Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

So I got started with a real project of mine on GitHub and things are going pretty well and ideas are flowing a lot faster than I initially thought. In order to keep things organized, I setup some branches so I can develop different features separately.

Now when I push my branch to GitHub, I have that section where I have two buttons : Pull Request and Compare with the name of the branch I recently pushed to. I understand the purpose of the Compare button but I don't get why I would want to create a pull request on my own repo.

Can someone explain me why I would do that? Is it useful to make pull request on my own repo if I am the only developer?

share|improve this question

5 Answers 5

up vote 10 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
I intentionally push my branches to github as I work from multiple computers and I want all of my code to be synced between them. Does knowing that change something to your answer ? – marco-fiset Dec 5 '12 at 17:44
@marco-fiset it should not change the answer. I'm not even sure exactly which pull request button you are referring to.. – David Cowden Dec 6 '12 at 7:03
You say "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". But not using pull requests does not mean not using branches. – Robert Norris Dec 6 '12 at 9:39

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.

share|improve this answer

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.

share|improve this answer
this seems to merely repeat points made and explained long time ago in top answer – gnat Jul 21 at 6:44
I disagree. Whilst the top answer is talking primarily about single vs shared repository, the discussion about pull is focused more on procedural and information sharing. My point is around maintaining consistent history. See for some more information. If someone is using a fork or clone of master and you re-write history, the parent they refer to may disappear. – Matthew Tippett Jul 22 at 7:12

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.

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 and you don't need pull requests to manage them.

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.

share|improve this answer

protected by gnat Jul 21 at 6:43

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.