标签：逻辑模块 修改 lock 空白 工作 错误 就会 很多 文档
九个版本控制的中肯建议。
一次提交应该对应一个相关的改动，列如，两个不同的错误应该对应两次不同的提交，使它更容易让其他开发人员明白这个改动，如果这次改动存在问题，也可以方便的回滚到改动之前的状态，通过暂存区标记功能，Git 可以轻松打造非常精准的提交。
经常性的提交改动可以更方便为它作注释，从而更容易确保提交的注释和改动的一致性，通过频繁快速的提交来与其他的开发人员共享这些改动，那样就会避免或减少代码整合时带来的冲突，反之，非常庞大的提交将会增大整合时出现冲突的风险。
对于一个很大的功能模块来说，完成后再提交并不意味着必须整体完成后才可以，而是要把它正确分割成小的完成的逻辑模块进行经常性的提交，一定不要提交一些不完整的改动，仅仅是因为下班。
同样，如果只是为了得到一个干净的工作区域也不需要立即提交，可以通过 Git 的 <
不要提交还没有进过完整测试的改动，只有经过测试，并确定无误的改动才能提交，把改动发送给开发团队其他成员前，必须确定所有修改已经完整测试过。这样才算是真正的完成。
提交注释的开头需要一个少于 50 个字的简短说明，在一个空白的分割行之后要写出一个详细的提交细节。比如回答如下的两个问题：
出于什么理由需要这个修改？
基于当前版本，具体改动了什么？
版本控制系统具有一个很强大的附带功能，那就是服务器端的备份功能，但是不要把 git 当成一个备份系统，一定要注意，只需要提交那些有意义的改动，而不要仅仅作为文件存储系统来使用。
自始至终，Git 的核心及时提供一个快速，简单和灵活的分支功能，分支是一个非常优秀的工具，用来帮助开发人员解决在日常团队开发中存在的代码冲突问题，因此分支功能应广泛的运用在不同的开发流程中，比如：开发新功能，修错等等。
Git 可以支持很多不同的流程：长期分支，特性分支，合并或是重置，git-flow 等等。选择哪一种流程要取决于如下一些因素：什么项目，什么样的开发，部署模式和（可能是最重要的）开发团队人员的个人习惯。不管怎样，选择什么样的流程都要得到所用开发人员的认同并且一直遵循它。
$ git help <command>本文由个人 hexo 博客 co2fe.com 迁移
date: 2017-11-06 21:28:53
标签：逻辑模块 修改 lock 空白 工作 错误 就会 很多 文档
原文地址：https://www.cnblogs.com/manastudent/p/10190932.html
