Source Control Commit Convention (SVN, GIT, etc.)

Witch ever source control software you are using (SVN, GIT or anything else) you must do “commit” to your repository. Normally people write a comment on commit (some don’t but they should), but event commit must have convention to be efficiant. So here are some rules that I’ve learn from other coworkers that I’ve push a bit farther:

  • One comment per line
  • One comment per change (a change can touch more than one file)
  • Separate you commit per feature
  • Commit for format/indentation should be done alone (hard to see a real code change in a full reformated file)

Here is a list of prefix that can be use for each of your comment line:

  • [+] new feature
  • [-] feature removed
  • [r] refactoring of existing code
  • [c] configuration change
  • [t] unit test (or any other kind of test
  • [d] documentation
  • [b] or [b#999] bug fix and add the bug number from your bugtracking tool (if any)
  • [t#999] the task number realated to your task tracking system (if any)
  • [i] any other information (like if the commit is a merge or for formattage purpose)

Of course you could have your own convention, but this one cover enough and is easy to remember.

This convention allow also to have script parsing your history log and be able to generate a release note about task implemented and bug fixed.

I’ll probably post something soon about a parser that we will do at my job to help QA team to know witch bug fix have been deploy on the server they are testing on.

Leave a Reply

Your email address will not be published. Required fields are marked *