On improving commit practices

Question

I was thinking about ways to improving my commit practices.

Is there any co-relation between no. of source code lines and no. of commits?

In a recent project that I was involved in, I was going at 30 commits per 1000 lines.

One typical file from the project has these stats

language: JavaScript
total commits that include this file: 32

total lines: 1408
source lines: 1140
comment lines: 98

no. of function declarations: 28
other declarations: 8

Another file has these...

Language: Python
total commits that include this file: 17

total lines: 933
source lines: 730
comment lines: 80

classes: 1
methods: 10

I also think that no. of commits is more related to no. of features or no. of changes to the code and less to the no. of lines.

The general git community motto is make short commits and commit often.

So, do you really think about you commit strategy before you start the project. For that matter, is there anything like commit strategy? If so, what's yours?

Answer 1

If you're using a DVCS, you should be committing very often. I commit every time my code is in a stable state, which is not related to lines of code. You want a tree of lots of small, atomic commits that makes it easy to see what you did in each. If you're trying to track down a regression you found when testing, this makes it far easier to do a binary search and track down the exact commit, because you will have fewer changes per commit. I only commit when my code compiles - my idea of "atomic" is that it compiles, passes the regression unit tests, and passes a quick integration test. Sometimes a unit test is included, and sometimes not.

When you push, you should push whole features. The rest of the world doesn't want to see your "missed checking in this file" commits every day. Git provides rebase, which allows you to clean up your commit tree by squashing multiple commits together. The community seems to be uncertain about how much history you should commit. I'd say you should squash together the commits that don't show any of the history, like "missed file" or "dumb regression". You want to present as clean a history as you can so everyone can easily see what you did.

In a centralized version control system, you need to commit a lot more if you want to keep a good history. My recommendation is that you work on smaller features and complete them as much as you can before you commit. Your concept of "atomic" here should be a feature that works and is tested. You don't want to commit anything that break other developer's workspaces, because they will be updating often and it's a lot harder to work on independent features that overlap. You'll commit less, but those commits will usually be more meaty than your average DVCS.

You can see that the ratio of lines of code to number of commits depends on how big your features are and the workflow you use. Your workflow will be different depending on what version control system you use, so you can't generally predict what your commits will look like. Each institution has their own standard, and should determine for themselves what their workflow should ideally be.

Answer 2

I've had commits for bug fixes that changed one character. Size isn't really the determining factor here. A good rule of thumb is to commit whenever you can think of a commit message that makes sense. When to share your commits is a different question. It varies by your group's culture, but generally involves you being reasonably confident your changes work as intended.

Answer 3

I don't think number of commits should be related to lines number. More likely to problems solved/features introduced. I use this rather simple approach (git):

• Commit often to local branch, but only when something relevant changes (solved puzzling issue, added few important files/functions). This way, you can navigate easily between steps that took you to final solution of what you were working at given time.
• Merge local commits into single feature/problem related commit when sending to remote/public repository. This way, whatever you did that goes public, is well described and coherent, so that everybody knows what you were doing (or at least has brief idea).

Overall, whatever you do locally is for you - stick to approach that works for you. Public commits should be more thought through, but I wouldn't develop whole new strategy if team already has working approach. Stay consistent with others.

Answer 4

For posterity, commit all files related to a bug/feature in one revision. This will help you immensely later when you need to know what files were touched to fix a bug.

It will make it easier to go back and see what you did to see 5 files checked in under bug #783, instead of trying to track down 5 commits (one for each file). This can be alleviated if you have better source control/workflow integration which matches a check-in to a job/bug/feature/backlog item. Still commit frequently, but put related files/features in the same check-in every time.

If you have your CI set up for "build every commit" then that will help you do this.