git 版本管理

应用的是 Git flow 这个工作流是 Vincent Driessen 2010 年发布出来的分支管理模型，热度非常高，我安利的也是这个，公司管理项目也是这么玩的。

• 按功能划分，可分为 5 种分支 Master、Develop、Release、Feature 和 Hotfix；

• 按生命周期划分，可分为 长期分支和暂时分支，更贴切地说，主要分支和协助分支；

  分支	分支名称	生命周期	描述
  Master	主分支	长期	从这个分支上检出的都是稳定的发布版，版本发布后记得打上 git 标签。好处是，在测试的时候，不影响下一个版本功能并行开发
  Release-hotfix	修复分支	暂时	用于线上紧急 bug 修复，修复后，合并回 Master 和 Develop，然后删除分支
  Release	预发分支	暂时	从 Develop 检出 Release 分支，修改后提交，测试发布后，合并到 Master 和 Develop，然后删除分支
  Develop	开发分支	长期	用于日常开发，存放最新的功能，完成一个版本合并到这里
  Feature	功能分支	暂时	用来做功能开发，从 Develop 检出，有 5 个人开发可建 5 个 Feature-* 分支，完成后再合并到 Develop，然后删除分支

总结一下

规则

1. 规则一：Master 为保护分支,Release-hotfix、Develop 分支由此检出，Release-hotfix、Release 分支最终合并到此。

2. 规则二：Develop 为保护分支，Feature、Release 分支由此检出，Feature、Release、Release-hotfix 分支最终合并到此。

3. 规则三：打 Tag，Release-hotfix、Release 发布后合并到 Master，与此同时必须打 Tag。

   TIP

   以上操作由各组 Leader 或架构师完成。

4. 规则四：Master、Develop 不允许任何 Commit 操作行为；只允许通过 Merge Requests 合并。

5. 规则五：所有针对 Master、Develop 的 Merge Requests，需要架构师或者我 完成 Code Review 之后才行。

建议

1. 建议一：所有被合并的暂时分支可以删除。