Re: [git-users] How does GIT handle Coreqs
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 () 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 > 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 git-users+unsubscr...@googlegroups.com. > 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 git-users+unsubscr...@googlegroups.
Re: [git-users] How does GIT handle Coreqs
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 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] How to enforce permissions?
My company currently has a structure where several teams work on the same project. Right now our current system has permissions built in that only allow you to make changes to certain files. Basically file permissions. In GIT, is there a way to only allow certain teams/users to make modifications to only the files they are allowed? Is creating multiple repositories the only way to accomplish that? 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] How does GIT handle Coreqs
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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
