comment 0

Track your upstream on GitHub, not your origin

I like to simplify my workflow. I have plenty of aliases to speed up the execution of recurrent tasks, such as rebasing against “master” when I want to submit a patch to a project on GitHub.

For that, I set the git branch where I am hacking to track the  upstream remote, not origin. Here is why.

Let’s start with an example: You found on Github a wonderful project “A” which looks fine, but there is an annoying bug you volunteer to fix. First, you clone it on the GitHub interface, of course, and then you want to retrieve the data on your computer to start hacking it.

Now you create a development environment on your machine and you end up having the following remotes “origin” and “upstream” configured:

upstream” points to the real project you just clone
origin” points to your version of the project you just created during the cloning
track-origin-5Now I want to submit a patch. I create a branch:

Normally your local environment should track “ origin”. This mean git will “track” changes that may occurs on your copy of the project. For example when you work on several computers.


But instead, I set this branch to track upstream, not origin. Tracking myself is pointless, I just want to create a small patch, in order to create a pull request on upstream.


So here I execute the following command:

Note that I don’t track origin/master, but upstream/master.

From now, everyday, to rebase this branch to retrieve the changes that has been done on the upstream, to make sure my pull request always merges (no conflict), until it gets merged on upstream, I simply do:

Which means:  git fetch --all && git pull --rebase

Of course, you cannot push your changes with git push (because your branch points to upstream, you probably not have the rights to push a new branch of a project that’s not your. You simply do  git push origin, or if you are lazy:

And this automatically updates my Pull Request.