[csense]

Rebase throws away your commits and replaces them with different commits. OP is using rebase to simply change the parent pointer, but git's interactive mode is much more powerful. To enter interactive mode with e.g. the last five commits, try this command on your favorite repository:

    git rebase -i HEAD~5

With this command, you can re-order commits. This is useful because often you will write several commits for A, realize A depends on another feature B, write several commits for B, then write several more commits for A. The history would be easier to read if B was developed first, then A was developed on top of it. Re-ordering the commits so all B commits are first accomplishes this.

You can also use the same command to squash multiple commits into one. This is useful when you write a commit, then have several commits gradually adding temporary debugging statements and unit tests, then more commits to fix any problems uncovered, then more commits to remove extensive print statements and other temporary debugging code.

Assuming you get the code working, most of these commits will be totally irrelevant to future development efforts. With the "squash" feature of git rebase -i, you can condense all these commits into a single commit containing only working code and unit tests, springing fully formed in a single commit, like Athena from the head of Zeus.

The git rebase -i command will also let you re-word or edit commits; the utility of those functions should be obvious.

[richsinn]

Nice explanation. When I was first learning git, the most intuitive explanation of git rebase were these three links (if read in order... these links were once published on Hacker News many moons ago):

(1) http://gitready.com/intermediate/2009/01/31/intro-to-rebase....

(2) http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm...

(3) http://gitready.com/advanced/2009/03/20/reorder-commits-with... <~ talks about "interactive mode" with the -i option