研发对于代码管理

git开发规则

主要分支

在介绍git开发规则前，先了解一下主要分支的概念。主要分支有两条：master分支和develop分支。

master分支记录了每个已发布的版本，分支上每一个提交点代表一个发布版本，每个提交点注明了版本号和版本内容变更。这样，使用者便能清楚地掌握发布版本的情况和方便地恢复到特定版本。 master分支在创建仓库的时候自动被创建。

develop分支主要用作功能开发，所有的开发工作将紧紧围绕develop分支进行。一般情况下，在创建仓库后，就应该从master中checkout出develop。

git开发规则

根据使用者的目的，可以总结出以下3个git开发规则：新功能开发、发布版本、热修复。使用者应该按对应的规则进行工作。

新功能开发

新功能开发就是添加新的功能。其规则如下：从develop分支checkout出新的分支（定义为功能分支，以feature/xxx-xxx-xxx命名）进行开发，开发完成后功能分支合并回develop，最后删除功能分支。

发布版本

当develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，便可考虑开始发布版本的工作。其规则如下：从develop分支上checkout一个分支用于发布工作（定义为发布分支，以release/xx.xx.xx命名）。发布工作完成后，将发布分支合并到master分支并以版本号打好Tag，同时那些从新建发布分支以来做的修改要合并回develop分支。

发布工作是指：测试、Bug修复、文档生成等。注意，新的功能不应再加到发布分支。

热修复

当想要快速给已发布版本打补丁时，就是进行热修复工作。其规则如下：直接从master分支checkout出新的分支开展修复工作（定义为热修复分支，以hotfix/xxx-xxx-xxx命名），修复完成后，修改应该马上合并回master分支和develop分支，master分支应该采用新的版本号，并打好Tag。

细节：合并

以上提及的所有合并动作，都不应以直接merge的方式，而应该squash merge的方式。为什么呢？举个例子，新功能开发时，功能分支A从develop checkout以后，有了多次提交，包括临时提交和各种琐碎的提交，如果合并回develop时直接merge，会导致这些提交都会记录到develop上面。这明显不是我们想要的。这时采用squash merge的方式，能够把这些提交合并成一个提交，最后develop上只会多出这个提交记录。

细节：注释规范

commit的注释规范如下：

feat： 新增feature

fix: 修复bug

docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等

style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑

refactor: 代码重构，没有加新功能或者修复bug

perf: 优化相关，比如提升性能、体验

test: 测试用例，包括单元测试、集成测试等

chore: 改变构建流程、或者增加依赖库、工具等

revert: 回滚到上一个版本

多人合作开发

很多情况下，项目会通过码云、阿里云、github等工具进行多人合作开发。这种情况下，上面的规则依然能够适用，但是有另外一些细节需要注意。

合并到主要分支需要权限

在多人合作的情况下，为了保证代码质量，增加了代码审核流程。这种情况下，项目开发者不能直接将其他分支合并进master或develop分支，而是通过发起merge request（或称pull request），由项目的维护者进行审核和合并。

分支状态的一致性

从本地分支checkout出其他分支时，需要留意本地分支是否已经与对应的远程分支同步。举个例子，新功能开发时，如果从没有和远程同步的本地develop分支checkout出功能分支，可能会给后续的合并造成不顺利。

merge requst前的工作

在发起merge request前，例如A merge to B，最好先将B分支merge到A。例如，开发者在新功能开发完毕后即将发起功能分支对远程develop的merge request，如果这时他能先将当前远程develop分支合并到功能分支并解决掉发生的冲突的话，能够有效减少维护者在合并阶段可能遇到的解决冲突工作。