What are some of the best SCM practices?

Question

I have been using Git for some time now to manage my own personal projects. I didn't really think about how I used it. I usually commit all the changes whenever there is a milestone not really thinking.

But after reading a blog post that mentions how you should right your commit messages, I realized that I don't really know how to properly utilize SCM.

So I am wondering if you have any tips regarding things like:

• When you should commit a change
• How to write the commit message
• How to work with others using a repository
• anything else...

Thanks!

Answer 1

Since you're using git, here are some of my practices that may or may not work for you:

1. Always work in a local branch with descriptive names, say work/feature_name (using the awesome bash completion for git to help you type)
2. Commit as often as you want in local branches with terse comments (to document intentions for reminding yourself.) So you have the complete original thought/development history that you can go back to.
3. Before you push/publish commits/patches, create a pu (proposed updates) branch (git checkout -b pu/feature_name) from your work branch and use git rebase -i to make perfect commits, i.e., group related small commits (and/or split large commits) in to logical commits and write meaningful descriptions (for others and yourself) make sure each logical commit builds and passes regressions.
4. Publish your pu/feature_name (either ask people to pull or just push to a public server like github.)
5. It's likely you'll need to iterate through 3 and 4 a few times if you have a code-review process.

It sounds complicated, but it's really a joy to practice (at least for me), as git is so fast and feels so right in doing all these steps.

Answer 2

I'm aware of two defensible and commonly practiced uses of the power to commit:

• Fine-grain commits, where you commit early, commit often, and in small chunks. The system may not be in a good state at every commit. The major benefit of this practice is that you get a very clear view of what has been changed and when, and with a system like darcs or a command like git-rebase you have a chance at "cherry picking" commits that interest you.

• Reliable commits, where you commit only when the system is in a solid state, e.g., it not only builds but also passes regression tests.

In a large group project, some sort of reliable scheme is a necessity, although you can still do fine-grain commits locally and make them public only when in a solid state.

After many years I have observed consistently that most students and other beginners are afraid to commit and don't commit often enough. For my own projects I tend to use the fine-grain approach, and for larger projects I typically carry at least two branches, doing solid-system commits on one and fine-grain commits on the others.