实在是受不了有些人的 Git 提交，费大力气“[回滚](441)”，遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。
和源码无关的东西，尽量不要进仓库
不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。
- 测试时上传的文件，测试时的临时文件，统统不要
- 对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外
- 编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要
- 对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了
- 图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理
- 对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极
- 使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库
- 不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线
尽量采用相对小、相对独立的提交
Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。
当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 [linux kernel 开发文档](http://wiki.zh-kernel.org/doc/%E5%A6%82%E4%BD%95%E5%8F%82%E4%B8%8E_linux_%E5%86%85%E6%A0%B8%E5%BC%80%E5%8F%91)中也有提到。
当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。
注释格式
格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。
Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。
我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质：
- Add something
- Bug [fix|found]: describe the bug or fix.
- Chg something
- Del something
- Enh some treatment
- New something
- Tmp for some cause
为了保持语法通顺，也可以采用前三个字母后面加冒号，后面有啥写啥的方法。
最后，我觉得，能够遵守行业规范和团队约定，主动养成良好习惯，应当是鉴别人才的一项重要因素。
Update @ 2012-12-03
关于注释格式，在使用了几年 Git 后，又有了更深的认识， 参见 [Git commit 注释格式](/blog/post/14)。