Skip to content

Instantly share code, notes, and snippets.

Embed
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 git@github.com:USERNAME/FORKED-PROJECT.git

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 https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

# 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.

Submitting

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 "origin"]:

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 https://github.com/forkuser/forkedrepo.git 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

Copyright

Copyright 2017, Chase Pettit

MIT License, http://www.opensource.org/licenses/mit-license.php

Additional Reading

Sources

@rantoniuk
Copy link

rantoniuk commented May 21, 2019

  1. I think there's a typo in the Fetching pull requests section. That .git/config line should be rather placed under upstream section rather than origin, as the PR are against upstream, right? ;-)

@gcolvin: There's really no practical difference. Doing git pull is essentially the same as doing git fetch followed by git merge.

  1. I'm wondering, why nobody is mentioning git pull --rebase as a way to sync fork from upstream to origin ? Doing a merge creates additional merge commit, doesn't it?

EDIT:
I know saw your comment @Chaser324:

@gcolvin: There's really no practical difference. Doing git pull is essentially the same as doing git fetch followed by git merge.

Well... with git pull --rebase there is a difference ;-)

@mhuisman
Copy link

mhuisman commented Jun 11, 2019

Good stuff, thank you

@jonmitll
Copy link

jonmitll commented Jun 19, 2019

@Chaser324:

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.

I'm way late to this, but isn't a pull request for a FF merge easier to manage than one with a merge commit? Even if that's not the case, I strongly disagree with the idea that VCS implies a persistent historical record. If you feel that way, you should be using SVN, not git. The entire design of git completely rejects your idea that a VCS needs to be a persistent historical record.

@TripeHound
Copy link

TripeHound commented Jul 15, 2019

@Chaser324

Great article. Some questions... I've created a fork of an existing repo to make some changes mainly for my own use. The original doesn't appear to be actively maintained, but I don't want to preclude either pulling updates from it, should they be made, nor creating a pull-request from my changes, should I get them to a fit state.

My first thought is to keep my master branch a clean copy of the upstream repo (but see below); a develop branch (I think acting similarly to your pending-master branch) that will be my working copy, with all my changes on. Those changes would originally have been created as branches from develop and merged back on to it.

My two potential problems:

  1. If I do a bunch of changes, even if I started with separate branches for each one (and potentially separate sources of pull-requests), I suspect it would be hard to keep things isolated. I might change one part of the original for feature1 but also use that change in feature2. Are there ways of keeping things separate, or does it just get to the point where I'd have to roll-up all my changes in one PR?

  2. Should anyone should happen to stumble over my forked-repo, they will (from my limited experience) "land" on master, which will be a mirror of the original repo, including the original README.md. If I change the copy in my master (so that it's visible) to explain why I created the fork, what my changes do (and, for example, that they're on the develop branch) will this cause a problem if/when I ever created a PR? Some of the changes, describing new features, might want to make it into the original, but other bits wouldn't. Do I just leave it to the upstream maintainer to sort out, or is there a better approach?

@Nilpo
Copy link

Nilpo commented Aug 17, 2019

  1. If I do a bunch of changes, even if I started with separate branches for each one (and potentially separate sources of pull-requests), I suspect it would be hard to keep things isolated. I might change one part of the original for feature1 but also use that change in feature2. Are there ways of keeping things separate, or does it just get to the point where I'd have to roll-up all my changes in one PR?

The best advice I can give you is to keep your commits small and frequent. Then don't squash them into huge chunks. This will make merging far easier. But if you are making such sweeping changes, you may be better of just maintaining a true fork. Otherwise, you should submit PRs one at a time and wait for them to be approved in order. Or combine them into a single PR. The project owner will probably prefer the first method.

  1. Should anyone should happen to stumble over my forked-repo, they will (from my limited experience) "land" on master, which will be a mirror of the original repo, including the original README.md. If I change the copy in my master (so that it's visible) to explain why I created the fork, what my changes do (and, for example, that they're on the develop branch) will this cause a problem if/when I ever created a PR? Some of the changes, describing new features, might want to make it into the original, but other bits wouldn't. Do I just leave it to the upstream maintainer to sort out, or is there a better approach?

If you are going to keep your repo public, keep a true fork. Your master branch contains your working version of the project. You'll probably want to keep a branch of your own up to date that is an exact copy of the upstream project. Contributions to the original project would be created in branched off of the copy, not your master. Your master branch is yours then. You can bring in any changes you like either from the upstream project, your own code, or contributions to your fork by others. But you should make sure your README clearly identifies your project as a fork with a description of what makes your variation unique.

@nerdlabs001
Copy link

nerdlabs001 commented Sep 2, 2019

Greetings. does anyone know if there is a way to put in a pull request to all forks from my main repo at once?

@Outright-Graham
Copy link

Outright-Graham commented Oct 10, 2019

Thank you Chaser324. I'm a noob in git and will use this as a resource. I really appreciate it - have a good one!

@Nilpo
Copy link

Nilpo commented Oct 11, 2019

@nerdlabs001 Not directly. But if you had a list of forks you could script it. Have you looked at Hub?

https://github.com/github/hub

It's kind of bad practice though. You shouldn't make PRs to forks of your project. It will make merging a nightmare when they pull upstream changes that include the work in your PR.

@namgang
Copy link

namgang commented Oct 30, 2019

Kudos from a latecomer who appreciated your thinking and writing style.

@pnlph
Copy link

pnlph commented Dec 19, 2019

Thank you so much, simple and clear written. I have a question, though.

When is it safe for the person submitting the pull request to delete the develoment branch from the fork?

  1. after sumbmitting the PR?
  2. when the PR is accepted upstream?
  3. when the PR is merged upstream?

@libuda
Copy link

libuda commented Mar 22, 2020

Thanks a lot for this summary...I really had some trouble to understand how to work within Github as I was used to work in Gitlab. This article is a great help...thanks again :)

@jackson-elfers
Copy link

jackson-elfers commented Mar 22, 2020

@pnlph Typically you'd want to keep your branch until it's merged or closed.

@Nitn-Yewale
Copy link

Nitn-Yewale commented Apr 1, 2020

Excellent write up and very helpful. Thank you!

@ebertland
Copy link

ebertland commented Apr 11, 2020

Does anybody know if there is a way to avoid having to do the workflow described here?
https://gist.github.com/Chaser324/ce0505fbed06b947d962#gistcomment-2059020

If I am submitting multiple separate pull requests, each fixing one issue, to upstream, and they can be applied without conflicts, there should be a simple way to specify this in GitHub itself. This is the right way to do it if I am going to email a patch set, but I would expect GitHub to provide an easier way. I am doing local branch manipulations purely to get a clean pull request; it has no benefit to my local workflow.

@davidkern13
Copy link

davidkern13 commented Aug 9, 2020

Great very helpful! Thanks 👍

@swquader
Copy link

swquader commented Dec 7, 2020

Thank you! This alongside the Atlassian article you linked cleared up a lot for me.

@dfkettle
Copy link

dfkettle commented Jan 10, 2021

I've just set up my first repository (I've never used Github or git before, except to download other people's code). I want to make some changes to my code, but when I try to create a fork (on Github), it tells me "Cannot fork because you own this repository and are not a member of any organizations". Well, it's true that I'm not a member of any organization, I'm just a single developer working on my own. What am I doing wrong? Is my repository set up incorrectly? Don't I need to create a fork? I'm somewhat confused.

@swquader
Copy link

swquader commented Jan 10, 2021

@dfkettle This workflow is meant for working on projects with others. If you're working on your own project, you can skip making forks. Just make changes directly onto your repository. The only steps from here you need to worry about are under "Doing Your Work" to create branches for new features. Once you're done making changes in your branch, you can create a pull request in Github to merge your updated branch into the master branch.

Try Googling "git workflow solo developer".

@dfkettle
Copy link

dfkettle commented Jan 10, 2021

@swquader Thanks.

@ssill2
Copy link

ssill2 commented May 21, 2021

so I'll admit I'm a git n00b.

I have the following real case I'd like to accomplish.
I have a fork of the following github project: https://github.com/ldthomas/apg-java
This project I forked from has one branch, master.
My fork is at https://github.com/ssill2/apg-java
I have created a branch of master called "maven" and made a number of changes there.

I've been coordinating with the author of the project I forked from. We'd like to take the branch called "maven" in my fork and somehow bring that branch to his repo without affecting master. I looked at the pull request stuff but it seems like maven needs to exist in his repo for this to work. Is this possible? I feel like it should be given the way that git works, or at least how I understand it to work lol

@LucasLarson
Copy link

LucasLarson commented May 21, 2021

I have a fork of the following github project: https://github.com/ldthomas/apg-java
This project I forked from has one branch, master.
My fork is at https://github.com/ssill2/apg-java
I have created a branch of master called "maven" and made a number of changes there.

We'd like to take the branch called "maven" in my fork and somehow bring that branch to his repo without affecting master.

@ssill2:

You’re looking for
github.com/ssill2/apg-java/pull/new/maven, which I found by going to your branch’s GitHub page
github.com/ssill2/apg-java/tree/maven where there’s a message like

This branch is 9 commits ahead of ldthomas:master.

You want the “Contribute” button next to it which will send you to the form where you can suggest that your changes be merged into
github.com/ldthomas/apg-java/tree/master.

@ssill2
Copy link

ssill2 commented May 21, 2021

oh that sounds exactly like I'm looking for.

The original author doesn't want to merge my branch into master just yet, but he's definite interested in having my maven branch as part of his repo.

I'll give this a go. Thank you!

@ssill2
Copy link

ssill2 commented May 21, 2021

Ok, I think I was on the right track before, but is throwing me:
image

The way that seems to read is that it's going to merge to master which is what I'm trying to avoid. Or am I just reading that incorrectly?

@ebertland
Copy link

ebertland commented May 21, 2021

Ask the original author to create a new branch. Then you open a pull request from your fork+branch to this new branch rather than master.

@ssill2
Copy link

ssill2 commented May 21, 2021

yeah that's what I was thinking too. thanks!

@davan690
Copy link

davan690 commented Aug 28, 2021

Hi,

Just wondering if it is just about changing master to main now the default for Github git init is now the main branch, not the master branch/ https://github.com/github/renaming#new-repositories-use-main-as-the-default-branch-name

New repositories use main as the default branch name
The default branch name for new repositories created on GitHub is now main. To set a different default:

For users, on the https://github.com/settings/repositories page
For organization owners, on the https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults page
For enterprise administrators, on the https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges page
Users, organizations, and enterprises that previously selected a default branch for new repositories are not impacted by this change. Existing repositories are also not impacted by this change.

Why main?
main is the most popular replacement for master that we're seeing across GitHub. We like it because it's short, it keeps your muscle memory intact, and it translates well across most languages. We're using main for our newly-created repositories and for the repositories we're moving now, like dependabot-core.

@Chaser324
Copy link
Author

Chaser324 commented Aug 30, 2021

@davan690 Good suggestion. I'll update this post to reflect the new default branch naming later this week.

@jamesjohnmcguire
Copy link

jamesjohnmcguire commented Dec 8, 2021

Nice Work!

I have been wondering about the process of submitting an issue, like a bug report, while also submitting a PR that includes a fix for that issue. If you have any thoughts about this, it would be great to expand upon it in the article.

@thomas-robinson
Copy link

thomas-robinson commented May 19, 2022

It looks like this could use an update: changing master to main.

@XsongyangX
Copy link

XsongyangX commented Jun 16, 2022

How can you add commits to the incoming pull request and push it to the pull/origin/#PRNUMBER branch?

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