Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
GitHub Standard Fork & Pull Request Workflow

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:

# Clone your fork to your local machine
git clone

Keeping Your Fork Up to Date

While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:

# Add 'upstream' repo to list of remotes
git remote add upstream

# Verify the new remote named 'upstream'
git remote -v

Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:

# Fetch from upstream remote
git fetch upstream

# View all branches, including those from upstream
git branch -va

Now, checkout your own master branch and merge the upstream repo's master branch:

# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master

If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - see the next section, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.

Now, your local master branch is up-to-date with everything modified upstream.

Doing Your Work

Create a Branch

Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.

To create a new branch and start working on it:

# Checkout the master branch - you want your new branch to come from master
git checkout master

# Create a new branch named newfeature (give your branch its own simple informative name)
git branch newfeature

# Switch to your new branch
git checkout newfeature

Now, go to town hacking away and making whatever changes you want to.

Submitting a Pull Request

Cleaning Up Your Work

Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.

If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.

# Fetch upstream master and merge with your repo's master branch
git fetch upstream
git checkout master
git merge upstream/master

# If there were any new commits, rebase your development branch
git checkout newfeature
git rebase master

Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:

# Rebase all commits on your development branch
git checkout 
git rebase -i master

This will open up a text editor where you can specify which commits to squash.


Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.

Accepting and Merging a Pull Request

Take note that unlike the previous sections which were written from the perspective of someone that created a fork and generated a pull request, this section is written from the perspective of the original repository owner who is handling an incoming pull request. Thus, where the "forker" was referring to the original repository as upstream, we're now looking at it as the owner of that original repository and the standard origin remote.

Checking Out and Testing Pull Requests

Open up the .git/config file and add a new line under [remote "orgin"]:

fetch = +refs/pull/*/head:refs/pull/origin/*

Now you can fetch and checkout any pull request so that you can test them:

# Fetch all pull request branches
git fetch origin

# Checkout out a given pull request branch based on its number
git checkout -b 999 pull/origin/999

Keep in mind that these branches will be read only and you won't be able to push any changes.

Automatically Merging a Pull Request

In cases where the merge would be a simple fast-forward, you can automatically do the merge by just clicking the button on the pull request page on GitHub.

Manually Merging a Pull Request

To do the merge manually, you'll need to checkout the target branch in the source repo, pull directly from the fork, and then merge and push.

# Checkout the branch you're merging to in the target repo
git checkout master

# Pull the development branch from the fork repo where the pull request development was done.
git pull newfeature

# Merge the development branch
git merge newfeature

# Push master with the new feature merged into it
git push origin master

Now that you're done with the development branch, you're free to delete it.

git branch -d newfeature


dhimmel commented Nov 4, 2016 edited

The first part of this guide assumes you're forking a GitHub repository which is referred to as the upstream remote. Therefore, the Accepting and Merging a Pull Request may be more useful from the perspective of checking out pull requests from upstream rather than origin?


Chaser324 commented Dec 15, 2016 edited

@dhimmel You may be right, but I guess my thought process when I was writing this was that I wanted to address the entire life cycle and workflow of a pull request. I added a little bit to the gist to clarify that the later section is written from the perspective of the original repo owner.

Apologies for the late reply...never noticed any sort of notification that someone had made a comment.

Also, wow, how does this have 100+ stars?! I mostly wrote this for myself as a reference when I forget something.

danhett commented Dec 15, 2016

This is a really handy thing! I get asked about this stuff a lot by people in my workshops who are learning, and concise references like this are gold. Gold star get! ^__^


Chaser324 commented Dec 15, 2016

@danhett. Nice! Glad you've found it helpful and that it's maybe helped out some budding new programmers.

So, does Now, go to town hacking away and making whatever changes you want to. mean that commits and pushes to the cloned fork are OK to do?

For submitting or pushing, the following command worked for me:

git push --set-upstream origin newfeature


Chaser324 commented Feb 20, 2017

@strobelight: Yeah. That's what I meant by that. After you've created a branch for your work, you can start committing to it and pushing to your fork. If you want to make a pull request, you would then later generate a pull request for the commits you've made on that branch.

This is a good article. I use this to rebase my newfeature on the latest changes in the upstream/master and upload to github:
git fetch upstream
git rebase upstream/master
git push -f origin newfeature

After that I recompile to make sure my new feature still works, then create a pull request. It works great, however it doesn't update your copy of the master branch.

Thanks for the article. Do you generally use a virtual environment for development? Could be really useful if you are using this library for other projects as well.


Chaser324 commented Apr 11, 2017

@fireballwayne - See the section above in my post titled "Cleaning Up Your Work" for a better approach to making sure you're up to date with the upstream master branch.

The set of commands you have listed there would in fact have the problem of not updating your copy of the master branch. Those commands are essentially pulling/merging directly from the upstream master to your feature branch skipping over your copy of the master branch. Beware of any time you're throwing that "-f" force argument into a push, it's a sign that what you're doing is probably not good.

The better workflow, as described above is to merge upstream/master into your copy of the master branch (this makes it now up to date) and then rebasing your feature branch against your master branch. The end result for your feature branch is the same, but with this process, your master branch is also consistent with the upstream repo.

@bendichter - I don't personally use a virtual environment all that often.

NaridaL commented Apr 13, 2017 edited

@Chaser324 If I have a PR which is rejected/pending, but I still want to have a complete version locally with all my changes, should I merge the branch into my local master? If I then create additional PRs, should I base them on upstream/master or my local master? Or would you recommend an alternative workflow?


Chaser324 commented Apr 13, 2017 edited

@NaridaL I would say that at least partly depends on whether or not you think there will be any significant overlap between your PRs. Always basing your PRs on the current upstream master is probably the safest bet, but if it's unlikely they'll touch the same files or code, you could possibly merge to your local master and base your PRs on that.

Another solid option would be to keep your master branch consistent with the upstream, but then create a branch off of that, let's call it pending-master, and do your PR work branched off of that. You can then merge to this pending-master all you want and still have the convenience of a clean master branch that's consistent with the upstream one. When you issue your PRs, you could then just rebase your PR branches onto the master. For example, you could have a setup like this:

---o---o---o---o master (consistent w/ upstream)
      o---o---o---o---o pending-master (merge/branch from this as much as you want)
                          o---o---o newfeature

When you're ready to issue the pull request, you could then rebase your newfeature branch onto master.

# Move newfeature branch onto master.
git rebase --onto master pending-master newfeature

This would give you something like this:

---o---o---o---o master
   |            \
   |              o´--o´--o´ newfeature
      o---o---o---o---o pending-master

NaridaL commented Apr 15, 2017 edited

@Chaser324 Thanks for the writeup!

marnen commented May 16, 2017

Thanks for the writeup, although I hate to see yet another guide recommending rebasing your feature branch (in general, merging works better).


Chaser324 commented May 25, 2017

Merging does have some benefits over rebasing in terms of safety and some other factors, but I generally think rebasing makes for a smoother and cleaner pull request workflow.

Here's a pretty good writeup from Atlassian on the subject:

wangf1 commented Jun 1, 2017 edited

Thanks! Very good article. I know how to create pull request by reading this article.
I have one finding:
In section "Checking Out and Testing Pull Requests", if I change the "origin" to "upstream", I can use same local repository checkout the pull request instead of clone the original github repository.

//In .git/config file
[remote "upstream"]
	url = https://***.git
	fetch = +refs/heads/*:refs/remotes/upstream/*
	fetch = +refs/pull/*/head:refs/pull/upstream/*

# Fetch all pull request branches
git fetch upstream

# Checkout out a given pull request branch based on its number
git checkout -b 999 pull/upstream/999

marnen commented Jun 2, 2017


I generally think rebasing makes for a smoother and cleaner pull request workflow.

I can't think of any respect—not one—in which this statement is accurate. It is just as easy to accept a pull request that contains merge commits, and as you acknowledge, rebasing is less safe than merging. In fact, I'd go further, and say that many uses of rebase make Git into something that is no longer a VCS (because it is not maintaining a persistent historical record).

So...I'm curious how you think rebasing makes pull requests "smoother and cleaner", because I don't even know where to begin with that claim.

Really useful thanks! Bookmarked.


Chaser324 commented Jun 5, 2017

@marnen Let's just chill out and keep things civil. I get that this is something that's debated, and I understand your point of view. This just maybe isn't the best place for having a back and forth on this.

This post is just a suggestion based on how I do things and how teams I've worked with have done things. I'd never claim that this is some sort of definitive post about the one and only way to do things. There are a lot of factors to consider, and it's up to individual teams to decide what works best for them.

Feel free to fork and create a different version of this post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment