From: Gergely Polonkai
during my GitHub based development (which is pretty much similar to what you just described) I do the following:
• fork the original repo, so that my GH account has a copy of it
• clone the forked repo to my machine
• add the original repo as a second remote and name it "base"

I like the name choice : "base". So the upstream remote repo is 'base', and the personal fork is 'origin'.

However I'm now using:
• clone the upstream repo to my machine (i.e. the opposite way around)
• fork the original repo on GH, so that my GH account has a copy of it
• add my GH fork as a second remote and name it "my".
So the upstream remote repo is 'origin', and the personal fork is 'my'.

This helps when others give commands that assume origin == upstream, and 'my' is short and easy to remember!


• start my feature branch off of base/master: git checkout -b myfeature base/master. This way, git status tells you immediately if my brange has diverged from upstream • code-code-code, occasionally pushing my feature branch to my fork (origin) • if the coding takes longer than a day, I sometimes fetch from base, and rebase my work to base/master.

Agreed. The rebasing becomes essential if there is a long review & refinement period

This way my feature branch remains up to date, and less polluted. This, though, requires me to force push to my fork (origin/myfeature) after the rebase; if this would cause problems, I tag ORIG_HEAD just in case, but still force push.

If I create a pull request on GH I will typically tag the old PR tip, so that when I force push and update I can refer to it's previous version (so those who are reviewing the GH repo can see both old and new versions; GH update the PR to the newly forced branch tip!)

Hope it helped.

You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to