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.

Answer 2

Well, to be really honest, the proper workflow involves good communication and management. Team members shouldn't often be working on the same thing and causing conflicts. Things like daily standups, and an attentive manager who knows what each member of the team is up to - at least in general - will go a long way in many cases to limit this.

It depends on the exact nature of the product, of course, but this is more of an organizational issue than a git issue. In fact, conflicts are often seen as "good" things, because they get people to get up from their desks, or call each other up to talk about why there was a conflict, and what should be done about it going forward. This is a chance to figure out that one person should own one area, or a set of files, or at least be the point of contact for discussing changes to that section.

Outside of making an up-front plan, there is no way to avoid git conflicts, but this would be the same issue in any versioning system. Any time two people change the same section of code, you have to figure out who wins. This is why it's not really appropriate to look toward the versioner for the solution, but to look to your team's methods and practices. Two cars can't go through an intersection at the same time, but it's extremely hard to invent cars that can pass through each other, so instead we invented the control systems of stop signs and traffic signals. This is a similar issue. We can't really make two changes to the same thing not conflict, so we must control how we work with the files.

You could consider one of the front-ends that allows locking in git, but I don't really agree with the concept, outside of non-mergeable filetypes. I think it's better to figure out a better team workflow, and meanwhile, use this as an opportunity to get really good at merging files. I did that, and now after months of doing it, conflicts are not an upsetting thing to me.

Answer 3

There is only one way to avoid conflicts: don't have different people edit the same file at the same time. Essentially each file has an owner who is responsible for all edits and who can pass ownership to another. Ownership for a file can be passed around based on a particular feature/branch or day-to-day as long as the ownership is clear.

If you find that you can't give one owner to each file then:

• you need to split your files into smaller files that can be assigned to one owner
• absolutely require that GIT conflicts get resolved (with all editors sitting together to resolve the individual conflicts).
• Use a good multi-merge tool to visualize and then resolve the conflicts.

Answer 4

Use appended block starts

In software like this ...

function chess() 
{
    while (!end_of_game)
    {
        make_move()

the lines starting blocks with opening braces are easily going to be confused with other lines in the software consisting of single opening braces. If the same software is written like this, appending the block starts to previous lines ...

function chess() {
    while (!end_of_game) {
        make_move()

which I personally don't like, but Git does, there are lots less lines that look similar to Git and get mistaken for each other, i.e. Git is more likely to perceive the editing the same way we do, making any conflicts much easier to resolve.

And comments on block endings

Use comments to make similar looking lines distinguishable.

If you write lots of javascript and JSON, you might have lots of lines that look a little like this.

            }
        }
    }
)

If you comment things then they can become distinguishable.

            }
        }
    }
) // end of weekdays()

and

            }
        }
    }
) // end of weekend()

no longer look the same to git. This can help git to understand your changes better. If you add something, like

function a()
{
    ...
} // end of a()

git is more likely to see that as a unit of change and not think you have added something like

}

function a()
{
    ...

just before the end of some other function. Even when this does not prevent conflicts, if git sees and presents your changes sensibly (i.e. the way we mentally view them), then you can perhaps resolve conflicts more easily. A descriptive header commenting what functions do, the parameters they take, etc, will further help to prevent git from muddling the contents of neighboring functions together.

Answer 5

Ordering.

There are a few other things you can do that might help too. It will be clearer if I post them separately.

Where you insert new things will help determine whether you create conflicts.

Imagine a list of names of employees

Andy, 
Oliver, 
Ivan,

Then Brad and Patrick join and their names are added to the list. You add Brad and I add Patrick. We both add the names to the bottom of the list, and then use git to merge our lists. The result will be familiar to git users :-

Merge branch 'Patrick' into Brad

Conflicts:
    names.txt

@@@ -1,4 -1,4 +1,8 @@@
  Andy, 
  Oliver, 
  Ivan,
  <<<<<<< HEAD
 +Brad,
  =======
+ Patrick,
  >>>>>>> Patrick

Now suppose we had done the same thing but imposed a simple alphabetical ordering rule on our list. Now when we come to merge the two branches the results are a little more pleasing :-

Andy,
Ivan,
Oliver,

Add one name yourself and then merge the other person's change with git, to add the other name.

Auto-merging names.txt
Merge made by the 'recursive' strategy.
 names.txt | 1 +
 1 file changed, 1 insertion(+)

And we get

Andy,
Brad,
Ivan,
Oliver,
Patrick,

Since we don't know who is going to join the company next we are effectively adding to the list randomly, and by inserting in random places, conflicts of location in the files are less likely.

Answer 6

To reduce the number of conflicts in version control without worrying about who is editing what, you simply need to make smaller changes and commit/push them incrementally. Split the problem up into small enough pieces that you can quickly modify files and push them back to trunk. The shorter lived your branches are, the less chance there will be of merge conflicts.

Even then, at some point two people will edit the same file at the same time through no fault of their own. The obvious question when that happens is:

"How can I take the pain out of resolving git conflicts?"

The answer is you should pull trunk and rebase your branch onto it frequently, and you will notice the conflicts as early as possible, while they are still small. At this point both developers should sit together and calmly discuss the best way to proceed while the changes are fresh in their minds.

Contrast this approach with trying to resolve conflicts on huge long-lived branches in a panic just before a release deadline, when the developers struggle to remember the thinking behind all the changes they made some time ago.

Answer 7

Use UTF-8 not UTF-16 for text files.

Many versions of Git (i.e every version I have used, as far as I know) can treat UTF-16 files as binary files due to the presence of many zero bytes in a typical UTF-16 text file.

Once Git thinks a file is a binary file, it is likely to keep on treating the file as a binary file even when it is changed. This means that the version control is done by storing complete versions of the file rather than the differences between them and the some of the advantages of a version control system are lost. (Edit: No. I tested this recently by changing a UTF-16 file to UTF-8 committing it, editing it and committing again - and it started treating the changes as text changes once BOTH the original and edited files were UTF-8.)

Most modern editors will recognize the character encoding and line ending style of a file and save the file in the same format. Some editors (e.g. Babelpad) will allow you to choose whether you save your file in UTF-8 or UTF-16, and with or without a byte order mark, etc.

If the file you want to version control is (i) in UTF-16 format and (ii) would work equally well in UTF-8 -- for example a source program for a decent modern compiler -- it is worth considering converting it to UTF-8.

If Git thinks your source text is a binary file before its very first commit, look at it and see if it is worth loading it in an editor and saving it in a different format that Git recognizes as text.

(Note. Linux files tend to be UTF-8 by default. Some Windows programs had a habit of creating UTF-16. So it's Windows users that are most likely to have the problem. Also note that you want to correct this before the very first commit of the file, before Git believes it has a binary file!)

Use Git rerere

Reuse recorded resolution!

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Answer 8

Inform colleagues when you have pushed your changes

Another way to reduce the pain of conflicts is simply to inform colleagues when you have pushed your changes. It allows them to pull your changes and resolve some conflicts there and then. Any conflicts are likely to be between your recent change, fresh in your mind and what they are working on, fresh in their minds.

If people don't pull changes from the main branch until they have finished a large development and then have conflicts with changes made by a number of people, all in the same area, then it will be harder to resolve.

Use a mergetool

One of Git's purpose's is version control. Other programs specialize in merging files and resolving conflicts. If you configure a mergetool to use with git, then it can automatically resolve many issues which git regards as a conflict, or at least make a very good guess for you to inspect and simply leave untouched if it looks okay, or you trust the tool.

That leaves fewer genuine conflicts which need an intelligent decision for resolution.

Use smaller files

I add a new controller at the bottom of mycontrollers.js and you add a new controller at the bottom of yourcontrollers.js: no problem.

We both add a new controller at the bottom of allcontrollers.js: conflict.

(However remember the advice about ordering things alphabetically too. myNewController() starting with M might go in the middle of a file and yourNewController() starting with Y might go at the end of the same file, again with no conflict.)