Hi, Github or Gitlab will allow you to enforce some level of restrictions, mostly about who can or can't merge branches or can access to the repo at all. I never used gerrit so I can't say much about it.
Git (check git hooks) will allow you to run scripts in different situations (i. e. before making a commit or before a merge) so you can make some validations (or whatever you want) and decide if you want to abort the current action. With this, for example, you can reject some one code if they don't pass some validations. I know for sure that gitlab will allow you to add hooks to individual repos so you can enforce custom permissions, i don't know about github. This can help you to enforce some workflow, have in mind that maybe you will need to develop the scripts. There are many workflows, you should learn from them and make one suited to your needs, search for git workflows you will find many. IMHO almost every team have a different workflow. El lun., 17 sept. 2018 a las 20:37, Karo Zans (<[email protected]>) escribió: > I see. Thank you for the response. I agree with what you say. > Unfortunately, I am dealing with about 250 different developers who have > been on the same project for 15, 25, and even 35 years and they are all > stuck in the old school way of doing things. > Asking them to adopt a new tool is like extracting teeth. I can't tell > you how many times I've heard, "What we do now works, so why change?". > Frankly the only reason why we are moving to GIT from the old system is > because the old tool isn't being supported anymore. > > Thanks for the information on the workflows. I think I have heard that > some people like Google use Gerrit in combination with GIThub. That is > supposed to enforce permissions, is that right? Where can I find these > workflow models? I think I saw some basic ones in the GIT user manuals, > but they didn't seem to work for us. Is there a good place I can look at > several workflows? > > Thanks > > On Mon, Sep 17, 2018 at 4:23 PM Philip Oakley <[email protected]> > wrote: > >> Hi, >> >> Most processes are driven by the limitations of the local tool and the >> experiences of local staff and managers. This also affects the way teams >> are structured (see Conway's Law). >> >> Git, with it's 'Distributed control' model, tends to break the old >> paradigms which were based on the 'absolute single master ' idea (one >> master drawing / paper record). Git avoids the need to limit peoples >> scope by separating the modification step from the acceptance step. >> >> Clearly it us reasonable that people generally stay within their lead >> area, but there is nothing wrong with stepping into other areas with >> carefully crafted and explained changes. They won't be accepted, I hope, >> if they fail that criteria. It is important to have a high quality >> senior dev at the acceptance stage who is firm but fair. >> >> The fact that git branches are free and easy makes this freedom easier. >> Have a look at the various workflow models, including Nvie's and that of >> git itself (4 layer: master, next, pu (potential updates), maint). >> >> Philip >> >> On 17/09/2018 21:17, Karo Zans wrote: >> > Hi everyone. I have a question. At my current company, we have quite a >> > few developers. Each team has about 10 or 15 developers that are only >> > allowed to modify their specific code areas. >> > >> > On our current bug and new development tracking system, we have bug >> ticket >> > that code changes are tied too, and sometimes a bug ticket is marked at >> a >> > CoRequisite of another bug ticket. >> > >> > Basically if a person on another team has to implement a function or >> > feature or bug fix in their code, I will mark my bug ticket as a >> > CoRequisite of their bug ticket, if my code depends on the new function >> > they are adding or fixing. >> > >> > So I was wondering, how does GIT enforce this? >> > >> > I realize that I could simply create a branch off of another person's >> > branch and that will indicate that my code depends on their code, but >> > suppose I finish my code before they finish their code. >> > >> > If a sub branches code is merged into Master before, the parent branch >> is, >> > the code will be broken. >> > >> > How does GIT mitigate/enforce this so that the build isn't broken? >> > >> > Thanks >> > >> >> -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Nelson Efrain A. Cruz - https://plus.google.com/106845325502523605960/about "Debes ser el cambio que esperas ver en el mundo" -Mahatma Gandhi -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
