• commit related changes
• 一次提交(comit)应该只包含相关的改动。比如说，修复两个不同的bug就应该分开来做两次提交。提交的改动越小，其他开发者理解起来就越容易。如果改动有问题，退回去也比较方便。
• Git有一个暂存区域（staging area）的概念，它还允许你暂存文件的某些部分，这更便于你创建非常细粒度的提交。
• commit often
• 经常提交势必让你每次提交的东西都很少，也有助于你只提交相关的改动。并且，你还能更频繁地与别人共享代码。通过这种方式，所有人在集成代码时都会感觉更轻松，也就能避免一些不必要的冲突。
• 相比之下，如果每次提交的东西很多、改动很大、时间间隔很长，那么在代码合并（merge）过程中产生的冲突就很难解决了。
• don't commit half-done work
• 你应该只在完工之后才提交。这并不是逼你把一个大块头功能完整实现好之后再提交。恰恰相反！你应该把大功能的实现分解成 合乎逻辑的小块工作，并且记住要早一些、经常性地提交你的代码。
• 只是要切忌为了提交而提交，比如在下班离开公司之前把一些东西仓促放入仓库中。如果你这么做只是为了从服务器抓取一份干净的代码（git checkout <branch>或者git pull），可以考虑使用Git的“Stash”功能。
• test code before you commit
• 你“认为”已经完工了，然后就可以提交了吗？千万要抵得住这种诱惑！你应该进行 全面的测试，以确保你真的是“完工”了，并且（在你能够识别的范围内）没有副作用。
• 尽管将半成品提交到本地仓库不伤大雅（原谅你的庸人自扰），但当你把代码推送（git push）到服务器与别人共享时，这个问题就大了——在这之前，请务必测试你的代码！
• write good commit messages
• 在描述的开头部分，你应该简单总结一下你所做的改动（别超过50个字）。然后，用一个空行将开头与主体部分隔离开来。在主体部分，你应该详细回答这些问题：
  • 为什么要做这次改动？
  • 跟以前的实现有什么不一样？
• 请使用祈使语气和现在时态（比如，要使用“change”这个单词，而不用使用“changed”或“changes”），为的是与git merge这样的命令自动产生的描述保持一致。
• version control is not a backup system
• 把你的文件备份到远程的服务器上是版本控制系统的一个不错的副作用。但是，你不应该只把版本控制当备份系统来使用。
• 版本控制追求的是 每次提交的意义（请回过去阅读第一条：把相关的改动放在一次提交里）——你不应该填鸭式地塞入一堆毫不相干的文件。
• use branches
• 分支是Git最强大的功能之一。这并不是偶然的——从一开始，简单、快速创建分支的能力就是对Git的一个核心需求。
• 使用分支能够有效地避免不同开发工作之间的相关干扰。你应该在开发过程中广泛使用分支，它可以用于开发新功能、修复bug、试验新的想法……
• agree on a workflow
• Git允许你采纳很多种不同的工作流程：持久存在的分支、主题分支、合并或复位、Gitflow……
• 你到底应该选择哪一种呢？这取决于几个因素：你的项目，开发与部署的整体流程，还有（可能是最重要的）就是大家的个人偏好。不管你们选择哪种工作流程，请确保团队中的每个人都对工作流程有相同的理解并且严格遵循。

相关资料：

• 原文：http://www.git-tower.com/learn/version-control-best-practices.html
• 翻译：http://www.oschina.net/translate/version-control-best-practices

很久以前看过，但不自觉地会放松对自己的要求。审查新同事提交代码，上述问题起码出现了一半。不禁想起自己的代码，问题多多少少也有一些。要加强这方面的学习，时时警醒自己。