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