代码分支管理规范

代码分支管理规范：（主要基于GIT，但SVN也可借鉴）

核心思想：

• 控制代码提交权限，保证主分支和tag分支都是经过测试验证的，保证测试分支不被随意更改。

• 另外支持对提交的代码进行审查。

• 支持多分支并行开发，保证版本管理严谨、不混乱。

从项目仓库A（称之为测试和发布仓库）中master拷贝一个分支出来，例如 branch_1.0.0

这个仓库A，包括它的master和所有分支，只有项目负责人有写权限。

从仓库A克隆出分支branch_1.0.0到仓库X（称之为开发仓库），然后在开发人员在仓库X中开发。

开发和自测完成后，向A仓库发起Pull Request，请求代码审查和合并代码。

项目负责人审查代码，代码合并之后，即可提交测试。测试完一轮之后，开发在仓库X中修复BUG，

然后向仓库A发起Pull Request，请求代码审查和合并代码。如此重复。

最后测试完成后，就将分支branch_1.0.0拿去上线，上线过程中如果需要修改BUG，则开发继续在

仓库X中修复BUG，然后向仓库A发起Pull Request，请求代码审查和合并代码。

上线完成后，由项目负责人将分支branch_1.0.0代码合并至master，同时将分支branch_1.0.0打tag。

（此时理论上master的代码和分支branch_1.0.0是完全一致的）

多分支并行开发，先后测试和上线：

假设同时有版本 branch_1.0.1 和 branch_1.0.2并行开发，

1）当 branch_1.0.1开发完、测试完、上线完之后，branch_1.0.2才准备测试。此时，只需要在合并

测试版本branch_1.0.2时将master的内容一起合并即可，合并之后在进行测试。

2）当 branch_1.0.1、branch_1.0.2几乎同时开发完时，可以合并成一个版本，然后把这个版本提交到branch_1.0.2进行测试。

3）当 branch_1.0.1开发完、测试完但是还没上线时，branch_1.0.2也开发完了准备测试，这种情况同（2）。

4）当 branch_1.0.1、branch_1.0.2开发完，但是需要同时测试时（但不建议同时测试），

那么只能一个分支先测试完上线，另一个分支则需要合并上线后的master再次测试才能上线。