git 分支管理实践

开发流程

1. 如图步骤1， master对开发者只有读权限，开发者从master拉取并新建feature_xxxx分支进行开发
2. 如图步骤2，开发完成后，提测时，基于feature_xxxx分支新建release_1_0_0分支，并把其它feature分支合并到release_1_0_0分支中。
3. 如图步骤3，release_1_0_0分支测试完成后，设置分支写保护。发布完成后。将release_1_0_0分支合并/覆盖回master,并在master中创建标签release_1_0_0

针对线上紧急问题创建hotfix

如上面所示，开发中遇到线上bug, 则基于release_1_0_0创建hotfix_1_0_0_关于xxx的修复。合并到release_1_0_0中并发布，发布完成后要合并到master中并创建标签[release_1_0_0_with_hotfix_关于xxx的修复]
然后，如图中release_2_0_0已经提测，那么就要将hotfix也合并到该分支中。如果release_2_0_0还未提测，即该分支不存在。那么要将hotfix合并到【feature 下一迭代需求集】的至少一个分支中。即保证下一代分支中包含了该hotfix.

运维与人员管理

1. Jenkins中拉取的每个迭代的release分支进行测试、生产环境的部署。所以每次提测，发布，需要修改jenkins中拉取的地址。
2. 少部分人员拥有master的管理权限，对分支进行写保护操作的权限。在生产发布后，要对release分支进行写保护，并对master分支进行合并，打标签操作。
3. 一个迭代在测试中时，不能进行另一个新的迭代的开发，即迭代无法并行。因为master是基于上一版本的release创建的，是新一版本的基准。
4. 在该模式中，master扮演了当前生产运行版本与下一迭代基准版本的角色，并在其中打标签的操作，也保证了master记录下了整个版本历史。如同一个备份。
5. release_1_0_0, release_2_0_0…分支累积的过多时，可以将过久的一些加以清除。