Conflicting pull requests are one of the most subtle yet tedious and exhausting problems when working on open source software. At first glance, it seems like a simple technical issue that can be solved with the git rebase or git merge commands. But in practice, this often hides not only technical difficulties, but also human ones: misunderstandings, fatigue, fear of “breaking something,” or even conflicts within the team that are not visible from the outside.
A pull request (or PR for short) is a proposal for changes to the project code. Once a developer has finished working on a new feature or fix, they create a PR so that other participants can review it, comment on it, and, if everything is fine, merge the changes into the main branch (usually main or master). The problem arises when, between the moment the branch for the PR was created and the moment it is about to be accepted, some changes have already occurred in the main branch. Especially if these changes affect the same parts of the code as the changes in the PR. In this case, Git cannot automatically merge the code, and a “conflict” arises that must be resolved manually.
In theory, this is a simple task: someone (usually the PR author) must download the current state of the main branch, merge it with their work, resolve all conflicts in the code, test it, make sure nothing is broken, and resubmit the PR. But in reality, this can be very exhausting. First, if the PR has been pending for a long time (which often happens in large projects), there may be many conflicts. Sometimes you have to figure out someone else’s code or remember what you did a month ago. Second, if a developer is inexperienced, they may be afraid to do something wrong — especially if the commit history is confusing and Git scares them with error messages. Third, it is not always clear who should resolve these conflicts — the maintainer or the author. Often, no one takes the initiative, and the PR just hangs around for weeks.
Sometimes the maintainer asks the PR author: “Please pull the branch to the current main and resolve the conflicts.” This can be perceived as an annoying demand, especially if the author has already “finished” the work and does not want to return to it. Or they may not see the point in editing everything manually if there aren’t that many changes. The opposite can also happen: the author writes in the comments that they can’t figure out the conflicts and expects the maintainer to do it. But if the maintainer has dozens of other tasks, they may simply ignore the PR — especially if they don’t consider it critical.
This is especially hard on newbies. Imagine: someone is inspired by a project, figures it out, makes useful changes, passes the first review stage, and then — bam! — “conflict.” They don’t know what to do. They start Googling, come across articles about rebase, merge, force push — and get scared. Sometimes they just stop responding, abandon the PR, and their changes never make it into the main code. This demotivates and slows down the development of open source. As a result, we lose valuable contributors because of trivial branch conflicts.
There is another problem — logical conflicts. Git may say that technically everything is fine and the merge is possible, but in reality, the changes in two PRs may be incompatible. One developer changed the logic of a function, another added a new check, and together this causes a bug. Such things are not visible at all without a thorough manual review. If the maintainer is in a hurry and simply “merges” both PRs without in-depth analysis, the project may break.
In some cases, rebase is used, in others — merge. With rebase, the history looks cleaner, but it is more difficult to master. Merge is easier, but adds “junk” commits to the history. In large projects, there are special rules for when and how to use each method. Some even use bots that automatically rebase PRs if the author has enabled this option. But this does not work everywhere.
There is also an organizational side to it. When the project is informal and the team is small, such conflicts can simply be discussed in a chat or on a call. But in large open-source projects with dozens or hundreds of participants, this does not happen. PRs can hang around for six months, discussions can spread out into dozens of comments, and authors lose interest and leave. Gradually, the project loses momentum.
To avoid all this, good projects have pre-thought-out rules. First, working with small PRs is encouraged — the fewer changes, the less likely there will be conflict. Second, authors try to work on the basis of the latest version of the main branch to minimize problems. Third, the project has a CONTRIBUTING.md file that clearly states who should resolve conflicts, when they should be corrected, and how to push fixes.
But the most important thing is attitude. If project participants treat each other with respect, understand that everyone is doing this in their free time, and are willing to be patient or help out a little, even conflictual PR doesn’t become a problem. But if communication is poor and everyone expects others to do their work for them, any conflicts turn into a quagmire that no one wants to get out of.
Ultimately, conflicting pull requests are not just a technical issue in git. They reflect the communication culture within the project, the maturity of the team, and the quality of the processes. Behind the lines of code and commands are real people, their motivations, fears, fatigue, and desire to be useful. If you take this into account, conflicts can be turned not into obstacles, but into opportunities to improve teamwork.
