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

@dhimmel

This comment has been minimized.

Show comment Hide comment
@dhimmel

dhimmel Nov 4, 2016

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?

dhimmel commented Nov 4, 2016

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

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Dec 15, 2016

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

Owner

Chaser324 commented Dec 15, 2016

@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

This comment has been minimized.

Show comment Hide comment
@danhett

danhett 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! ^__^

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

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Dec 15, 2016

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

Owner

Chaser324 commented Dec 15, 2016

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

@strobelight

This comment has been minimized.

Show comment Hide comment
@strobelight

strobelight Feb 15, 2017

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?

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?

@arunksaha

This comment has been minimized.

Show comment Hide comment
@arunksaha

arunksaha Feb 18, 2017

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

git push --set-upstream origin newfeature

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

git push --set-upstream origin newfeature

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

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

Owner

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.

@fireballwayne

This comment has been minimized.

Show comment Hide comment
@fireballwayne

fireballwayne Mar 2, 2017

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.

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.

@bendichter

This comment has been minimized.

Show comment Hide comment
@bendichter

bendichter Mar 10, 2017

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.

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

This comment has been minimized.

Show comment Hide comment
@Chaser324

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

Owner

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

This comment has been minimized.

Show comment Hide comment
@NaridaL

NaridaL Apr 13, 2017

@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?

NaridaL commented Apr 13, 2017

@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

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Apr 13, 2017

@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
Owner

Chaser324 commented Apr 13, 2017

@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

This comment has been minimized.

Show comment Hide comment
@NaridaL

NaridaL Apr 15, 2017

@Chaser324 Thanks for the writeup!

NaridaL commented Apr 15, 2017

@Chaser324 Thanks for the writeup!

@marnen

This comment has been minimized.

Show comment Hide comment
@marnen

marnen 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).

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

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 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: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Owner

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: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

@wangf1

This comment has been minimized.

Show comment Hide comment
@wangf1

wangf1 Jun 1, 2017

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

wangf1 commented Jun 1, 2017

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

This comment has been minimized.

Show comment Hide comment
@marnen

marnen Jun 2, 2017

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

marnen commented Jun 2, 2017

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

@sledge909

This comment has been minimized.

Show comment Hide comment
@sledge909

sledge909 Jun 3, 2017

Really useful thanks! Bookmarked.

Really useful thanks! Bookmarked.

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 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 my personal preferences and how teams I've worked with have done things. I'd never claim that this is a definitive post about the one and only way that things must be done. 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.

Owner

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 my personal preferences and how teams I've worked with have done things. I'd never claim that this is a definitive post about the one and only way that things must be done. 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.

@thedude42

This comment has been minimized.

Show comment Hide comment
@thedude42

thedude42 Jun 24, 2017

The Atlassian article you mention talks about some pitfalls and good practices around the use of rebasing. Seems like it may be a good idea to reference those in this piece for folks casually finding your work, and who may not be inclined to read through all the comments. I found the Atlassian article a great folow-up after reading yours.

The Atlassian article you mention talks about some pitfalls and good practices around the use of rebasing. Seems like it may be a good idea to reference those in this piece for folks casually finding your work, and who may not be inclined to read through all the comments. I found the Atlassian article a great folow-up after reading yours.

@manpen

This comment has been minimized.

Show comment Hide comment
@manpen

manpen Jun 25, 2017

Thank you for the great summary!
There is a small typo in "Checking Out and Testing Pull Requests" which is hard to spot for copy/paste users as me:

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

manpen commented Jun 25, 2017

Thank you for the great summary!
There is a small typo in "Checking Out and Testing Pull Requests" which is hard to spot for copy/paste users as me:

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

@StoneyJackson

This comment has been minimized.

Show comment Hide comment
@StoneyJackson

StoneyJackson Jul 2, 2017

@Chaser324 Very nice! I've written something similar, but I prefer yours. Plus, with so many stars, yours has clear validation. Would you be willing to add a license, preferably an open license (e.g., creative commons, etc.)?

@Chaser324 Very nice! I've written something similar, but I prefer yours. Plus, with so many stars, yours has clear validation. Would you be willing to add a license, preferably an open license (e.g., creative commons, etc.)?

@BobCochran

This comment has been minimized.

Show comment Hide comment
@BobCochran

BobCochran Jul 4, 2017

Hi! I am really rusty with my git knowledge because I don't use it very often. Today, I forked another repository, set up my local repository of the fork, created a branch called page44, and went ahead to make some changes on that branch. Then I did a pull request for those changes. The PR is now pending. I kept thinking my PR must have a lot of clutter inside it because I renamed a source code directory and that was a bigger change than it seemed. I think I could have done a much cleaner pull request if I had followed your suggestions to @NaridaL and also tried rebasing like the Atlassian article suggests.

Hi! I am really rusty with my git knowledge because I don't use it very often. Today, I forked another repository, set up my local repository of the fork, created a branch called page44, and went ahead to make some changes on that branch. Then I did a pull request for those changes. The PR is now pending. I kept thinking my PR must have a lot of clutter inside it because I renamed a source code directory and that was a bigger change than it seemed. I think I could have done a much cleaner pull request if I had followed your suggestions to @NaridaL and also tried rebasing like the Atlassian article suggests.

@mapadofu

This comment has been minimized.

Show comment Hide comment
@mapadofu

mapadofu Jul 15, 2017

It would be nice if you included the explicit command(s) in the "Submitting" section
for those of us who are noobs and/or forgetful.

It would be nice if you included the explicit command(s) in the "Submitting" section
for those of us who are noobs and/or forgetful.

@siculars

This comment has been minimized.

Show comment Hide comment
@siculars

siculars Jul 20, 2017

Thanks for the writeup. Please include information on "desirable to squash some of your smaller commits down into a small number of larger more cohesive commits". Aka. squashing in interactive mode.

Thanks for the writeup. Please include information on "desirable to squash some of your smaller commits down into a small number of larger more cohesive commits". Aka. squashing in interactive mode.

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Jul 20, 2017

@thedude42: Thanks for the suggestion. I've added a link to that article to the post.
@manpen: Corrected. Thanks for pointing it out.
@StoneyJackson: I've added a copyright section to the post. Treat it as MIT licensed, so do as you like with it as long as you provide attribution.
@mapadofu @siculars: If I get an opportunity, I'll try to expand on the subjects of submitting and squashing commits.

Owner

Chaser324 commented Jul 20, 2017

@thedude42: Thanks for the suggestion. I've added a link to that article to the post.
@manpen: Corrected. Thanks for pointing it out.
@StoneyJackson: I've added a copyright section to the post. Treat it as MIT licensed, so do as you like with it as long as you provide attribution.
@mapadofu @siculars: If I get an opportunity, I'll try to expand on the subjects of submitting and squashing commits.

@paulbrittain

This comment has been minimized.

Show comment Hide comment
@paulbrittain

paulbrittain Jul 22, 2017

Great writeup thanks for sharing!

Great writeup thanks for sharing!

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Aug 1, 2017

@paulbrittain: Thanks.

Owner

Chaser324 commented Aug 1, 2017

@paulbrittain: Thanks.

@cweekly

This comment has been minimized.

Show comment Hide comment
@cweekly

cweekly Aug 9, 2017

Here's a related tip for using PR workflow when you're working with others on a fork -- say, "myfork" and not (yet?) ready to contribute back upstream to the original / canonical repo (call it "canonical") which someone else maintains.

In .gitconfig remote, designate the canonical repo as "upstream", whereas the shared fork is "origin".
Locally, clone the origin, create topic branches and push to origin.
Then to manage changes via PR, on the myfork origin repo, in the GH UI, when you first trigger "Open a Pull Request" note the default base for comparison will be the canonical upstream. Simply select a different base repo in the dropdown (e.g. base fork: myfork and base branch:master -- not default base fork: canonical). Using PRs and disposable feature branches to manage changes is pretty universally recognized as a solid idea, but it may be tricky for newer git users working against a fork to figure out how to use PRs outside the context of "giving back" to the original repo. HTH.

PS As for the merging vs rebasing debate, it's out of scope here but I do want to both thank @Chaser324 for publishing his take on it, but also, respectfully, to echo @marnen 's caution against using rebase if you're not sure what you're doing.

cweekly commented Aug 9, 2017

Here's a related tip for using PR workflow when you're working with others on a fork -- say, "myfork" and not (yet?) ready to contribute back upstream to the original / canonical repo (call it "canonical") which someone else maintains.

In .gitconfig remote, designate the canonical repo as "upstream", whereas the shared fork is "origin".
Locally, clone the origin, create topic branches and push to origin.
Then to manage changes via PR, on the myfork origin repo, in the GH UI, when you first trigger "Open a Pull Request" note the default base for comparison will be the canonical upstream. Simply select a different base repo in the dropdown (e.g. base fork: myfork and base branch:master -- not default base fork: canonical). Using PRs and disposable feature branches to manage changes is pretty universally recognized as a solid idea, but it may be tricky for newer git users working against a fork to figure out how to use PRs outside the context of "giving back" to the original repo. HTH.

PS As for the merging vs rebasing debate, it's out of scope here but I do want to both thank @Chaser324 for publishing his take on it, but also, respectfully, to echo @marnen 's caution against using rebase if you're not sure what you're doing.

@gcolvin

This comment has been minimized.

Show comment Hide comment
@gcolvin

gcolvin Aug 25, 2017

I'm wondering how your fetch and merge approach to keeping forks up to date is different than just git pull?

gcolvin commented Aug 25, 2017

I'm wondering how your fetch and merge approach to keeping forks up to date is different than just git pull?

@jordanlui

This comment has been minimized.

Show comment Hide comment
@jordanlui

jordanlui Sep 1, 2017

Great guide! Helped me through my first pull request!

Great guide! Helped me through my first pull request!

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Sep 5, 2017

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

Owner

Chaser324 commented Sep 5, 2017

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

@LightCC

This comment has been minimized.

Show comment Hide comment
@LightCC

LightCC Sep 11, 2017

Before the final pull request, why would you rebase your feature branch onto master, rather than merging master into your feature branch? That creates the same effect - makes the pull request from the feature branch guaranteed to be able to merge into master by making you solve any conflicts, but does so in a way that doesn't push unneeded crap onto your master that you might have to clean-up later. It also sets up your feature branch so that if any changes are needed due to maintainer requests on the pull request, that you can just continue committing to feature.

I wouldn't want to ever merge anything to my fork's master - in fact, Like you said - always work on a branch. If the pull request is accepted, I'll just get the final update to my master from upstream rather than do a merge myself to it. That way my master is clean to always just pull from upstream.

Am I missing something?

LightCC commented Sep 11, 2017

Before the final pull request, why would you rebase your feature branch onto master, rather than merging master into your feature branch? That creates the same effect - makes the pull request from the feature branch guaranteed to be able to merge into master by making you solve any conflicts, but does so in a way that doesn't push unneeded crap onto your master that you might have to clean-up later. It also sets up your feature branch so that if any changes are needed due to maintainer requests on the pull request, that you can just continue committing to feature.

I wouldn't want to ever merge anything to my fork's master - in fact, Like you said - always work on a branch. If the pull request is accepted, I'll just get the final update to my master from upstream rather than do a merge myself to it. That way my master is clean to always just pull from upstream.

Am I missing something?

@multi-io

This comment has been minimized.

Show comment Hide comment
@multi-io

multi-io Sep 13, 2017

Is it possible to create a pull request for a project that you've forked manually, rather than via the "Fork" button?

Like, if you manually clone the upstream project and push it to a newly created project in your profile. Another situation where this may come up is an original project having multiple 3rd party forks/variants that you've all integrated into one project of your own and want to send pull requests to.

Is it possible to create a pull request for a project that you've forked manually, rather than via the "Fork" button?

Like, if you manually clone the upstream project and push it to a newly created project in your profile. Another situation where this may come up is an original project having multiple 3rd party forks/variants that you've all integrated into one project of your own and want to send pull requests to.

@gcolvin

This comment has been minimized.

Show comment Hide comment
@gcolvin

gcolvin Sep 16, 2017

Thanks @Chaser324

@LightCC I think it depends on the workflow your team has chosen. If they have chosen this one, yours won't work. I don't really know how, I just know it got ugly as only git can.

gcolvin commented Sep 16, 2017

Thanks @Chaser324

@LightCC I think it depends on the workflow your team has chosen. If they have chosen this one, yours won't work. I don't really know how, I just know it got ugly as only git can.

@marcschoeni

This comment has been minimized.

Show comment Hide comment
@marcschoeni

marcschoeni Sep 26, 2017

extremely helpful thanks.

extremely helpful thanks.

@lirantal

This comment has been minimized.

Show comment Hide comment
@lirantal

lirantal Sep 28, 2017

@LightCC you didn't miss anything and you're definitely right. the local repo 'master' branch should only be used as a tunnel to get new work from upstream, there's no reason to merge anything to it. Moreover, if you're extreme about it, one can even delete the local repo's master branch completely and just branch out of upstream/master for a new branch.

@LightCC you didn't miss anything and you're definitely right. the local repo 'master' branch should only be used as a tunnel to get new work from upstream, there's no reason to merge anything to it. Moreover, if you're extreme about it, one can even delete the local repo's master branch completely and just branch out of upstream/master for a new branch.

@dagolinuxoid

This comment has been minimized.

Show comment Hide comment
@dagolinuxoid

dagolinuxoid Oct 24, 2017

@Chaser324 in a Create Branch section using a git checkout -b newfeature looks more appealing (at least to me coz I really rarely use two separate commands git branch newfeature and git checkout newfeature) , even though it is understandable that you didn't combine it in one single step — because of absolute newcomers I suppose. This moment wen you want to make a pull request but than realize that it's just a gist ^^.

dagolinuxoid commented Oct 24, 2017

@Chaser324 in a Create Branch section using a git checkout -b newfeature looks more appealing (at least to me coz I really rarely use two separate commands git branch newfeature and git checkout newfeature) , even though it is understandable that you didn't combine it in one single step — because of absolute newcomers I suppose. This moment wen you want to make a pull request but than realize that it's just a gist ^^.

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Nov 10, 2017

@dagolinuxoid Yeah. I think most people, myself included, typically will do that in one step. As you noted though, I thought making them two separate steps would make it clearer what's happening.

Owner

Chaser324 commented Nov 10, 2017

@dagolinuxoid Yeah. I think most people, myself included, typically will do that in one step. As you noted though, I thought making them two separate steps would make it clearer what's happening.

@poenneby

This comment has been minimized.

Show comment Hide comment
@poenneby

poenneby Nov 19, 2017

Thanks for this writeup!

Thanks for this writeup!

@IMarvinTPA

This comment has been minimized.

Show comment Hide comment
@IMarvinTPA

IMarvinTPA Jan 9, 2018

A few things that could be added for the complete git newbie is how to commit and push your changes on your local machine back to github.
git commit -a -m "Your comment goes here as this command will commit all of your changes and tag them with this statement."
"git push --set-upstream origin newfeature" will send it back to the origin and create the branch there too.

A few things that could be added for the complete git newbie is how to commit and push your changes on your local machine back to github.
git commit -a -m "Your comment goes here as this command will commit all of your changes and tag them with this statement."
"git push --set-upstream origin newfeature" will send it back to the origin and create the branch there too.

@t0tem

This comment has been minimized.

Show comment Hide comment
@t0tem

t0tem Jan 10, 2018

@Chaser324 thannks a lot for this guide, that's very helpful!

t0tem commented Jan 10, 2018

@Chaser324 thannks a lot for this guide, that's very helpful!

@ElectricRCAircraftGuy

This comment has been minimized.

Show comment Hide comment
@ElectricRCAircraftGuy

ElectricRCAircraftGuy Jan 16, 2018

For noobs, can you please clarify "Once you've committed and pushed all of your changes to GitHub" by showing the push commands too?

For noobs, can you please clarify "Once you've committed and pushed all of your changes to GitHub" by showing the push commands too?

@superdyzio

This comment has been minimized.

Show comment Hide comment
@superdyzio

superdyzio Jan 20, 2018

@Chaser324 thanks for that!

I have a question - let's say I've forked something, did my job, send pull request which was accepted and merged and then what happens with my work? Is it automatically removed from my repositories, as its job is done and code is merged to original repository or does it stay in my repositories and I can do whatever I want with it without impacting my contribution to original repository?

@Chaser324 thanks for that!

I have a question - let's say I've forked something, did my job, send pull request which was accepted and merged and then what happens with my work? Is it automatically removed from my repositories, as its job is done and code is merged to original repository or does it stay in my repositories and I can do whatever I want with it without impacting my contribution to original repository?

@Chaser324

This comment has been minimized.

Show comment Hide comment
@Chaser324

Chaser324 Jan 24, 2018

@IMarvinTPA @ElectricRCAircraftGuy - Good suggestion. I should better clarify that for the sake of people that are completely new to git.

@superdyzio - Once your pull request has been accepted and merged, you're free to do whatever you want with your fork. You can delete your dev branch or delete the fork entirely without impacting the original upstream repo. Likewise, the pull request being accepted and merged won't automatically cause any change in your forked repo either.

Owner

Chaser324 commented Jan 24, 2018

@IMarvinTPA @ElectricRCAircraftGuy - Good suggestion. I should better clarify that for the sake of people that are completely new to git.

@superdyzio - Once your pull request has been accepted and merged, you're free to do whatever you want with your fork. You can delete your dev branch or delete the fork entirely without impacting the original upstream repo. Likewise, the pull request being accepted and merged won't automatically cause any change in your forked repo either.

@tdrisdelle

This comment has been minimized.

Show comment Hide comment
@tdrisdelle

tdrisdelle Feb 21, 2018

Awesome work @Chaser324, I really appreciate your diligence on this thread.

Awesome work @Chaser324, I really appreciate your diligence on this thread.

@phuochau

This comment has been minimized.

Show comment Hide comment
@phuochau

phuochau Mar 8, 2018

@Chaser324 it's really helpful, thanks so much

phuochau commented Mar 8, 2018

@Chaser324 it's really helpful, thanks so much

@DTV96Calibre

This comment has been minimized.

Show comment Hide comment
@DTV96Calibre

DTV96Calibre Mar 18, 2018

Also, wow, how does this have 100+ stars?!

@Chaser324 Almost at 1000 stars!
Thanks for the guide!

Also, wow, how does this have 100+ stars?!

@Chaser324 Almost at 1000 stars!
Thanks for the guide!

@nareddyt

This comment has been minimized.

Show comment Hide comment
@nareddyt

nareddyt Mar 19, 2018

@Chaser324 great tutorial! Just one comment: It would be helpful to describe where the "Fork" button is (upper-right corner) so that new users don't have to search for it.

nareddyt commented Mar 19, 2018

@Chaser324 great tutorial! Just one comment: It would be helpful to describe where the "Fork" button is (upper-right corner) so that new users don't have to search for it.

@samsammurphy

This comment has been minimized.

Show comment Hide comment
@samsammurphy

samsammurphy Mar 27, 2018

Thank you ^_^

Thank you ^_^

@gstanden

This comment has been minimized.

Show comment Hide comment
@gstanden

gstanden Apr 4, 2018

Great article so helpful thank you!
Adding some comments mostly for my own use but also in case they help others:

  • After "git rebase -i master": do "git push origin newfeature": because (my newfeature, ready for pull, had never been pushed from remote)
  • After pressing "Pull Request" button, review request, scroll to top, add comment (if any) and press "Send Pull Request".
  • After pressing "Send Pull Request" go to original repo that was forked and confirm your pull request appears there.

gstanden commented Apr 4, 2018

Great article so helpful thank you!
Adding some comments mostly for my own use but also in case they help others:

  • After "git rebase -i master": do "git push origin newfeature": because (my newfeature, ready for pull, had never been pushed from remote)
  • After pressing "Pull Request" button, review request, scroll to top, add comment (if any) and press "Send Pull Request".
  • After pressing "Send Pull Request" go to original repo that was forked and confirm your pull request appears there.
@laurafchen

This comment has been minimized.

Show comment Hide comment
@laurafchen

laurafchen Apr 8, 2018

hi,
After i update according to "Keeping Your Fork Up to Date" section, and push, its pushing to original repo's master but not local forked repo's master branch;( This isnt what I expected. What I want is to get upstream updates and push to my forked repo

hi,
After i update according to "Keeping Your Fork Up to Date" section, and push, its pushing to original repo's master but not local forked repo's master branch;( This isnt what I expected. What I want is to get upstream updates and push to my forked repo

@lijukrks

This comment has been minimized.

Show comment Hide comment
@lijukrks

lijukrks Apr 12, 2018

Great! guide Thanks

Great! guide Thanks

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