I’m very fond of git for many reasons, one being its changeset-based commit model. Today I ran a demo of some code for a customer, and I used git as a demo driver - much like a TV chef brings out stuff he or she has prepared earlier. There are at least two ways to run a demo using git:
- by cherry-picking commits, and
- by using interactive rebase.
Let’s see how they both work! Suppose we have a separate branch, demo, that contains the code we want to demo:
The demo code consists of three separate commits.
The cherry-pick method
To use this method, start by creating a new branch based on master:
$ git checkout -b demo_impl master
Next, obtain a listing of the commits that are in the original demo branch:
$ git log --format=oneline master..demo b246a365af2476fdef2887d42b3f977d1526ec82 Third part of the demo 368176859ef87c81549ffebd2d79e98833f892e7 Second part of the demo fa9ef86b53126428ba8859d2e7dc3818efbd9243 First part of the demo
Then, as part of the demo, cherry-pick one commit at a time from the original demo branch:
$ git cherry-pick fa9ef86b53126428ba8859d2e7dc3818efbd9243
- The demo takes place in a branch separate from the original demo branch, which thus becomes a “template” that you cannot mess up.
- If you change the code as part of the demo, you need to clean the
local changes before you can continue. There’s no risk that you
inadvertently sabotage the demo. (To abort a cherry-pick gone wrong,
git reset --merge.)
- You need to keep a copy of the commit list to copy commit sha1s from.
- There’s much disruption in the form of typing and/or using the mouse inbetween demo steps.
The interactive rebase method
Working in the demo branch, start an interactive rebase for the three commits:
$ git rebase -i HEAD~3
In the interactive rebase instruction, choose reword (r) for all three commits:
r fa9ef86 First part of the demo r 3681768 Second part of the demo r b246a36 Third part of the demo
Start the interactive rebase by saving the instruction and quitting the editor. Now, git applies each commit in turn, and then waits for you to edit the commit message. To continue the demo, simply quit the commit message editor without making any changes.
- Very little “demo overhead” - all you have to do is switch to the commit message editor and quit editing.
- Since you do the interactive rebase in the original demo branch,
there’s a risk that you mess things up. I did this by making some
local changes as part of the demo, then did a
git reset --hardwhen git told me that it couldn’t continue with the rebase. The commit was lost. Whoops! (Thankfully,
git fsck --lost-foundsaved the day.)
Which method is best?
Personally, I find the simplicity of the interactive rebase method appealing. But if you’re afraid of messing up the commit history, go for the cherry-pick method! (As an added bonus, the cherry-pick method lets you skip demo steps if that for some reason makes sense in your context.)
Update 2011-10-17: Posted a follow-up to this!