本文翻译自git-tower.com
提交相关联的更新
一次提交，是有关联的更新的一个打包。比如，修复两个不同的bug，应该是两次提交。小型提交，使其他开发者更易理解那些更新。当出错时，也更容易回滚。
有了像暂存区域和暂存文件某部分的工具，git很容易的创建细粒度的提交。
经常性提交
经常提交能让你的提交更小，而且，再一次说，帮助你只提交有关联的更新。另外，它可以让你你更加频繁的跟其他人分享你的代码。那样，每个人更容易定期整合更新，避免合并冲突。相反，拥有少量的且巨大的更新，并且不经常分享，使得他人很难去解决冲突。
不要提交半成品
你只有当代码完成后才提交。这不意味着你在提交前必须完成一个完整的巨大的功能。恰恰相反：将功能的的实现分解成逻辑块，记得尽早提交和经常提交。但是，不要当离开办公室或一天结束时，把随便什么内容都提交到仓库。如果你仅仅因为你需要一个感觉的工作区(如切换分支，拉取更新等)需要临时提交，考虑使用Git的Stash功能作为替代。
在提交前测试代码
当想提交一些你“想当然的以为”已经完成的东西时，请抵制住诱惑。彻底的测试以保证它确实完成了，并且没有副作用(至少根据当前的情况判断)。当提交半成品到你本地仓库，你还能能自己原来自己；与推送/分享你代码给其他人相比，测试你自己的代码则更加重要。
编写优良的提交信息
在信息的开头，简要介绍这次更新(通常做法是至多50字)，用一个空行与后续的主体分离。信息主体对于下述的问题应提供详细的回答：
- 这次更新的动机是什么？
- 与之前的实现有什么不同？
使用祈使句，现在时态(使用change，而不是changed或changes)，与诸如git merge命令生成的提交信息一致。
版本控制不是一个备份系统
把你的文件备份到远程服务器上是一个版本控制系统非常好的附加应用。但是，你不应该像备份系统一样使用你的版本控制系统(VCS)。当进行版本控制时，你应该集中精力在语义上的提交(参考## 相关联的更新)，你不应该只是填充文件。
使用分支
分支是Git最强大的功能之一，并且这并非偶然：快速易用的分支功能从一开始就是核心需求。分支是帮助我们避免混淆开发过程中不同支线的完美工具。你应在你的开发工作流程中广泛使用分支，诸如功能，修复缺陷，新想法….
统一的工作流程
Git可以让你选取诸多不同的工作流程，长期运行的分支(long-running branches)，置顶分支(topic branches)，合并或变基，git-flow…，你的选择取决于几个个因素：你的项目、整体的开发工作和工作流，以及(可能是最重要的因素)你和你的小伙伴的个人喜好。不管怎样，一旦你选取了一个工作流，你就要确保每个人的工作都能与此工作流程保持一致。
帮助以及文档
通过命令行获取帮助
1 |
$ git help <command> |
在线资源
git官方网站
http://www.git-scm.com/
免费在线资源
http://www.git-tower.com/learn
http://rogerdudler.github.io/git-guide/
http://www.git-scm.org/book