Is there any situation, where git merge command uses frequent committing in one or both branches to prevent merge conflict (as opossed to one giant commit of week-long work followed by immidiate merge), or are those things independent?


Making several small commits rather than one big one will not magically prevent conflicts, but it usually makes them less frequent and easier to deal with.

If you commit and push lots of small changes to master, then it's harder for conflicts to arise in the first place, since less code is changing between commits and the other developers will see some of your changes before they start to make their own.

If you have a feature branch that's broken up into lots of small commits when you merge, then the merge is done one commit at a time, so if there are a lot of conflicts, you only have to resolve one commit's worth of conflicts at a time, which is usually a lot easier than resolving them all at once.

The git merge command itself does not perform any commits, except for a single "merge commit" if necessary. It will not retroactively split an existing commit into several smaller commits or anything like that (I don't believe there's an easy way to do that in git, or any other VCS).

| improve this answer | |
  • Can you show documentation for the "fact" that merge is done "one commit at a time". I am familiar with this behavior for rebase, but not for merge. I could be missing something, though. – Joseph K. Strauss Feb 9 '15 at 0:41
  • Note: The way to split the last commit into smaller ones in git would be: Reset the last commit, then git add --interactive (using "edit" where needed) to build logical units to commit individually. To make sure not to create invalid (= non-compilable) commits, do a git stash, make, git stash pop after each (partial) commit. – U. Windl Dec 28 '19 at 19:35

Frequent committing and merge conflicts are independent of each other. By committing often you reduce the probability of a merge conflict, you cannot eliminate it. If two people both clone a repository, change the same line in a file, commit, and push it then it will result in a merge conflict. It does not matter how quick they were.

| improve this answer | |
  • "By committing often you reduce the probability of a merge conflict,": If you split one commit with one conflict into three commits with only one conflict in a single commit, the relative probability per commit will be less, but absolutely a merge conflict will be a merge conflict still. – U. Windl Dec 28 '19 at 19:24

Not a direct answer, just the practice that works best for me:

  • Have a central repository with a master branch in it.
  • Clone / pull the central repo's master branch before taking on a new task / ticket / feature.
  • As you go, do local commits often.
  • After each commit, or at least periodically, do a git pull --rebase. This will put your current work on top of master's most recent state. Since you do it often, automatic merges will usually suffice. When conflicts arise, they will arise on your branch and will be hopefully small.
  • When you are done and ready to push your feature, you have zero conflicts, by definition.

I usually don't work on the master branch locally but instead make a separate named branch (or several, try various approaches); this prevents me from an accidental push.

Even better is if you have a code review tool like Gerrit installed, and your master repo can't be directly pushed to (only via code review).

| improve this answer | |
  • There are problems with this approach: "As you go, do local commits often.": Why? – U. Windl Dec 28 '19 at 19:26
  • "git pull --rebase": This may ruin the work you did, requiring you to change code more frequently that necessary. The only advantage I see is this: Your future work after the rebase may be free of further conflicts. – U. Windl Dec 28 '19 at 19:30
  • @U.Windl: The whole idea is to do it frequently, so any change required is small and hopefully obvious. It avoids a bigger problem when you need to merge and change a lot, and risk to end up with a square peg and a round hole. That can indeed ruin your work. – 9000 Dec 28 '19 at 22:26

While frequent commits will not reduce the absolute occurrences of merge conflicts, but making them easier to resolve (at first sight), the truth is different: Commits don't come independently; usually they are a logical unit of work each. If the logical unit of work consists of several commits on a branch, the total merge conflicts will be the same when merging the branch, whether it's one big commit, or multiple smaller commits.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.