Whose responsibility is it to fix merge conflicts?

Question

Say that A is working on a branch based off master and B merges changes into the master branch, which introduces merge conflicts between A's branch and master.

Whose responsibility is it to fix merge conflicts? I am not intending to be petty, so in other words - is it more productive in general if A fixes these conflicts or B?

It's always the responsibility of the non master branch owner to fix that of course. — πάντα ῥεῖ, Feb 21 '20 at 17:52
There isn't really an answer. It's whatever you decide what the process should be. — Martin K, Feb 21 '20 at 20:03
A will first _merge master into their working branch_, resolving any conflicts, and then merge the now-conflict-free working branch back into master. — Eric King, Feb 21 '20 at 20:18
Without any specific setup, B cannot even see what changes A made in their own branch (those may not even be physically accessible be B). That does not mean A could not ask B for help in merging if required, but the one who is responsible is a no-brainer. — Doc Brown, Feb 22 '20 at 07:33
A should resolve the conflicts on their own branch, *provided* they are absolutely sure that they are not breaking functionality introduced by B. It is therefore necessary for A to understand the changes introduced by B at a high level, and be able to ask questions of B if uncertain situations arise (although these should not be very common in practice). — preferred_anon, Feb 22 '20 at 13:27
@shoover: I can mention rebase if you wish. rebase runs into conflicts for the exact same reasons as merge: two developers concurrently tried to integrate changes to the same part of code. — Laurent LA RIZZA, Feb 24 '20 at 11:31
Rebase before attempting to submit a PR incurs a merge conflict only on the author's side and inconveniences only the author, not the entire team. — shoover, Feb 24 '20 at 13:09
@shoover since hypothetical merge conflict is already worth discussing *whose responsibility is it to fix it*, a small mistake in rebase can do a lot of harm. I'm not trying to start a merge-vs-rebase war, but *merge* in that case would preserve information about the conflict itself as well as context when and why it happened, so anyone could rewind history back to that point and redo a merge. — Sanya_Zol, Feb 24 '20 at 21:50
@Sanya_Zol The tests that the developer ran on his/her PC after the rebase but before submitting the PR should catch that, right? Also, note that I'm just talking about a simple rebase, not a rebase-and-squash or rebase-and-modify. — shoover, Feb 25 '20 at 01:15
Also, there's still a merge of the rebased branch, but it's just a FF. — shoover, Feb 25 '20 at 01:19
Person A knows in more detail what changes he has been working on, and thus should be able to better figure out how to resolve the conflicts. If Master has progressed a lot, then A should ask B for help/clarification (or another C who is also working on the project), but still it's A's responsibility to provide a conflict-free PR to be reviewed. Git annotations will be helpful here. — chesscov77, Jul 13 '20 at 14:46

score 131 · Answer 1 · answered Feb 21 '20 at 18:46

131

Person A is the one who decides when to incorporate new changes from master, so Person A will perform the merge. Person A should certainly attempt to resolve merge conflicts on their own, but if any questions arise then both Person A and Person B should sit together and resolve the conflicts together.

Remember that you work on a team. Teammates should help one another without resorting to finger-pointing or saying "it's your job, not mine."

So to answer your question, neither person is solely responsible for resolving merge conflicts. You both are.

answered Feb 21 '20 at 18:46

Greg Burghardt

34,276
8
63
114

12

-1 - this doesn't apply to a situation when B's code is in master already - his job is done. In fact, A has a conflict with master branch, not with B's branch. And if A is not able to resolve conflicts on his own, his programming skills are very poor. – sanyassh Feb 22 '20 at 07:57
5

Person B has put changes into master. Person B is now on vacation. Person A is on their own. Just like person B was when they put their changes in. This is fine. You don't have to sit with anyone to resolve conflicts. Just resolve them. If person B comes back from vacation and takes issue with the changes now you have something to resolve together. Now you have to talk. This works fine. It's how Wikipedia editing works. – candied_orange Feb 22 '20 at 08:56
75

@sanyash That's a rather unproductive stance. a) It means that not all information available to resolve the conflict are used (the part inside B's head is missing), and b) it poisons the team spirit. Of course, a good programmer will be able to resolve most conflicts on their own without needing to ask the other person for assistance, but in case of doubt, getting the other person to help is a valid approach that should not be precluded for petty reasons of pride... – cmaster - reinstate monica Feb 22 '20 at 08:59
40

@sanyash So they may be a junior developer or someone new to the team who does not understand the history of the codebase or just someone who for all kinds of reasons is unable to know all the requirements of the code they're merging into. There are many reasons why resolving merge conflicts should not be a "lone wolf" process. Anyone who believes their responsibility for their code ends at merging into master has very poor team-working skills. – Ben Cottrell Feb 22 '20 at 09:11
34

@sanyash I consider knowing when to ask for help a valuable programming skill. – Emile Bergeron Feb 22 '20 at 21:04
4

@sanyash If a coworker needs help with something you can help with, however simple it seems to you, it's your job to help them. This would apply for person B or person C, who maybe reviewed B's code, or even person D, who knows barely anything about the codebase as a whole. And if you're blocked by something, it's your job to ask for help if required. Although I do think "Person A will perform the merge" is the part that should be bold, and I agree that merges *generally* shouldn't be particularly hard, unless your codebase or project is an absolute mess. – Bernhard Barker Feb 23 '20 at 00:23
1

@sanyash your job is never done as long as you work there. Your job is to help the company as much as possible using any means available to you. Cooperate. – usr Feb 23 '20 at 20:45
1

From Twitter: @ExpertBeginner1 Apr 16, 2015 Tried out git and not impressed. I was hoping for a lot more out of git blame. – CJ Dennis Feb 24 '20 at 03:27
3

The first sentence and a half is the answer, in terms of what typically happens in practice. Which is that whomever commits first wins, and everybody else gets to deal with the merge conflict(s) on their branch(es). Usually they'll do that on their own. Collaborating on the merge is fine, but I wouldn't say it's common. – aroth Feb 24 '20 at 03:48
@aroth what is common and what is not depends solely on the team culture of the project. Encouraging collaboration during the merging process, together with setting up useful tools to ease the process itself, leads to less long-term bugs and as such is a thing useful to be common, if all the rest of the project allows it. – bracco23 Feb 24 '20 at 11:44
2

If merging requires intervention of people whose code is already on master that means there's a problem with whatever was merged on master. Most likely, it is missing proper documentation and a proper explanation of the intent behind the changes. – Kafein Feb 24 '20 at 16:46
3

@Kafein: Merge conflicts are not always avoidable. If you are a .NET developer merging changes to Visual Studio `.csproj` files then merge conflicts are a pain you must deal with once in a while. Those kinds of files aside, merge conflicts don't necessarily reflect bad planning or documentation. The code that needs changing needs to be changed. The longer your branch lives, the more conflicts will arise, even with good planning and communication. – Greg Burghardt Feb 24 '20 at 16:51
2

@EmileBergeron - Indeed. I consider myself lucky that I learned this lesson early on - in my second job - when I got reprimanded for trying to figure out a problem myself and not ask for help thus delaying the entire project. Sometimes that stubbornness to try something out yourself is useful because it prevents you from giving up on a problem. Sometimes it is not helpful. Knowing when to ask for help is an important skill – slebetman Feb 25 '20 at 02:48
@Ben Resolving merge conflicts is _always_ followed by code review. – gnasher729 Feb 25 '20 at 09:59
1

@GregBurghardt I don't mean that conflicts are always avoidable. Fear of conflicts is a bigger problem than the conflicts themselves in my experience. What I'm saying is that the information necessary for any member of the team to fix a functionality broken by a conflict *had* to be merged in with that functionality, back when it was added. Otherwise it's just not done. As for IDEs, their insistence on using files which are a pain to edit manually is the main reason why I use Vim and CMake. – Kafein Feb 25 '20 at 10:14
@gnasher729 Developers need be able to raise issues, talk about problems and seek out help as and when problems/issues arise. It shouldn't be the case that they're expected to figure everything out by themselves without adequate support, and then only being able to find out that it's wrong at the code review stage after they've done a lot of the work already - that's a very inefficient way of working, and a sign of a broken process and/or serious problems within the team. – Ben Cottrell Feb 25 '20 at 17:06

score 19 · Answer 2 · answered Feb 21 '20 at 20:00

19

Practically speaking it is Person A, the branch owner.

In reality there will be branches C, D, E, and F that will now have conflicts with master, Person B won't be able to fix them all.

However, If you are working together merge conflicts should be easy to fix. After all you know what person B is attempting to do and will have discussed the needed changes at your daily scrum or whatever. So it wont be a surprise when they check in and you will understand why the conflicts have occured and how to fix them.

answered Feb 21 '20 at 20:00

Ewan

70,664
5
76
161

Keep in mind that some large codebases are handled by more than one scrum team and thus A and B may not be closely aware of each other's work. Even if they are aware of it, a daily isn't detailed enough for them to be aware of specific implementation details, which are generally the required knowledge to resolve (non trivial) merge conflicts. – Flater Feb 24 '20 at 00:04
@Flater I can't help bad project management – Ewan Feb 25 '20 at 14:11
Good management doesn't entail daily meetings to a degree of communicating implementation details for all pending tasks. – Flater Feb 25 '20 at 15:08
It does if you want to avoid working at cross purposes to some guy on another team in another country – Ewan Feb 25 '20 at 15:19

Mecki · Answer 3 · 2020-02-24T19:38:25.247

Generally the person who runs into the conflict also has to resolve it, after all it's the person who wants that merge to happen and resolving the conflict is required to make it happen.

In your sample that would be person A. It's person A who wants his code in the master branch. It's not person B who wants that code there. Person B just made changes to the branch and apparently they didn't conflict or if they did, he resolved the conflict. Assume person B had been much faster adding his changes, then person A would have had to deal with them already on his feature branch, wouldn't he? Well, now person A has do deal with them afterwards, which should just be a little bit of extra work.

If it is a lot of extra work as the conflict is huge, something went wrong completely. E.g. if two people implemented the same feature or contradicting features or one person worked on a feature while another one completely restructured the project, then there was some planing/management deficit in the preparation of these two code changes.

In that case, you need to discuss if resolving that conflict is even meaningful at all. Sometimes it just makes more sense to discard one of both changes completely (which one has to be discussed) and redo the work on the new code base because solving the conflict would be at least an equal amount of work. Sometimes another change may even make a feature obsolete or require it to work completely different manner as it has been designed. In that case merging alone will not get you anywhere, as you will still have to make a huge amount of extra adoptions after the merge and these alone may equal the work to re-implement that feature on the new code base from scratch.

As a general development tip:
If you have a long running feature branch, keep merging the master branch into that feature branch on a regular basis. This prevents the two branches from developing too far apart and makes the final merge much easier. Also you will quickly see if there is something going on on the master branch that will conflict with the way how you intend to implement that feature. It's then up to you to stop the people who currently mess with the master branch and discuss how to proceed with that situation, or to just adopt your implementation strategy to their changes.

An example for the later case: You planned to make it synchronous, they currently make everything asynchronous on the master branch, then you should also implement that feature asynchronously following the same pattern that they use. By merging their changes into your feature branch, you may even have some new, useful methods available that they added to the master branch and that makes it much easier for you to now implement your planned feature in an asynchronous fashion. If you had just focused on the feature branch, your feature will be done one day and it will be synchronous, then you try to merge it, just to find out, that everything in the project has changed and even if you can resolve that merge conflict, it won't buy you a lot as you will still have to make your feature asynchronous now and that may as well equal rewriting it from scratch.

Especially important is the last paragraph: Yes, if the conflict is huge, something went wrong with the planning of the various features/bug fixes/refactorings/whatever that were going on simultaneously. You should have done it differently. (Speaking as one who has _failed_ to do it differently far too many times now ... but maybe, just maybe, I've finally learned that lesson ...) — davidbak, Feb 22 '20 at 19:17
And this is also why you want to keep your features/branches small - any conflicts will likewise be kept small, and easy to manage. — Baldrickk, Feb 24 '20 at 15:42

score 4 · Answer 4 · answered Feb 22 '20 at 08:35

In most development processes which have a "master" branch, it is the responsibility of anyone making changes to do the merges required.

The "master" branch is a privileged branch in the sense that it is the "current best version" of the software. Once changes are merged into it, there is an expectation that they will be preserved, as they are now the current best version.

This is not to say that there is never a case where "first past the post" is wrong. I have seen situations where A's changes are a higher priority than B, meaning they provide more value in a business sense. In this situation, B was simply not permitted to apply their changes to master until after A (making it B's responsibility to do the merge). This occurred because A's changes affected a highly contended file and were deemed essential to a release that was coming up. But you note, B did not commit their changes to master and then have to merge A's changes. B was forbidden from putting their changes on master until A had a chance.

There are pragmatic reasons for this, of course. It is often not reasonable to identify all of the potential "more important" changes being done on different branches. This would produce a great deal of uncertainty as to when B's changes were "complete," and that uncertainty is not desirable in modern development environments.

This being said, I have indeed worked on projects where the answer is that person C is responsible for the merge, where C was the build manager. Not that I think there should be a build manager who solves problems like these, but it does show that "who is responsible" is very dependent on how you develop.

This is the answer. If B's branch has been accepted into `master`, then A would typically be responsible for rebasing their own branch on the new head. — StackOverthrow, Feb 24 '20 at 16:20

gnasher729 · Answer 5 · 2020-02-25T10:04:01.940

It’s the responsibility of the person who wants to merge.

Obviously any changes that would have caused conflicts would have been reviewed before being merged, and if a change caused an unreasonable number of conflicts it would have been rejected.

Obviously A doesn’t merge into the main branch and then resolved conflicts. A merges the main branch into his development branch, resolves conflicts, and makes sure his branch works. At that point A has a branch that can be merged without conflicts into the main branch. The resulting code is reviewed then merged. If it is a complex change where the review takes long and has the risk of new conflicts appearing, A can ask his colleagues to hold of merging changes until A’s merge is done.

score 2 · Answer 6 · answered Feb 23 '20 at 21:08

2

If branch "A" and "master" have conflicts, merge "master" into "A" before opening the pull request.

This way, the review process isn't started unnecessarily early and you can clearly see and discuss all changes that "A" would introduce, whether they stem from resolving merge conflicts or feature development.

answered Feb 23 '20 at 21:08

knallfrosch

133
4

In git workflows, it's often better to rebase a local branch rather than merge. This shouldn't be done if the branch has been pushed anywhere though. – pjc50 Feb 24 '20 at 12:59
I think this is a given. The question is more to do with who fixes the conflicts. Does A do it (because it's their branch) or does B do it (because their merge to master created the conflicts). – adelphus Feb 24 '20 at 17:45

Whose responsibility is it to fix merge conflicts?

6 Answers6