Git详解(补2) 多分支开发思路

分支数量

一个健壮、稳定、可持续开发的代码仓库应该具备以下 5 类分支：

1. master 分支：主分支，负责项目发布。
2. develop 分支：开发分支，开发主分支。
3. feature 分支：新特性（新功能）分支，开发副分支。若项目有多个新特性需要开发，那么同一时间内可能会存在多个 feature 分支。新特性开发完成后，各 feature 分支需要合并到 develop 分支上。
4. release 分支：发布分支，测试分支。当项目开发到一定程度/某个新特性开发完成，应该在 develop 分支上检出 release 分支并交由测试人员测试。release 分支上的测试、bug 修复都完成后，需要合并到 develop 分支和 master 分支。
5. hotfix 分支：热修复分支，负责处理 master 分支上出现的紧急 bug。

示意图如下：

 

多分支思路

1、当项目下一版本的需求确定后，直接从 develop 分支检出多个 feature 分支，各开发团队在相应的 feature 分支上开发。某个开发团队的需求实现、自测、bug 修复后，就可以将相应的 feature 分支合并到 develop 分支，同时从 develop 分支检出 release 分支（此时可以删除该 feature 分支）。 

2、测试人员在以单个 release 分支为基础构建的测试环境中，分别测试新版本的部分需求。如果发现 bug，开发人员直接在此 release 分支上修复 bug，直到完全没有问题。单个 release 分支测试、bug 修复结束后，需要合并回 develop 分支。所有 release 分支全部合并到 develop 分支后，再从 develop 分支检出新的 release 分支供测试人员进行新版本的集成测试。

3、集成测试的 release 分支上的测试、bug 修复结束后，需要合并到 develop 分支和 master 分支，同时给 master 分支打 tag 版本号，然后上线。

4、项目上线后，测试人员测试线上版本。如果出现 bug，从 master 分支检出 hotfix 分支，开发人员在 hotfix 分支上直接修改 bug 并合并到 develop 分支和 master 分支，直到没有问题。