chaitanya

- 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.