What are the good criteria for committing changes

Question

I'm currently using git for managing several projects, however, one question has been bugging me recently: what is the good tone for committing modifications to the master branch and to secondary branches? Should it be 'commit when it compiles', 'commit when it works', or something else? Thanks.

Answer 1

It really depends, is this your personal repo or is it a repo that is shared by many developers? How far into the project are you?

Personally I commit to my subversion repositories when I am done with one aspect and everything compiles. It does not have to be complete, just not broken. I prefer to not leave things broken in the first place.

Half written code can get checked in, but only in my personal branches, generally with notes about what I was doing at the time and what still needs to get done. Since I use Subversion and this is my personal repo I use this mainly to be able to leave my desktop and pick back up where I left off on my laptop.

Generally the one bug/issue/feature per commit is nice, but may not suit your development style. If this is a more complete project it may work out since commits mean that you are crossing items off a list somewhere and it means one more item that is now completed.

Other things to consider, what is significant about the changes that it warrants checking in? For example, I checked in code last night that significantly changed an internal API, this meant I had to document the changes in the commit message as well as the documentation. At the same time I also changed a few comments to fix typo's. That gets a small sub-note on the commit message, but is not something I consider a big enough issue to get committed on its own.

Answer 2

Commit any code you don't want to write again :)

Answer 3

First: Ignore subversion strategies and strategies stemming from that mentality. There is a difference between saving a change and publishing a change.

Committing is saving a change. While I wouldn't suggest committing on a timer, I would suggest you think of it more like saving a file than releasing a version. Do it when you fear you may need to come back, but are afraid it would otherwise be hard to get back to where you are.

However, rewrite the commits (git rebase -i origin/master # for example) before you publish them. Find the meaning in the mess you made and create a set of comprehensible and clean commits with good commit messages and ensure each passes whatever quality checks you might have. Then publish it.