PR = Pull Request, a common technique for requesting to “pull” ones code into the master branch.

A pull request workflow with code reviews goes a long ways towards facilitating great software development. Here are some of the top reasons I like to use them.

• It forces collaboration on code being merged (code reviews). This has many advantages. Most notably:
  • Code stability is increased since “dumb” mistakes are caught by a second pair of eyes.
  • Code quality is increased as engineers point out “tips” when they see something coded in a less than optimal way (or flat out wrong).
  • Developer growth from knowledge sharing is massive. Developers will make comments offering better ways to accomplish tasks, or correct other developers of fallacies.
• Facilitate constructive feedback through commenting on PRs. Giving feedback is hard. Feedback on someones code, which can be more personal than many realize, is a challenge every developer has to learn how to receive and give. GitHub makes it simple to provide feedback that is “code” focused, and not “you” focused. I.e. This line of code will do this. Not “your line of code will do this”.
• Provide a clear history of decisions made in PRs. GitHub will hold comments and discussions around various technical decisions that can be referenced.
• git history is cleaner which makes rolling back to older changes easier (highly recommend squash and merge feature for this on all PRs). This makes it possible to role code back by feature easily (can do it through github’s GUI even!), correct code, and merge back in.
• Manage code merges purposefully into the master branch. Don’t let team members merge in at will. This means there must be a person who is “responsible” for different areas.
• Greater and more clear ownership of code. The developer that creates the PR and addresses peer review feedback on the PR is the one that should have the final say about merging it. In other words, they are the ones responsible for clicking the “merge” button.
• In my experience, fixing conflicts is easier with this model. I believe there are two major reasons for this:
  • Firstly, pull request are meant to “stay close to master”. Meaning they shouldn’t be very large code changes that get merged in after a long time. They are intended to be a quick branch off master, a non-breaking finite amount of code with a defined purpose. As long as people aren’t developing in silo’s and all are holding close to master, conflicts many times don’t occur at all.
  • Secondly, a developer writing a pull request likely reviews the code of other PRs from different developers and understands what the current state of the code base is and what will go into it. This makes avoiding conflicts via pre-determined coordination possible or even flat out avoidance.
• Applicable for a smaller team - with pull request the development process in place, it is much easier to take away the ability for some developers to merge into master in the future. This is great so that someone (or multiple people) intimately familiar with the project can be the gatekeeper for code merging into master.
• Although a reason not of its own merit, the development models familiarity. Many if not most developers use this model of development, including the open source world of software. Developers joining the company are immediately familiar with the workings of the team and can get right to adding value. Also, for less experienced developers not having a clear defined process to contribute code will cause a slower start.

It is important to realize that it is a fundamental shift in how the software is written. In my experience, when projects are managed well, people are more careful about the code they merge into the project. If a project is in a poor state, an engineer might not think twice about the code they merge in; however, if the project is clean and has great documentation, then the engineer is much more likely to follow suit. This pays dividends for developer happiness (they take pride in their work) and the overall quality of the software.