How to resolve conflicts continuously while working on a long-term feature branch, before doing the big merge to master?

Question

I have created a feature branch from master, on which I have been working on for over a month. I have not merged it back to master yet, but I have made a trial merge and there were quite a few conflicts to resolve. I am concerned that there will be more and more conflicts the more I work on the branch and more work for me down the line trying to remember parts of code I may not have touched for a while when resolving conflicts.

My default strategy is keep working on the branch until it's done, then merge it into master, and deal with all the conflicts then. I am concerned however that the longer I wait the more painful the merge will be.

What strategy do I use to minimize the conflict resolution at the final merge, or at least deal with only very recent conflicts.

Answer 1

Regularly merge master into the feature branch (git merge master), or, if you don't want the merge commits, rebase your branch on top of master (git rebase master).

Rebasing rewrites the history of your branch, which may or may not be what you want (although the author and original date are preserved).

If you choose to merge regularly, you can end up with merge commits that don't resolve anything and are just clutter. You can prevent this by doing a "dry run" of git merge:

git merge --no-ff --no-commit

If there are no conflicts, this will tell you

Automatic merge went well; stopped before committing as requested

so you can do a git merge --abort to prevent the spurious merge commit from being created. (Another, less automatic, way to get the same behavior is to type git merge, then if you get an editor screen immediately, leave the commit message blank to cancel the commit. This is error-prone, though.)

Answer 2

Regularly merging master into your feature branch, or rebasing your feature branch on top of master, is a good answer.

Another option would be to enable rerere so you can reuse the recorded resolution:

There are a number of scenarios in which this functionality might be really handy. One of the examples that is mentioned in the documentation is if you want to make sure a long lived topic branch will merge cleanly but don't want to have a bunch of intermediate merge commits. With rerere turned on you can merge occasionally, resolve the conflicts, then back out the merge. If you do this continuously, then the final merge should be easy because rerere can just do everything for you automatically.

To enable rerere do git config rerere.enabled true. I generally add the --global flag so it applies to all repositories on my machine.

Answer 3

Try this:

use git rebase and use a 3-way merge tool to resolve conflicts that crop up, most of the time automatically. And is more accurate since things are merged automatically.

This has been the least painful way for me. git merge was much more painful, since it produces a lot of conflicts and 3-way merge tool gets lost and throws them all at you.

-- based on actual experience & trial of some 25 commits that diverged from master. I resolved 1 single conflict manually with rebase, which was a white space line, the other one conflicts resolved with git mergetool automatically. With git merge I cropped through 8 files trying to remember what I had done, making some mistakes in the process.