I read that too, but if you're unwilling to answer any of my questions below then there's nothing more for me to say.
On Monday, February 6, 2017 at 1:41:07 PM UTC-7, Stephen Morton wrote: > > Thank you for taking the time to think about my issues. However, I will > direct you then to the end of my original question. " p.s. I'm aware of > answers like "Your workflow is broken, with git you merge often and > therefore never have lots of conflicts." It's just too long a discussion to > argue that point, so let's just avoid it, ok. " > > Stephen > > On Mon, 6 Feb 2017 at 15:00 Hugh Gleaves <hugh.g...@gmail.com > <javascript:>> wrote: > >> Yes I did read that already, what I don't know is the actual scale: >> >> >> - How many developers on this project branch? >> - How long does the project take? >> - How many changes (commits) do developers make per week? >> - How often do you merge ongoing changes from master into the project >> branch? >> - How many changes do developers make to master per week? >> >> >> >> >> >> On Monday, February 6, 2017 at 12:36:57 PM UTC-7, Stephen Morton wrote: >> >>> Thanks for your reply Hugh. Have a look at my follow up reply earlier in >>> the thread where I use Microsoft and the XBOX as an analogy. You should get >>> the idea. >>> >>> Stephen >>> >>> >>> On Mon, 6 Feb 2017 at 14:33 Hugh Gleaves <hugh.g...@gmail.com> wrote: >>> >> First here's a summary of what I setup for a small team: >>>> >>>> >>>> http://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task/41753291#41753291 >>>> >>>> You say "big merge" and "lots of conflicts" I wonder why this is >>>> happening? >>>> >>>> Tell me what do you mean by a "big merge" and what do you consider >>>> "lots of conflicts"? >>>> >>>> Ideally the more frequently you merge the smaller will be the scale of >>>> any conflicts. >>>> >>>> What do branches represent in your situation? are they representing >>>> projects or bug fixes etc? do multiple developers work on a branch or just >>>> single developers? >>>> >>>> >>>> >>>> On Wednesday, January 25, 2017 at 3:17:11 PM UTC-7, Stephen Morton >>>> wrote: >>>>> >>>>> I'm looking for a git branching and merge strategy for merge with lots >>>>> of conflicts requiring multiple people. I can make it work, and I >>>>> understand git, but it all seems kind of awkward and it feels like there >>>>> must be a better way. >>>>> >>>>> I've got a big git merge to do. There are lots of conflicts and it >>>>> requires many people to resolve them all. >>>>> >>>>> The only way to handle this in git, AFAIK, is to start the merge and >>>>> then just commit all files with conflicts in them and then let different >>>>> people work on the different conflicts, committing them as they go. That >>>>> is >>>>> great for resolving the conflicts. In the diagram below, branchA is >>>>> merged >>>>> into branchB with merge commit M. The code in the repo at M is full of >>>>> conflicts. Many of the conflicts in the merge are actually resolved in >>>>> commits x, y, z. >>>>> >>>>> o---o---o---o---- branchA >>>>> \ \ >>>>> \-o---o-M---x---y---z branchB >>>>> >>>>> >>>>> But I worry that the above strategy is not good for git's merge >>>>> tracking and future merges. Because if we do a 'git checkout branchA; >>>>> git merge branchB`, git will erroneously try to merge x,y,z into >>>>> branchA. >>>>> >>>>> I *could *create branchB2 where I re-do the original merge but then >>>>> just `git checkout z -- . ` and commit that as the merge commit. That >>>>> would work well for the git merge tracking. Then I would keep branchB >>>>> just >>>>> as historical reference for "who fixed what conflict and why" during the >>>>> merge. >>>>> >>>>> >>>>> The above would all work, but it seems so un-git-like. It feels like >>>>> there must be a much better and established practice, yet I have not >>>>> found >>>>> anything online. Is there a better way to do this? >>>>> >>>>> Thanks, >>>>> Steve >>>>> >>>>> p.s. I'm aware of answers like "Your workflow is broken, with git you >>>>> merge often and therefore never have lots of conflicts." It's just too >>>>> long >>>>> a discussion to argue that point, so let's just avoid it, ok. >>>>> >>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Git for human beings" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/git-users/0DObGNobp1w/unsubscribe. >>>> >>> To unsubscribe from this group and all its topics, send an email to >>>> git-users+...@googlegroups.com. >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Git for human beings" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/git-users/0DObGNobp1w/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> git-users+...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
