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?

  • 60
    It's always the responsibility of the non master branch owner to fix that of course. Commented Feb 21, 2020 at 17:52
  • 11
    How could B fix the conflicts when it is already merged? Commented Feb 21, 2020 at 18:35
  • 5
    There isn't really an answer. It's whatever you decide what the process should be.
    – Martin K
    Commented Feb 21, 2020 at 20:03
  • 30
    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
    Commented Feb 21, 2020 at 20:18
  • 7
    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
    Commented Feb 22, 2020 at 7:33

6 Answers 6


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.

  • 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
    Commented Feb 22, 2020 at 7: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. Commented Feb 22, 2020 at 8:56
  • 76
    @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... Commented Feb 22, 2020 at 8:59
  • 41
    @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. Commented Feb 22, 2020 at 9:11
  • 35
    @sanyash I consider knowing when to ask for help a valuable programming skill. Commented Feb 22, 2020 at 21:04

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.

  • 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
    Commented Feb 24, 2020 at 0:04
  • @Flater I can't help bad project management
    – Ewan
    Commented Feb 25, 2020 at 14:11
  • Good management doesn't entail daily meetings to a degree of communicating implementation details for all pending tasks.
    – Flater
    Commented Feb 25, 2020 at 15:08
  • It does if you want to avoid working at cross purposes to some guy on another team in another country
    – Ewan
    Commented Feb 25, 2020 at 15:19

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.

  • 2
    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
    Commented Feb 22, 2020 at 19:17
  • 2
    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
    Commented Feb 24, 2020 at 15:42

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. Commented Feb 24, 2020 at 16:20
  • The hard case is when first past the post is just completely wrong because B was rushed in while A was being carefully tested. By-passed required testing, by-passed review requirements, applied updates to wrong file, etc... Then A has the tough decision do try to fix B in the merge and invalidate all their careful testing. Or do they do a merge --ours, and let the author of B go back to the drawing board.
    – user6856
    Commented Apr 9 at 18:55
  • @user6856 While there are plenty of solutions to that, the one I've seen most often is that one reverts B first, then applies A (in a state where A's testing is valid), and then B has to come back and fix it.
    – Cort Ammon
    Commented Apr 10 at 4:07

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.


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.

  • 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
    Commented Feb 24, 2020 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
    Commented Feb 24, 2020 at 17:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.