0

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?

MattL
  • 109
  • 3
  • 12
  • The only way to avoid a conflict is to not work on the same code at the same time. – mkrieger1 Sep 08 '21 at 09:58
  • Of course you could just *solve* the conflict instead of trying to avoid it. – mkrieger1 Sep 08 '21 at 09:59
  • What I don't get is that developer A worked on the line "background-color" while developer B worked on the line "color" so they did not work on the same lines of code – MattL Sep 08 '21 at 10:07
  • 1
    You may not "get" that, but that isn't what you asked. Anyway, editing adjacent lines is a merge conflict, and you could have found that out by searching. For example see https://stackoverflow.com/a/55275859/341994. Or https://stackoverflow.com/a/51899176/341994. Etc. – matt Sep 08 '21 at 10:13
  • I had voted to close this as I thought that you were just being silly. I've retracted my close vote though because in retrospect I think that it is actually an important discussion. Merge conflicts are part of working in a team and its important to learn how to manage them and not think that they are something to avoid. – Software Engineer Sep 08 '21 at 10:58
  • @matt thank you I didn't know that adjacent lines could cause conflict. – MattL Sep 08 '21 at 12:45

2 Answers2

1

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

Software Engineer
  • 15,457
  • 7
  • 74
  • 102
0

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.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • I'm pretty sure that avoiding git won't solve this problem. The problem, as you're clearly well aware, is having 2 people edit the same file. This isn't solved by avoiding git. – Software Engineer Sep 08 '21 at 10:55
  • @SoftwareEngineer If you have a different answer, give it as an Answer. But I don't agree. My experience is that in real life, with everyone grabbing tickets as fast as they can to get through the sprint, that sort of fine grained planning is impossible even with the best communication. – matt Sep 08 '21 at 11:59
  • Yeah, but how is removing the tool going to help? It's always a people problem and rarely a tooling problem. If you remove the tool that shows you the conflicts you are then flying blind. What's the alternative to not having git? SVN is worse, and so is the less popular git-like Mercurial. I agree with everything you say, except the dump git bit. It's like being on a liferaft at sea during a storm and jumping out because you're still getting wet. – Software Engineer Sep 08 '21 at 16:33
  • The alternative, my answer says, is to stop wanting to avoid merge conflicts. – matt Sep 08 '21 at 18:03
  • That's not an alternative to git though is it? That's an alternative to the OP's request, and it's the right answer, but it has nothing to do with the tool – Software Engineer Sep 08 '21 at 18:05
  • Well, I'm not going to bat this around ad nauseam. I can't help feeling there's a misunderstanding of my answer here. Anyway, as I already said, feel free to write a better answer. – matt Sep 08 '21 at 18:17