Several feature branches in the Github Flow

Question

I have a question regarding the GitHub flow and specifically about how to manage multiple features developed at the same time.

Let assume we have a simple CSS file.

.container{
    height: 500px;
    width: 500px;
    background-color: blue;
    color: white;
}

Let assume developer A is in charge of changing the background color to red while developer B is in charge of changing the font color to black.

Developer A creates its feature branch "red-background", updates the CSS file and commits the change in its branch. The CSS file in "red-background" branch is now:

.container{
    height: 500px;
    width: 500px;
    background-color: red;
    color: white;
}

Developer B creates its feature branch "black-font", updates the CSS file and commits the change in its branch. The CSS file in "black-font" branch is now:

.container{
    height: 500px;
    width: 500px;
    background-color: blue;
    color: black;
}

Now if the reviewer merges "red-background" to main and then "black-font" to main, a git-merge conflict arises :

.container{
    height: 500px;
    width: 500px;
<<<<<<< HEAD
    background-color: red;
    color: white;
=======
    background-color: blue;
    color: black;
>>>>>>> black-font
}

How to avoid conflict in those types of situations?

Answer 1

How to avoid conflict in those types of situations?

Don't collaborate using Git.

Seriously, this is what Git is / does. If you want to "avoid" it, avoid Git, except for degenerate uses like only one person has access to the repo. If you're going to collaborate, you're going to get merge conflicts sometimes. One person changing a line and another person changing an adjacent line, that's a conflict. That's just life.

But conflicts are not bad. They are not things to be avoided. So, ignoring your actual question, another solution is: don't avoid them. Resolve the conflict. Git is asking for your help. Help Git, and go on with life.

A common technique for making the history cleaner is to reverse merge just before merging the PR. That way, there might still be a conflict to resolve, but you resolve it during the reverse merge, in a commit on the PR branch, and the actual merge to the primary branch, closing the PR, has no conflict. But then, once again, you are not "avoiding" the conflict. You are managing it, which is not what you asked to do.

Answer 2

@Matt has provided an answer that is partially correct. It states that you shouldn't be avoiding merges, you should be resolving them and this is correct.

However, it also states that if you want to avoid merge conflicts you should avoid git. This is the bit that's wrong. If two users edit the same file then you have a merge conflict. Git is only highlighting that conflict and trying to help you resolve it. Throwing Git away wouldn't resolve the underlying issue, which is that 2 people edited the same file.

There are actually a few things you can do to make your life easier, but first you have to accept that your tools are amongst the best available and are used by millions of developers who successfully develop systems with them. The tools are not to blame and you must learn to work with them without feeling like they're the problem.

One way to avoid continual conflicts is to split files up. With CSS that's quite easy as CSS classes are automatically merged. This may make it more difficult to find the place to make a change, but with modern tools, it's pretty easy to search your code and find the right place.

Another way is to assign control of a file to a single developer so that, say, all CSS changes in one file go to one guy and all the CSS changes in another file go to another guy. Or, you could assign all CSS changes to one guy and have the other guy work on something else.

You could always have engineers working on the same file actually pair and make their changes together. This will increase quality and throughput anyway and pairing is considered one of the most effective ways to avoid bugs. Ultimately, this is in effect, pre-merging: a conflict avoidance technique.

I once worked with a team of 10 engineers with a small and intense codebase. We would avoid major conflicts by calling out when we were changing a central file, say the master CSS, to keep other people from posting updates until the original set of changes were merged to main. They could then merge main into their feature branches (as per git-flow) and then issue their pull request.

Eventually, all efforts to avoid merge conflicts are bound to fail and it becomes necessary to learn how to merge quickly and efficiently. It's not that hard. If there's two of you working on the same file, one of them is merged with main, then the 2nd engineer merges main into their code, then the results are fast-forwarded onto main again. Mostly it's neither hard nor time-consuming.