Atomic commits
Thursday, August 9th, 2012 | Limited, Programming
If you’re using version control (you are using version control, right?), the question sometimes comes up as to how often you should commit.
I’m a commit fanatic, I like to commit as soon as soon as I can, no matter how small the change. Other people prefer to wait a little and make large commits all at once. However often you choose to commit, you should make sure it falls within the constraint of being atomic.
This means that each commit is one single, complete change. That is to say that you shouldn’t commit multiple changes at once, nor should you commit a change that is only half done. This is scope in this for different approaches of course “one single, complete change” could be part of a several step refactor as long as the changes stand on their own, so could committing the refactor at once if it is all part of the same unit of work. But the important thing either way is to try and stick to atomic commits.
Think of it like an ACID transaction. Presumably you’re system works before you make the commit and it should work after too. It should contain just one feature so that if you want to roll that specific feature back, you can roll back that one commit without rolling anything else back.
With Git, where people may want to take out of sequence commits, this becomes especially important. People may want to take one of your changes, but not the other, so making sure two changes are in two separate commits is very important. Generally, if your descriptive commit comment (you are writing descriptive comments, right?) contains the word and, you probably need to re-think your commit.
If you’re using version control (you are using version control, right?), the question sometimes comes up as to how often you should commit.
I’m a commit fanatic, I like to commit as soon as soon as I can, no matter how small the change. Other people prefer to wait a little and make large commits all at once. However often you choose to commit, you should make sure it falls within the constraint of being atomic.
This means that each commit is one single, complete change. That is to say that you shouldn’t commit multiple changes at once, nor should you commit a change that is only half done. This is scope in this for different approaches of course “one single, complete change” could be part of a several step refactor as long as the changes stand on their own, so could committing the refactor at once if it is all part of the same unit of work. But the important thing either way is to try and stick to atomic commits.
Think of it like an ACID transaction. Presumably you’re system works before you make the commit and it should work after too. It should contain just one feature so that if you want to roll that specific feature back, you can roll back that one commit without rolling anything else back.
With Git, where people may want to take out of sequence commits, this becomes especially important. People may want to take one of your changes, but not the other, so making sure two changes are in two separate commits is very important. Generally, if your descriptive commit comment (you are writing descriptive comments, right?) contains the word and, you probably need to re-think your commit.