这写都是我个人的约定，你可以取其精华或忽略它，但是你和你的团队最好要有一些某种形式上的约定！:)
尊重现有项目的约定
这种情况并不多见，但是当你往一个你可以直接访问的开源项目中提交代码或补丁时，你最好花几分钟的时间了解一下该项目以前的提交记录，并且了解一下该项目的作者是怎样组织文件的。
为提交信息添加动词前缀
当你往一个主分支(one that won't be squashed)提交代码时，你最好为所有的提交信息加上前缀，或者至少为绝大部分的提交信息加上标准化的动词前缀。何时添加以及添加的频率有你决定，但是最好使用标准化的动词，这可以更容易的快速浏览。我喜欢用"add", "remove", "update", "refector", "fix" 等，如下所示：
* bafaeac TJ Holowaychuk — add mixin property array support
* e9df63a TJ Holowaychuk — remove opacity plugin. Closes #29
* c5b1e85 TJ Holowaychuk — remove media macros. Closes #36
更新依赖的时候做个记录
当你更新你项目中的某个依赖时，你也许仅仅只用"update foo"类似这样的信息来提交你的代码，但是如果是出于某些原因你需要更新依赖，你最好为你的提交信息做一个简单的记录，这会对该项目的其他开发者（或者以后的你）很有帮助。
分支名称
这里没有什么特殊的，我通常会使用提交信息中同样的约定来命名分支，像 “add/my-feature”, “remove/old-feature”, “fix/crazy-bug”。
合并提交
在你自己的代码库或当你向其他项目贡献代码时，你最好保持一个清晰的提交记录，至少也要足够清晰以免把你自己搞乱。其中一个重要的方面就是在适当的时候“合并(squashing)”提交记录来形成一个单个的提交记录。
这是一个有点争议的话题，因为将多个提交合并成一个会使得二分查找(bisecting)更见困难，但是对于一些小的修改，这往往会有助于提交记录的清晰。
举例来说，如过某个人向你的项目中发送了一个pull-request来修复一个bug，但是这个pull-request包含3个提交记录，如下所示。你很可能不会关心最上面和最下面的那两个提交记录，你可能只需要一个包括了test和fix在内的提交，这可以更容易的恢复(revert)，更容易的在你的主分支中进行浏览，只要聚焦于这些修改，也同样容易进行二分查找(bisect)
- fix typo
- fix something. Closes #123
- add test for fixing something
你真正想要的是：
- fix something. Closes #123
你可以使用 git-extras 中的 git-squash(1) 命令来实现它，尽管我相信某一个GIT大神会给出一个内建(build-in)的解决方案。
EDIT: @defunctzombie 建议只需简单的使用 reset —soft，之后再重新提交修改即可。这种方法和git-squash(1)之间的唯一区别是后者会合并(squash)整个分支（要小心！！）。
EDIT 2: 最终发现git-merge 有一个--squash 选项可以有效的完成git-squash的工作，所以没有必要再多做介绍如何使用了。下面是它的用户手册的一个片段：
—squash, —no-squash
Produce the working tree and index state as if a real merge happened (except for the merge information), but do not
actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to cause the next git commit command to
create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the
same as merging another branch (or more in case of an octopus).
短暂的分支
对于一些我确定我会合并的短暂分支来说，在提交时，我会去掉功能相关的前缀。例如，在一个名为 fix/facebook-auth 的分支中有两个常规的提交“fix facebook oauth integration” 和 “add test for facebook oauth integration bug”, 我通常只会像这样提交，"add test"，“fix integration”，这样它们依旧有意义，但是这可以为你节省很多时间。
留下一份记录
大部分人都会这么做但我还想强调一下,告诉使用者去“查看提交日志”是不友好的. 当你提交一个版本后，大家只想看到更改部分的日志, 或是排序后的日志，可以方便的看到那些是添加的，修改的，删除的等等.
我用的是 git-change log(1) 来生成更改日志, 如果你还需要更严格的日志记录，那也许不需要像git-change log(1) 那样的处理.
关闭和引用
我想大部分 GitHub-ers都知道这个功能，但我还要再强调一下. 如果提交了 “Closes #123" 字样的字符串，Github就会关闭这个条目，并创建该条目的注释引用.
引用的时候也一样, 在注释中写上 “#123" 以分类标识, 这是Github一个不起眼却很强大的功能，最好能合理应用.
提交的标签
我是不太使用这条功能，但我会积极尝试. 比如生成了更新日之后还是需要分出哪些是“真正的” 更新, 谁也没法确保提交日志的准确 — 但如果在相应的提交记录里添加#change或是[change]标签, 区分起来就很容易了.
其他人也会使用#ui, #ux 或其他类似标签来标识, 我想不管从统计的角度或是易读性方面都很好.
我们在 Cloudup的提交都加上了相关模块名字的前缀. 这样确实是模块化的开发，但却影响了后续的代码提交. 比如 “add gravatar support to signup”, 可以这么写“signup: add gravatar support”, 这样能让人们更容易识别.
还有其他好的建议?
以上都是我的一些使用心得，如果在你的工作中发现了其他更有效的使用方法，请不吝赐教.
