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?
Is there any situation, where
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.
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).
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.
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).
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.