[chaitanya]

You can have the best of both worlds -- "commit early, commit often", and "nice clean commit histories" -- with git, and it is easier than most people think.

- So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit".

- Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this doesn't modify the previous commit, instead it modifies your commit history and replaces the last commit with a new one[1]. So instead of having two new commits in your branch's history, you only have one.

- Repeat the process until you have something worth pushing to the remote.

- Once you've pushed to remote, remember to not make any further modifications to your git history[2] i.e. going forward, create a new commit and only then run "git commit --amend".

Now, there's an obvious question here: if "git commit --amend" keeps replacing the last commit with a new one, what happens when you mess things up and want to revert to NOT the last checkpoint, but some checkpoint before that?

The trick here that git has up its sleeve is called "git reflog". You see, while "git commit --amend" replaces the last commit in your branch's history with a new one, the older commit is not actually gone, its still there. And you can see all of them with "git reflog". Basically "git reflog" returns every commit at which the local HEAD (i.e. the commit checked out in your working directory) has been. So none of the commits that you replaced with --amend are actually lost, and you can find them all in the reflog.

Restoring to an older checkpoint becomes as easy as running "git reset --hard <previous-commit-id>", or if you want to play safe, "git checkout -b <new-branch-name> <previous-commit-id>".

Hope this helps!

Notes:

1. By design, a commit, or in fact most objects in git cannot be modified. They are immutable.

2. Basically you can play with git history as long as it is private to you and not shared with others. But the moment you push it to a remote you share with others it's no longer private and you must not modify that history anymore. Read Linus's note on keeping a clean git history: https://www.mail-archive.com/[e-mail]...

[sbinnee]

I like --amend a lot too. Usually a new feature requires a few steps. I commit every step and make a list in git commit body. It's basically almost same as rebasing at the end, but amending seems more logical to me.