Meaningful Commit History
Posted February 17, 2010on:
Back to the time of using VSS, check-ins (commits) happened upon when you feel it’s the time to check in. One check in could contain changes for different purposes. Who cares. It is impossible to apply the changes to different branches anywhere.
With git, the commits are visualized like steps of how your software is developed. You would feel shame when seeing yourself mixed up changes together. Actually, if you organize them well, the commits are not only showing good history, but also they can be applied to other branches, called cherry picking. It really let you start thinking to make meaningful commits. And not to mix several changes into one big commit.
The commit message conventions have changed because of the meaningful commit idea. In VSS before, we mostly used the past tense, like “fixed bug 123”, “added new stored procedure”, and etc. It mean I finally have done something. Now in git, the present tense makes more sense. “Fix bug 123” means that if you pick this commit into your branch, it will fix the bug. “Add new stored procedure” means that the commit will you give a new stored procedure. This new style is helpful for cherry-picking. Now the history does not like feature announcements, but has many smaller atomic, maybe reusable steps.
Since we started to be careful on committing, very naturally we want to be able to fix our last commit by adding more changes to it, or even just add some comments. Git commit –amend let us achieve it easily. In Mercurial, that’s not allowed. because in Mercurial, change sets are immutable. It is difficult to make correct commits just one time deal.