作为开发者首选的版本控制系统（VCS），Git已经变得无处不在了。使用Git为工程团队带来了巨大的价值，特别是对于有多个开发人员一起工作的团队，因为有一个系统可以可靠地整合每个人的代码变得非常重要。
但是，对于每一个强大的工具，尤其是涉及到与他人合作的工具，最好是建立约定俗成的方式来遵循，以免我们把自己射杀在脚下。
在DeepSource，我们为自己的团队制定了一些指导原则，使与Git这样的VCS合作更容易。以下是你可以遵循的5条简单规则。
1.做出干净的、单一目的的提交
很多时候，程序员在做某件事情时，会偏离方向，做了太多的事情--比如你正试图修复一个特定的bug，却发现了另一个bug，于是你忍不住想把它也修复。还有另一个。很快，它就像滚雪球一样越滚越大，最后你会在一次提交中出现许多变化。
这是有问题的，最好让提交尽可能的小而集中，原因有很多，包括：
- 它使团队中的其他人更容易看到你的改动，使代码审查更有效率。
- 如果提交的内容必须完全回滚，那就容易得多。
- 用你的票据系统来跟踪这些变化是很直接的。
此外，它还可以帮助你在头脑中解析你所做的修改，使用git log 。
2.编写有意义的提交信息
这可能是挂在嘴边的最低级的果实--有洞察力和描述性的提交信息，简明扼要地描述了作为提交的一部分所做的改动，让别人和你未来的自己都感到轻松。写好提交信息的一个很好的启发式方法是这样的：
feat: add beta sequence
^--^ ^---------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
如果你使用的是票据系统，你也应该在描述中包括票据ID。一些现代的VCS托管系统，如GitHub，会自动将提交信息与问题链接起来。
3.尽早提交，经常提交
当你经常提交你的工作时，Git的工作效果最好，也对你有利。与其等待提交完美，不如分小块工作，不断提交你的工作。如果你正在开发一个可能需要一段时间才能完成的特性分支，这有助于你保持代码的最新变化，从而避免冲突。
另外，Git只在你提交时对你的数据承担全部责任。它可以帮助你避免丢失工作，恢复修改，并帮助追踪你在使用git-reflog 。
4.不要改变已发布的历史
一旦一个提交被合并到上游的默认分支（并且对其他人可见），强烈建议不要改变历史。Git和其他VCS工具可以重写分支历史，但这样做对每个人都有访问仓库的权限是有问题的。虽然git-rebase 是一个有用的功能，但它应该只用在只有你在工作的分支上。
尽管如此，难免会有需要重写已发布分支的历史的情况。在这样做的时候，必须特别小心。
5.不要提交生成的文件
一般来说，只有那些耗费了大量人力的文件才应该被提交，而且不能被重新生成。可以重新生成的文件可以在任何时候生成，并且通常不与基于行的差异跟踪一起工作。在你的仓库根目录下添加一个.gitignore 文件是很有用的，它可以自动告诉 Git 你不希望追踪哪些文件或路径。
