----- Original Message -----
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.
OK, so what is your workflow, and work products, in a little more detail - how
is it made to 'work' at the moment?
Is the project well modularised with no file >100 lines (excepting, maybe, well
developed libraries that never change), or are they mega-beast files with a mix
of long and short functions/objects/procedures ?
How are the review / merges done? do you have a small core team that hangs
together that can work on each issue, or is it multiple functions having a
review by committee that then depatches instructions to a poor coder to try and
implement before the cycle continues..
Do you have any intermediate work products (in the current process) where some
parts are fully merged, and then you can move on to the other parts; or it's
all partly merged as an intermediate work product for another round?
What is the smallest work element you could extract and get merged (done, done
style) from beneath the management's radar, as that you can do (with proper
commit message) in Git.
Have you seen the Mikado method (aka pick up sticks) as applied to correctling
faulty software. https://vimeo.com/54450491 is a nice presentation from Lean
Agile Scotland a few years ago.
--
Philip
[If I were you I wouldn't start from here, he said]
--
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.
