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

Answer 1

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 2

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 3

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 4

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 5

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 6

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.)