Using pull requests on a single-developer project
The pull request workflow might seem unnecessary for projects with one developer, but it offers security, testing, and feedback benefits.
Karly Nelson
July 9, 2025
It’s easy to forget how many software projects — both in industry and open source — effectively have only a single developer. In those cases, the developer often chooses to make commits directly to the main branch, or to merge their development branch locally before pushing. I used to do that myself, but I’ve seen the benefits of using a pull request workflow, even when I’m the only developer.
Kusari Inspector
The best reason to use a PR-based workflow when you’re the only developer is Kusari Inspector. Our supply chain security tool will check your changes for vulnerable dependencies, accidentally-committed secrets, and other potential risks that you might have missed. You’ll only get this if you submit your changes through a pull request.
Kusari Inspector catches issues deeper in your dependency graph that humans often can’t take time to research, so it works great to augment your human reviewers. But if you don’t have human reviewers, then it’s even more important that you have someone (a cute avocado with a fedora and a magnifying glass, in this case) watching your code.
Other benefits
Let’s pretend for a moment that Kusari Inspector didn’t already convince you. There are plenty of other reasons that using pull requests is preferable to making direct commits.
One reason is that it makes you look at your changes slightly differently. It’s easy to get on cruise control when making a commit (especially if you use `git commit -a`) and not notice that you’ve accidentally added files that you didn’t intend to. When you open the pull request, you see it presented in a different way than you do in your terminal or IDE. This new perspective can highlight changes you didn’t mean to include. It’s much cleaner on your commit history to fix it up before merging.
Another reason is the ability to run tests, linters, and other code quality checks automatically. Sure, nothing prevents you from running those yourself, but that requires you to remember to do it. Plus, it takes up resources on your machine that you could be using for something else, like playing Age of Empires. Automated CI workflows mean you test your code in the same way every time. You can also more easily test on an array of language versions, operating systems, etc. to help ensure that the code works for all of your supported platforms. Since CI environments aren’t reused, it can also catch “works on my machine” issues — no more forgetting to add a Python library to your project’s requirements.txt because you already had it installed for another project.
Lastly, just because you’re the only developer on a project, that doesn’t mean you’re the only person who can weigh in. Have a code change that you aren’t fully sure about? If you put it in a pull request, you can ask colleagues, users, and friends to review it and offer feedback. This allows you to proceed with other work until that particular change is ready. Of course, you can do that with a separate branch not in a pull request, but the pull request workflow makes feedback and discussion much easier to track.
If you’re the only developer on a project and you’re not using a pull request workflow, give it a try. It sounds like it’s just extra work, but it helps you find issues you wouldn’t notice otherwise. Plus, it’s a great habit to get in for the day when you get to add a second developer.
Learn more:
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?