Forking repositories is at the core of contributing to open source, and everyone does it just a little bit differently. So let's take a look at how I used to handle multiple pull requests on the same repository, the problems it presented and the solution to those problems.
The problem
Say I want to create 2 pull requests to solve 2 seperate issues on the repository octocat/test-project
. A lot of people would create their first just fine:
- Fork the repository on GitHub
- Clone the forked repository
- Make changes in the
master
branch - Push to the forked repository
- Open the pull request
Ok, that works. However, adding the second pull request changes the dynamic. Making changes to that same master
branch will affect the original (first) pull request, so let's not do that. Branching off of master
now will include the changes you've already made for PR #1. Some people might tell you to do the following:
- Fork the repository on GitHub again (this will create a
test-project-1
repository) - Clone the forked repository
- Make changes in that repository's
master
branch - Push to the forked repository
- Open the pull request
Obviously, if you wanted to open a third, fourth, or even a fifth pull request, this becomes unweildy. Did I make that change in test-project-2
or test-project-4
?
The solution
How could you combat this? Branching! When initially cloning the first repository, start by creating a branch for the thing your PR solves:
$ git checkout -b first-pull-request
This creates and checks out the first-pull-request
branch. Make your changes for PR #1 and push them to GitHub. You can now open your first PR on GitHub.
Adding a second PR couldn't be easier:
# Ensure you're on master!
$ git checkout master
$ git checkout -b second-pull-request
Again, make your changes and push them to GitHub. Now you can safely open the second pull request without having to worry about conflicting with the first one!
Top comments (0)