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