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

Question

Some background:

Currently on CVS and transition to Git. We plan to release our sophisticated custom internal platform every month or so.

In the current development stream, we have several branches, one for each of the planned releases, for example, an example:

• 7000 release likely to be released in May
• Release 7100, which is likely to be released in August.
• Release 7200, which is likely to be released in September.

(we can have half a dozen planned releases working at the same time).

We also named the project branches for larger projects that do not currently have a release date. In the end, they become merged into the selected planned release branch when the date becomes known.

Each release is quite large (many functions), since the releases require failures, we cannot do them too often, we can literally get permission to stop the release once a month or so.

This causes merge conflicts. We have a CVS report that contains a list of manual mergers that need to be completed, and we have divided the work among several developers. Any way to do the same with Git is to split the merge work for merging from one branch to another (leading to a lot of conflicts) between several developers?

EDIT:

This is what I ended up doing (note that we are using Atlassian Stash / BitBucket Server to view the request / code):

• Merge daemon: create a new manual merge branch from the target branch
• Combine daemon: start merging to get a list of conflicts
• Combine daemon: notify managers and wait for conflicts to resolve.
• Manager: share conflicts between developers
• Developers: each developer creates and verifies the "feature" branch from the merge branch, and then begins to merge the original tag with their objects branch - they get conflicts in their environment. They only resolve conflicts for the files they are responsible for, and then perform a soft reset to abort the merge and commit only the files that they resolved. Then they merge their function branch (with overview) into the "manual merge" branch.
• Merge daemon: once conflicts have been resolved by the developers, check the modified files from the "manual merge" branch (only files that have changed). At this point, all manual conflicts must be resolved. Lock and press.

Answer 1

Here is one approach:

• Run merge
• Use git diff --name-only --diff-filter=U to print a list of merge conflicts
• Use git reset --hard HEAD to reset before you start the merge

But it’s better to simply not allow these things to accumulate, and not to carry out a massive solution to the conflict resolution, which can cause more errors.

You can do this by making a 7100 branch of 7000 instead of master and regularly reinstalling or merging 7000 into 7100 .

You can also do this by storing each function on separate branches ( feature-a , feature-b , etc.) and combine them one at a time when you are approaching the release, and you know exactly what will be in him.

Answer 2

Assuming your developers have their own repository clone, there is no way to split one merge and conflict action in one branch into all of these clones. When a developer executes git merge in their branches and conflict conflicts, the merge remains "incomplete" (therefore, further commits cannot be made) until all conflicts in this branch are resolved and the merge is completed with a merge commit.

However, you can still assign each developer to resolve conflicts in another branch in your own cloned repository; just not a few developers on the same branch.

If you really need to adhere to existing branch settings and so that you can clearly divide conflict resolution without typing team members on each finger, you can experiment with having a common repository on a shared machine where everyone can access (say, via ssh ). Just do git merge and the conflicts identified in the output is your report :-)

In general, avoid branches branching too far apart, often combining them. Having a merger festival, especially around the release date, can be very stressful and error prone.

Note on limited cycle commentary due to strict SLA, have you considered various release methods, such as a blue / green deployment strategy or clustering (appropriate for your product) that can help reduce downtime and reduce risks?

Answer 3

Maybe Gerrit , a fluent Git server, can help you: he has a concept for change. Each change belongs to the user (usually the developer). The developer can use the function for the future release branch, but it will not be applied directly to the branch (for example, by clicking on the magic branch refs/for/release-7100 ).

Once someone (such as the release manager) decides that this function really needs to be accepted, the change can be sent. If the branch branch is scattered for a while, the developer will be notified and must resolve the conflicts. After clicking resolved conflicts, the change can be sent again.

I have not tried this workflow myself, but I think it might work. In any case, I think it's worth a try ...; -)

Answer 4

Oh my gosh, our team recently went through this and was initially upset by this restriction. The merger from the "source" of the branch to the "destination" of ours (admittedly hacking) was:

• For each team member, we cloned copies of the “destination” as “destinationMerging” on our separate machines.
• Then each of us, in the destinationMerging directory, made a 'git merge source'
• This created a list of conflicting files. We created a checklist of conflicts that we all could edit. (Perhaps you can do this in Google Docs.)
• We than started merging conflicts over a file. When one of us starts working on a new file, we will check it in the list. A checkmark means "this is being done or working."
• When we are done with the file, we will copy it to the source “target” repo and commit / push these changes.
• When all conflicting files were resolved and clicked, one person, then, from the "destination", made an attempt to get all the changes, and proceeded to the "git merge source"

Absolutely inelegant, but he did his job. I understand that “it’s better just to prevent these things from accumulating,” but when they do, they need to be fixed, and that was the way we could do it in a distributed way.