When I code, I always commit as often as possible. I try to bring myself to check code in at least every hour. Here is the case for frequent commits.
The psychological effects on me are just amazing. The rhythmic process becomes a dragonboat's drum that pushes me forward. If I fail to commit after an hour, I feel like I dropped the ball and end up working harder. The following points are more technical, but this one alone is enough to justify frequent commits.
Breaking down the tasks into small chunks becomes essential to make the next commit on time. When a task is hard to explode, I get creative and check in tiny bits of functionality at a time. Write a small test, make it pass, check it in. Refactor, check it in. It helps me to always stay in control, I can justify every step I take toward the goal.
Fewer integration conflicts result since less code is checked in at a time. This one is well understood. Conflicts are bad.
Flexibility. It makes it easier if I want to pair, go solo, or switch pair. I can "change state" every hour if my heart so desires. Also, if someone needs a piece of code from the story I'm working on, it might already be checked in. Sharing and integration cannot happen soon enough.
Thinner diffs between commits makes the problem of finding where a bug appeared/re-appeared easier. Once I found the build that "broke the feature", it's a lot easier to dig through a small change and pinpoint the dubious line. As a bonus, the log message for each check-in usually ends up very precise.
Backups. Every time I commit, I am also making a backup of my code. Losing my local work is never a problem.
Visibility. The commit log becomes a pulse on the state of each pair or each developer. It becomes another tool for the team or the manager to assess progress. Frequent commits become a sign of good health. How hard the current task is can now be estimated by the interval between commits. A slowdown in the commit rate might raise some questions during the stand-up meeting or the retrospective...
Frequent commits are a good thing.
5 comments:
How do you think that frequent commits might change once your software is in production? Are your stories small enough that you feel that you can have them completed in time for a production push?
I generally agree with frequent commits. The common practical blocker of frequent commits is when there is a looming production release that prevents you from risking unfinished code. How do you balance that situation?
I agree with you Matty, but sometime if the project's codebase is very large, build will cost a lot of time especially for the acceptance tests. Now, the Mingle team are trying to solve this problem.
I used to think people who waited the whole day to commit were evil. But there are fundamental underlying issues when people do not commit frequently. This happens when someone is spiking a card and is not sure if the card-spike will lead the card completing successfully. It could also be that building/running tests takes something like 20+ mins so either the dev can wait to complete the card or just commit after unit tests and hope cruise does not break.
@Kris: I feel more confident checking in an array of small changes than checking in a code bomb, so when it comes to code base stability, I think committing often is a good habit.
Now if there is an imminent production push, that's a problem. I see 3 pseudo-solutions.
1- Don't care (if the feature does not yet have a hook to the GUI for instance)
2- Use a distributed VCS to at least be able to commit locally
3- Branch
Nice & brief, it's been forwarderd to several developement teams a minute after having been read. Thanks!
@kris; if a release is coming, you better have a tactic ready, but there's no (unafordable) reason to stop committing;
Branching for polishing & testing would be my choice, but that'll depend on a lot of factors in your installation.
Post a Comment