GIT: conflict quick, conflict cheap

push conflicts dev1

Days ago I gave a talk about git, and how to use it in a good way to reduce toils. At the end of the talk we discuss the conflicts, and what could be a good way to solve them. In this article, I’m gonna try to talk about the conclusion of the discussion and my experience solving conflicts. This article is aimed at people who have or haven’t experienced GIT, so at the beginning, I’m trying to explain step by step about the conflicts, so bear with me.

The context

When you are working on a project with a group of developers, commonly, you could share some interfaces, libraries, utils, or config files. Using GIT as a tool to manage your repository is a good practice.

The efficacy and efficiency of the team depend on the knowledge and good practices that your team uses in your repository. One of the most common problems that you face as a developer in a team is conflict. Deal with this kind of problem it’s a day at day work.

A conflict occurs when two developers change the same lines in a file, and the repository manager does not know which change should be used. At that moment a conflict occurs. Think a little bit about the possible scenarios:

  • Happy path: the expected result of the lines that were modified are the same in both cases, so it doesn’t matter which of the two possibilities you select, everything works well.
  • Not so happy path: the change affects the outcomes of the program, and depending on which approach you select the program can give data incorrectly.
  • Sad path: if you select one approach, the code created by the other developer breaks the application.

In all the scenarios there is the risk of having unexpected outcomes. But if we have the idea of the code as a communication way, all of these scenarios could solve the problem by the communication between the two developers, according to the best way to solve the conflict, and avoid unexpected outcomes. Let’s understand this situation.

Let’s deep dive into conflicts

Conflicts occur when two developers change the same lines in a file. Let’s assume we have a file like the following.

Main file

In this file, each geometric figure represents a line in specific, and the color represents the information that we have in each line.

In a distributed environment we usually have a remote repository, we can see this in the following picture:

Remote repositories

The remote repository is used to share the code with all the developers, so, all the developers should clone the main repository to have the changes updated, and this scenario should look like:

no conflict repo

In the preview image, we can see that each developer clones the repository using the remote. At this moment each developer has an updated version of the project.

But at that time each developer starts to work on the project. The first and the second developers need to change the triangle, Dev 1 changes it into a blue one, and Dev 2 changes it into a green one. These changes happen in the local repository, so for the memento, we don’t have any problem.

diferent modifications repo

At that moment the Dev2 decide to update the remote repository, she pulls their changes, and will see

first dev push

At this moment the remote repository has all the changes of Dev 2.


Now that Dev1 wants to pull their changes, let’s see what happens.

push conflicts dev1

The remote repository doesn’t know which change is the one that it has to use. So tell the developer, “Hey dude, first solve the conflicts, then I can accept your changes”.

The Dev1 understands what happened, and he downloads the latest changes in the remote repository, and he has to solve the conflict in their local repository, it looks like this:

pull to solve conflicts

Solving conflicts

Right now the Dev1 has to make a choice, which color is the correct one, in this case, assume that the Dev1 selects their color without thinking in the Dev2, the worst scenario could be:

creating errors in the system

In the preview scenario, Dev1 took a decision and the impact will be reflected in the part of the program of Dev2. So this isn’t the right solution. But The Dev1 cannot take the color green because in that scenario he has troubles in their program.

Recommended way to solve conflicts

Communication is important in the developer’s team, so, at this moment its important to have a meeting to solve this issue

debating about the solution

It’s better to “waste” 10 minutes in a meeting with the other dev to find an agreement about the best way to solve the problem than make a decision without discuss and maybe the other dev has to take hours to find out what is the cause of the problem. Remember that we are part of the same team, so we have to support each other.

Imagine that the outcome is that orange is the best color to solve this problem. But this color doesn’t affect the work of anyone.

conflicts solved

We cannot avoid having conflicts, but if we solve the conflicts in a good way, we can be efficient and efficacy in our team.

What’s your opinion about this?

You Might Also Like

Leave a Reply