How to avoid git conflicts in a team?

Question

We are some developers who work on same project and we use git for the project. If two or more of us happen to work on same file, we receive git conflicts which are hard to deal with, sometimes changes done by one developer are lost when these conflicts happen.

How do they work with git in a team? What should be the proper flow in order to avoid git conflicts ?

Thanks in advance.

Answer 1

Before you dig deep into your workflow, before you spend a moment of time or a dollar of money rebuilding your communication processes, ask your team three questions:

1. Do we enforce whitespace conventions?
2. If we use IDEs, do they all use the same formatting and keyword settings? For example, Eclipse can automatically finalize parameters.
3. Do we generate textual build artifacts? For example, do we minify js, generate css rules from .sass or .scss files, or build xml configurations on the fly? Do we check them in?

After years of generating conflicts and helping others solve them in centralized workflows, I submit these three things cause the vast majority of our collective conflict pain:

In the above image, the '!' slice represents legitimate merge conflicts. The vast majority of awful merges come from lazy whitespace conventions or overly aggressive IDEs (or occasionally, overly-refactory developers). Before you do anything else, standardize your IDE settings and whitespace conventions. Then have everyone issue this command in their local repositories:

# Enable the repository's stock pre-commit hook
mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

That pre-commit hook will conduct a series of checks every time you issue git commit, including a version of git diff --check, a command that checks if your committed changes introduce whitespace errors. The commit will be rejected if it does. If you really need to get around it, you can issue git commit --no-verify, but don't: Whitespace errors are like the unexploded ordinance of version control. They're merge conflicts waiting to happen.

If you want to clean up whitespace, refactor a file to improve its indentation, or otherwise make a large series of purely formatting changes, do it in isolated commits, and warn the team to check in their conflicting work in progress first.

If you conduct code reviews, make these the first questions every reviewer asks: "Did this change set touch anything it wasn't supposed to? Did it clean up any formatting? Did it unnecessarily refactor a method?" If it did, fail the review. Or if you can't, make sure those changes are sufficiently isolated from the logical changes (i.e. in different commits) to make your history useful.

Stylesheet languages, RequireJS, and js minifiers also cause conflicts, if their generated targets are checked in. The files created by these technologies are build artifacts. You wouldn't check in a WAR archive; don't check in a SASS-compiled CSS file. Or, if you feel you must, use a .gitattributes file to let git treat them as binaries.

If after doing all of these things, you still have merge conflicts, institute workflow improvements. Gary Fixler's answer is absolutely right: Legitimate merge conflicts arise because teams cannot or do not communicate well about the scope of their projects. Just make sure its not poorly enforced formatting rules first.