Feb 21 2014
How to avoid git conflicts when working with a team?
Continuing…
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-commitThat pre-commit hook will conduct a series of checks every time you issue
git commit, including a version ofgit 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 issuegit 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.
The above quote made me realize our problem was I hadn’t defined a set of rules, conventions, and standards for the new guy to follow. As a result he decided to apply his own list of best practices on the existing code base.
Another issue is whether to separate different tasks into different classes (as opposed only to methods). Instead of having large classes containing multiple methods why not refactor and separate code into multiple small classes in order to further decrease the risk of git collisions? This is something I implemented by separating the code the new developer was responsible for and placing it in a completely separate class.
Thoughts? Happy development!
