版本控制-最佳实践

2018-07-01 本文已影响0人塞上牧羊空许约

提交要对应修改

一次提交应该对应一个相关的改动。例如：两个不同的错误应该对应两次不同的提交，使它更容易让其他开发人员明白这个改动，如果这次改动存在问题，也可以方便的回滚到改动之前的状态。通过暂存区标记功能，Git可以轻松打造非常精确的提交。

经常的提交改动可以更方便地为它做注释，从而更容易确保提交的注释和改动的一致性。通过频繁的提交来与其他的开发人员共享这些改动，那样就会避免或减少代码整合时带来的冲突。反之，非常庞大的提交将会增大整合时出现冲突的风险。

对于一个很大的功能模块来说，完成后在提交并不意味这必须整体完成后才可以，而是要把它正确分割成小的完整的逻辑模块进行经常性的提交。一定不要提交一些不完整的改动，仅仅是因为下班。
同样，如果只是为了得到一个干净的工作区域也不需要立刻提交。可以通过Git的Stash命令把这些改动移到另外的分支。

不要提交还没有经过完整测试的改动。只有经过测试，并确定无误的改动才能提交。把改动发送给开发团队其他成员前，必须确定所有修改已经完整测试过。这样才算真正的完成。

提交注释的开头需要一个少于50个字的简短说明。在一个空白分割行之后要写出一个详细的提交细节。比如回答如下的两个问题：

出于什么理由需要这个修改
基于当前版本，具体改动啦什么
为了和自动生成的注释保持一致（例如：git merge),一定要是用现在时态祈使句（比如使用change 而不是changed 或 changes）.

版本控制系统具有一个很强大的附带功能，那就是服务器端的备份功能。但是不要把VCS当成一个备份系统，一定要注意。只需要提交哪些有意义的改动。而不要仅仅作为文件存储系统来使用。

自始至终，Git 的核心就是提供一个快速，简单和灵活的分支功能。分支是一个非常优秀的工具，用来帮助开发人员解决在日常团队开发中存在的代码冲突的问题。因此分支功能应该广泛的运用在不同的开发流程中。比如：开发新的功能，bug fix等等。

Git 可以支持很多不同流程：长期分支，特性分支，合并或重置， git-flow等等，选择哪一种流程要取决于如下一些因素：什么项目，什么样的开发，部署模式和团队人员的个人习惯。不管怎样，选择什么样的流程都要得到所用开发人员的认同并且一直遵守他。

显示给定git指令的帮助文档
$ git help <command>