For people new to git, what you usually do is something like the following:
apt-get install git-core git-clone git://git.cuci.nl/pike cd pike git-branch 7.7 origin/7.7 git-branch 7.6 origin/7.6 git-branch 7.4 origin/7.4 git-checkout 7.7 git-branch -f master 7.7 git-checkout -f master
Now you are ready to create your own changes on top of 7.7 in your own development branch called master.
git-log master git-log 7.7 git-log 7.6 git-log 7.4
After making changes, use:
git-commit -a -m "Some useful one-line-description"
and repeat as often as needed (of course).
In order to update the mirror from upstream (my repository, where you cloned from), simply run:
git-fetch
Every once in a while. After doing so, perform:
git-rebase
to actually move forward your own "master"-branch changes so they are automatically merged and (re)based onto the latest (official) updates from 7.7 Pushing back the changes into the official release involves using CVS (externally from git) still. The native git mechanisms cannot be used for that until the official repository is also changed to git.
The nice thing about git is that merges from the developmentbranch back into older stable branches are seemless and fully annotated. These advantages however, cannot be used until git is used natively. In theory, the merges could be retro-fitted into the branches, but there currently is no automated way of doing that to the existing tree (it can be done manually, git allows all kinds of "afterward fixing").