git flow 工作流

Git作为一个源码管理系统，不可避免涉及到多人协作。协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。–阮一峰《git flow 工作流》

    浅谈个人对于git flow 的理解:
    大型项目开发，团队协作，频繁的提交代码，尤其对于今天来讲敏捷开发已经成为主流的开发方式。我们如何保证在这种情况下项目依然井然有序，进行发展下去。再如某个项目开发周期稍长结果可想而知就频繁冲突是必然，那么如何简化工作流程制定选用合理的工作流就显得尤为关键。

---

    以下是我在工作生活中总结的git flow 模型:

• git flow 常用分支

      1.master 分支
      是分支的根源，不能直接修改，只能有其他分支归并始终保持最新的代码。master 创建的分支 develop,release,staging,hotfix(紧急bug下)。
      2.develop 分支
      主开发分支，包含着所有要发布下一个release的代码,主要与feature特性分支合并。
      2.1 feature 分支
       特性分支，主要是开发一个功能，开发完成后，归并到develop分支，进行上线前下一步准备。
      3.staging 分支
      预生产分支，高仿真环境测试为项目顺利发版把关，通过后，进入下一个release。
      4.release 分支
      由master分支创建，主要作用是项目发布上线。发布上线后分别归并release分支代码到master(归并后需要打一个release版本的tag)，develop，staging。
      5.Hotfix 分支
      由master分支创建，作用紧急bug需求立即修复。完成归并至release分支，进行上线。

• 具体流程
  
      1.master分支创建develop、staging、release、hotfix;
      2.develop分支创建特性分支，例如：feature_v1.0.9_xx（feature_版本_某次需求）；
      3.特性分支开发完成发布到测试环境完成测试;
      4.特性分支合并到staging分支在高仿真环境下完成灰度测试;
      5.校验完毕上线发版合并staging分支到release分支发版上线;
      6.发版完毕，归并release分支到master分支，归并release分支到develop分支，归并release分支到staging分支（仅步骤7过来时执行）
      7.紧急bug修复，master分支创建hotfix分支，bug修复测试完成，合并到release分支，上线；上线完毕，执行步骤6