Using Git, is it possible to split up merge conflict resolution for a single merge between multiple developers?

Question

Some background:

Currently on CVS and looking to move to Git. We do planned releases for our complex custom internal platform every month or so.

In current development workflow, we have multiple branches, one for each of our planned release, such as an example:

• Release 7000, that will probably go out in May
• Release 7100, that will probably go out in August
• Release 7200, that will probably go out in September

(we can have half a dozen planned releases being worked on at the same time).

We also have named project branches, for larger projects that don't have a release date at the moment. They eventually get merged into a selected planned release branch, when the date becomes known.

Each release is quite large (many features), as releases require outages, we can't have them too often, we literally can get approval for release downtime once every month or so.

With this come merge conflicts. We have a CVS report that provides a list of manual merges that are to be done, and we split the work between a few developers. Any way to do the same with Git - to split up merge work for merge from one branch to another (resulting in many conflicts) between multiple developers?

EDIT:

This is what I ended up doing (note that we are using Atlassian Stash/BitBucket Server for pull request / code review):

• Merge daemon: Create a new "manual merges" branch from the target branch
• Merge daemon: Start merge to get list of conflicts
• Merge daemon: Notify managers and wait for conflict resolution
• Manager: Divide conflicts between developers
• Developers: Each developer creates and checks out "feature" branch from the merge branch, then start to merge source tag to their feature branch - they get the conflicts in their environment. They resolve conflicts only for the files they are responsible for, then do a soft reset to abort the merge, and commit only the files they resolved. Then they merge their feature branch (with review) to the "manual merges" branch.
• Merge daemon: Once conflicts have been resolved by developers, check out modified files from "manual merges" branch (only the files that changed). At this point all manual conflicts should be resolved. Commit and push.

Answer 1

Assuming your developers each have their own clone of the repository, there is no way to split up a single merge-and-conflict-resolution effort in the same branch across all these clones. When a developer performs a git merge on her branch and encounter conflicts, the merge remains "in-progress" (hence, no further commits can be made) until all conflicts in that branch is resolved and the merge completed with a merge commit.

That said, you can still assign each developer to resolve conflicts on a different branch in his own cloned repository; just not multiple developers on a single branch.

If you really have to stick with the existing branch set-ups and that you can cleanly partition the conflict resolution works without team members stepping on each toes, you can experiment with having a common repository on a shared machine where everyone can access (say, via ssh). Just do a git merge, and the conflicts identified in the output is your report :-)

In general, avoid letting the branches deviate too far from each other, by merging them often. Having a merge fest, especially near the release date, can be very stressful and error-prone.

A side note on your comment on restricted release cycles due to strict SLA, have you considered different release techniques such as blue/green deployment or clustering strategy (appropriate to your product) that might help to reduce downtime and mitigate risks?

Answer 2

Here's one approach:

1. Start the merge
2. Use git diff --name-only --diff-filter=U to print a list of merge conflicts
3. Use git reset --hard HEAD to reset to before you began the merge

But, it's better to just not let these things build up rather than have a massive conflict resolution exercise which may introduce more bugs.

You could do this by making 7100 a branch off of 7000 instead of master, and regularly rebase or merge 7000 into 7100.

You could also do this by keeping each feature on separate branches (feature-a, feature-b, etc.) and merge them in one at a time when you're near a release and you know for sure what'll be in it.