I have stumbled by http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html a few times now. So I thought I'd say why rebase and lying is good.

Everyone lies, no matter what.

Committing often is a good thing. It helps keep you organized of what you already done. Having to COMMIT to the commit you would be more hesitant to commit at all (until everything works 100%).

Which would mean you end up not having a commit on your branch but 100s of file changes which you cannot figure out why exactly you changed something so you would end up git add . and git commit -m "changes" which does not help workflow or finding out why something was changed (e.g. a bug was introduced).

Lets say you worked on a branch for a day and have done 20 commits. However you notice this feature is going to take much longer and 10 of them commits can be re-used by other developers (if you get it into master ASAP). You could easily rebase, re-order the commits and create a branch on the 10th commit (git branch feature-x <sha>).

Now what you have is a branch off a branch.

git checkout feature-x git push origin feature-x and open a code review.

If rebasing wasn't possible then you would end up with developers doing the SAME work; or even worse... you creating a new branch and re-doing half the work manually.

Also... if you commit often then you figure out you don't require a few changes you've made previously. Each of them changes would be in their own commit so you could easily use rebase and remove those commits.

Alternatively (non-rewrite history) you would git revert <sha> which adds an additional commit to the history for NO REASON. Just to keep the "history".

Keeping history is good... too much of it is bad.

Some argue keeping history (no matter what) is good. My question would be, do you commit each time you type a character? and then the backspace? no...

Do not commit to your commits

unless they are in master or are shared :)