提交要对应修改
一次提交应该对应一个相关的改动。例如：两个不同的错误应该对应两次不同的提交，使它更容易让其他开发人员明白这个改动，如果这次改动存在问题，也可以方便的回滚到改动之前的状态。通过暂存区标记功能，Git可以轻松打造非常精确的提交。
经常的提交修改
经常的提交改动可以更方便地为它做注释，从而更容易确保提交的注释和改动的一致性。通过频繁的提交来与其他的开发人员共享这些改动，那样就会避免或减少代码整合时带来的冲突。反之，非常庞大的提交将会增大整合时出现冲突的风险。
不要提交不完整的改动
对于一个很大的功能模块来说，完成后在提交并不意味这必须整体完成后才可以，而是要把它正确分割成小的完整的逻辑模块进行经常性的提交。一定不要提交一些不完整的改动，仅仅是因为下班。
同样，如果只是为了得到一个干净的工作区域也不需要立刻提交。可以通过Git的Stash命令把这些改动移到另外的分支。
提交前进行代码测试
不要提交还没有经过完整测试的改动。只有经过测试，并确定无误的改动才能提交。把改动发送给开发团队其他成员前，必须确定所有修改已经完整测试过。这样才算真正的完成。
高质量的提交注释
提交注释的开头需要一个少于50个字的简短说明。在一个空白分割行之后要写出一个详细的提交细节。比如回答如下的两个问题：
- 出于什么理由需要这个修改
- 基于当前版本，具体改动啦什么
为了和自动生成的注释保持一致（例如：git merge),一定要是用现在时态祈使句（比如使用change 而不是changed 或 changes）.
版本控制不是备份
版本控制系统具有一个很强大的附带功能，那就是服务器端的备份功能。但是不要把VCS当成一个备份系统，一定要注意。只需要提交哪些有意义的改动。而不要仅仅作为文件存储系统来使用。
使用分支功能
自始至终，Git 的核心就是提供一个快速，简单和灵活的分支功能。分支是一个非常优秀的工具，用来帮助开发人员解决在日常团队开发中存在的代码冲突的问题。因此分支功能应该广泛的运用在不同的开发流程中。比如：开发新的功能，bug fix等等。
合理的工作流程
Git 可以支持很多不同流程：长期分支，特性分支，合并或重置， git-flow等等，选择哪一种流程要取决于如下一些因素：什么项目，什么样的开发，部署模式和团队人员的个人习惯。不管怎样，选择什么样的流程都要得到所用开发人员的认同并且一直遵守他。
使用帮助文档
显示给定git指令的帮助文档
$ git help <command>
开发的在线资源
http://www.git-tower.com/learn
http://www.rogerdudler.github.io/git-guide/
http://www.git-scm.org/
