Sync git fork with maintainer
I forked the joind.in project on GitHub, committed a few patches and sent pull requests. It was fun until I asked myself “how do I keep my fork synced with the maintainer’s repo?” I found the info (with minor bug) on Google Groups by Matt Todd. It deserved its own post post.
Create and checkout “upstream/master” branch (or whatever you want to call it):
git checkout -b upstream/master
Link branch to maintainer’s repo:
git remote add upstream git://github.com/upstream_maintainer/master.git
Pull maintainer’s repo:
git pull upstream master
Switch to your fork’s master branch:
git checkout master
Merge maintainer’s repo into your fork:
git merge upstream/master
Subsequent syncs
The next time you want to sync, you only need to switch branches, pull and merge:
git checkout upstream/master git pull upstream master git checkout master git merge upstream/master
Why don’t use:
git fetch upstream
git rebase upstream/master
This method don’t generate a commit on your local master branch.
In git, all branches are references to commits and can be replaced by their sha1 hash. The only difference is that branch references are updated after each commit/pull, with the exception of tags, which doesn’t change at all.
The branches you normally use in git, called local branches, are a part of a bigger group of references in your git repo. They are part of the “heads” namespace, and to proof that, you simply can do “git checkout heads/master”, which is the same of the shorter and more common “git checkout master”.
Remote branches are called by their remote name, and are for practical reasons for the end user read only, except when pulling changes. These remote branches are keeping the state of the last pull (since its impossible to keep track of a repo without manual pulling these changes). Each remote branch can be called by “remoteName/branch” name, like “git checkout origin/master”. But again, this is just a shortcut for in this case “git checkout remotes/remoteName/branch”.
You can list all remote branches by doing “git branch -r” or “git branch -a”, or remote specified “git remote show remoteName”. Yes there are many ways to 1 job.
Because git also tracks the history of the remotes you specified, I think it would add a bit garbage when doing just “git branch” because these commits are still reachable and in normal cases, you know where they come from. The only exception I personally do, is a local clean branch of the remote I am working on (like master, referring to upstream/master), just to safe a few keystrokes and not confusing other people by adding personal work.
Maybe just a reminder: if you check out a remote branch or tag (or get stuck in a headless situation), you have to create a new branch before you adding commits on it.