There are two scenarios where this is useful.
The first is when you deploy code from an open source project, and then make custom changes to that code. You then want to pick up bug fixes and features from an upstream release.
The second is managing client code branches (which I'll talk about in part two).
Shocking as it seems to me now, in the 'old days' I used to keep a changelog which listed all the changes that had been to made to code. Embarrassing.
Here is what I do know, in my day job.
We use MediaWiki internally, but have carried out a number of customisations and patches to add features that are not in the standard release. Some of these are extensions, but a few require changes to the core code.
Managing this in Git has made the task a whole lot simpler than it used to be.
Firstly I created a repository of the standard release by untaring the code, cding into the directory and running:
qed ~/wiki $ git add .
qed ~/wiki $ git commit -m"The initial commit"
The second step was to create a branch for our customisations.
qed ~/wiki $ git checkout -b radiowiki
I then installed the wiki and committed the changes in our new branch. For testing I have a local copy of the repository where testing is done, and changes are backed up in the master repo.
When a new release of the MediaWiki software is out, I change back to the master branch (on the staging server):
qed ~/wiki $ git checkout master
and then untar the new code over the top of the old.
After committing, it is the a simple matter to checkout our branch:
qed ~/wiki $ git checkout radiowiki
and rebase this off the master.
qed ~/wiki $ git rebase master
The rebase command first checks out the working copy of the code from the head of the specified branch, and then reapplies the commits we made on our branch.
I then test, backup the repo, and deploy the changes.
This strategy is perfect when you have a single repository (although not THAT likely if you are using Git). In the next part I'll show how to manage client code using both rebase and merge.