Hi Philip. Thanks for the response. Right now we are trying to migrate from IBM CMVC to GIT. We haven't really migrated yet, we are trying to get a plan ready for the migration, but we need some answers first on how GIT handles certain things that CMVC already does.
We are running just vanilla GIT on Github Enterprise, and just GIT or Github Desktop on our local dev machines. Let's say Developer A starts working on Feature A, and Developer B starts working on Feature B. If Feature B needs code from Feature A to work, then Developer B will mark Feature A as a "corequisite". This ensures that the build team gets both Feature A into the code when it comes time for Feature B to be included in the main build. What I am worried about is that if Feature B gets finished before Feature A is complete, and Feature B is included in a build without Feature A, then the build will be broken, because Feature B depends on Feature A. On Thu, Sep 20, 2018 at 3:58 PM Philip Oakley <philipoak...@iee.org> wrote: > Karo, > You don't say what the existing 'tool' is, and whether there is a way of > running both old and new (Git) tooling in parallel. > > When using Git branches (and local forks), it is possible for individual > devs to 'break' the rules regarding which files they can touch, but only as > a temporary measure, thereby allowing the dev to indicate a _potential_ > solution to the real owner of that area. > > The responsibility for the 'foreign area' is still with the old hands, who > get to pick and choose what they use in 'their' area (cherry-picking ideas > and code segments from those other branches). Obviously they get to do the > same back to the young whippper-snappers (showing who are the wiser > coders), and hopefully everyone benefits from the mutual working. > > The key step is that the area owners retain responsibility for what they > will accept into their segment of the master/trunk, without having to > actually do the work (when someone offers a finished work item). > > Most of this is careful social engineering using the best parts of each > particular tool and the process flows. > > HTH > > On 18/09/2018 00:37, Karo Zans wrote: > > 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 <philipoak...@talktalk.net> > 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.
