Posted 06 October 2013 - 02:41 AM
I apologize for coming into this late but wanted to expand on this subject considerably. In general, the messages you use are perfectly fine from what I could see, your use of git in it's intended form is crippled by worrying about this though. I don't mean to be offensive, I just mean to point out an alternative which makes worrying about the individual messages less important except at the points it actually matters. What I'm talking about is specifically codified with the GitFlow scripts, which is actually very close to what I have used with other items such as Perforce and SVN for many years.
Look at the purpose of revision control in general. It actually has 3 primary goals:
1. The individual user wants basically an undo system along with the history. As you work as an individual, things compile but don't actually work yet, you might check that in just as a "compiled at this time" mark. The message doesn't matter to anyone else, only that you decided you needed a point of reference for what you were doing next. You keep working and find that you went down the wrong path, a quick revert to the check point and you can start over. This is the user personal level. Obviously if this is done in the main/dev branches folks will flay you alive. Hence, GitFlow 'Feature' branches. (Or personal branches in other revision control systems.)
2. The always almost always working, though potentially buggy, development branch. This is where #1 integrates with the "team" nature and how GitFlow and branching in other RCS systems have done things successfully. The individuals do everything in a personal branch, GitFlow calls them "feature" branches, and you only write the fancy messages describing what you have done in detail during the merge of the personal branch into the development branch. These are the messages which need to make sense, the merges. Obviously your history in the personal branch is important (and yes it is tracked even if you kill the branch and start a new one) for tracking why some bug may have shown up.
3. The "release" branch. (GitFlow I believe says this is the master branch to follow Git conventions.) The intention is obvious I hope, but the utility is underrated. Say you release 2.8.7 of your software (i.e. check into the release branch, build and deploy) and your devs (you perhaps) are all busy on 2.9 when a bug is reported on 2.8.7 which simply has to be fixed immediately. With the branches, you simply check out the release version, fix the bug and check it in as release 18.104.22.168 as a hot fix. If you need to apply the fix back down to current work, that is simple using the cherry picking system in Git though a bit more complicated in other revision control systems.
This is basically an overview of GitFlow which is pretty much a formalization of how many AAA game shops work in one way or another. It applies to all RCS usages in reality, just some are more painful than others to setup.