Why you should use Pull Requests even if you are the only developer

Sometimes you will find yourself in a situation where you are the only developer working on a project. Maybe you are a freelancer, maybe you are working in a small company, or maybe you are working on a side or hobby project. Pull requests (PR, or merge requests, MR) are a feature offered by all major source code hosting service like GitHub, GitLab, Bitbucket, etc.

The way it usually works — if it’s a team working on the project — is that a developer creates a pull request on his fork (or branch) of the repository in order to notify others of changes he or she made, like a new feature for example. The person(s) interested can then

• review and discuss the code changes,
• ask for changes from the developer that create the pull request,
• push-follow up modifications,
• merge the changes to the (main) branch.

When looking at the points above, you might think that this requires at least two people or more. Well that’s only partially true. You can and should also use pull request if you are working on a project alone, and there are a couple of benefits:

Review your changes

The web interface for a pull request on the popular sites like GitHub and Gitlab has a list of all the modified, added or deleted files. But in addition to that, you will get a complete “diff” of what will be merged. This is very beneficial, especially when you want to merge a feature branch for example that is made up a lot of commits. So you will have the chance to review all the changes in one place.

Quality assurance

Yes, you can also do a code review on your own code. And pull requests (merge requests) are a great way to do it. Go over all the changes of your code again, and I’m pretty sure you will find something that is not OK from your point of view. Take this as a chance to improve the quality of your code:

• Add missing code comments for example, in case you spot an undocumented part of your code
• Check if you updated the README.md with regards to the new feature
• Watch out for potential side effects or regressions
• Think about things you might not have considered yet
• Etc.

Put on another hat

It’s a really good practice — if you are the only developer on a project — to “put on another hat” from time to time.

Doing a pull request is a good way to do that and look at your code from the perspective of a “reviewer”.

Run the CI

A pull request is also a great way to hook into your continuous integration (CI). Here’s some documentation from Travis CI. The CI will run before one branch is merged into another and you can consider the result of the CI job when reviewing the pull request.

Conclusion

I recommend using pull requests (merge requests) even if you are just a single developer working on project. This can improve the quality of the code an eliminate bugs that might appear later. And we all know that it’s much more effort to eliminate bugs later in the process of building a software product. What is you experience with using pull requests? Let me know in the comments!