For many (perhaps most) individual developers working on their own, creating pull requests is probably not worthwhile. However, I can think of at least one potential reason to do it:

Pull requests can be used to keep track of your project history more easily. A pull request has an issue ID which can be referred to from commit messages and in a change-log, which allows you to easily go back and find the merge point and set of merged commits for a particular change, without having to retain your feature branches indefinitely.

For example, in Pioneer (shameless plug), when we merge a pull request, we add an item to the changelog, with a one-line description of the change and a reference to the pull request ID. Of course, Pioneer has several developers, but the same mechanism could be useful for a developer working on his or her own.

This may be less useful if you decide to stick to a linear commit history (by rebasing your feature branches before merge, so that the merge can always be performed as a fast-forward), and if you are very disciplined about editing and squashing your commits before merging to master, because in that case the individual commit messages can be used as a changelog in themselves.

Pull requests are created so someone can review the work, make comments, suggestions, make or request edits and then merge the code to master.

In your case the someone is you.

As the sole developer you still should review your own work, refactor it and merge it to master when ready.

One approach I use a lot is to try to ‘put on another hat’, ‘try other personas’. So sit for a short while and place yourself in the situation of: newbie to the group; junior developer; colleague you respected in the past, etc. Try and look at it through their eyes and try to think of simply what could you do to make the change more obvious, better written with even better names that avoid tribal and domain knowledge as much as possible.

So, as you have indicated, you should work in branches when you want to separate out features and changes that aren’t ready for master. You can do all that in branches (you don’t even need pull requests to manage them if you do the PR tasks anyway, but it may provide useful structure for you).

Also, I will sometimes find that my change isn’t working, but rather than the horror of trying to back it out from master, maybe now mixed with other master changes, I can just do it all in a branch which I can then ignore / delete if it starts to go wrong. This is a huge benefit.

So you should work in branches and not commit directly to master until you decide to merge the entire branch.

These are guidelines – and not rules – to follow. I intentionally break them sometimes. For example, yesterday I committed a typo fix to master.

5 years later update: All the above still works well for me. I’ve recently created many PRs that only I see and approve for myself. The process of having a PR helps me put on that ‘different hat’ to review my own work.

Frequent things I pick up in my code reviews of my own code:

• commented out code (this is very common)
• print (debug) statements
• missing or poor tests- missing abstractions
• poor naming
• edge cases
• parameter defaults

It sounds like you have remote branches as well as local branches. If you’re finding the overhead of that workflow too much, then you can always work on different features using local branches without pushing them.

It basically comes down to doing what works for you. Working with branches is a huge benefit to git, and github makes that really easy, but as a lone developer there isn’t a great need to use the pull request model and committing directly to master should work just fine. When your project eventually becomes incredibly successful and tens or hundreds of developers are working on it, you’ll find getting pull requests from their forks is a great way of keeping track of the project.

The reason that I do it, is that it is a convenient way to make sure that all automated checks pass (it compiles, it has correct formatting, unit tests pass…).

I don’t necessarily require all checks to pass for each commit, but I do want the head of the main branch to always pass checks. I think pull requests are the easy way (perhaps not the only one).

More generally, it is a way to connect hooks to complete changes. Tests are an example; @John mentioned creating release notes as another example.

Pull requests would usually be used for either code reviews or contributions from users with their own fork of the project – for a single developer on a project I don’t really see a purpose.

Pull requests vs git push ultimately come down to one of individual or shared history. The main repository is the source for all changes, if others are pulling from and potentially making local changes, then a push request can cause those users issues as the tree they are deriving from changes.

The pull request model (either from custom branches or personal repositories) serves as a way to provide consistent history for all those using and deriving from the code.

Part of the reason you are putting code on github would be to make the code available for forking, and pull requests. You never known when it will happen, and keeping your co-developers histories consistent would be a big plus.