Question

在看这部分前，请先回顾阅读业界认可的成功的 Git Branch Work Flow 模型 A Successful Git Branching Model ，了解日常开发中的场景，有助于熟悉下面的使用过程。

在企业开发中，使用 Git 作为版本控制软件最看重的还是结合公司自己搭建的 Gitlab ，将 Code Review 加入打包部署持续集成的流程中，这样，代码开发完成，提交测试前，便可以对开发人员提交的代码进行 Review，发现潜在的问题，及时指导，对于新人来讲，也能更快更好的学习。

解决的需求场景如下：

• 能支持日常迭代开发、紧急线上 bug 修复、多功能并行开发
• 大概 50 人左右的团队，平日迭代项目较多，且周期短（1~2 周一个迭代）
• 能够通过 tag 重建整个系统
• 支持 code review
• 所有上线的代码必须都是经过测试保证，且能自动同步到下一次的迭代中
• 能和公司的项目管理/持续集成系统整合

上图就是 xirong 团队在日常开发中总结出来的适合企业开发的模式，下面进行简单的介绍，方便大家学习了解，欢迎提交 Issue 进行讨论。（本模式适合敏捷开发流程，小迭代上线，传统的瀑布开发模型并没有进行测试）

1. 迭代需求会、冲刺会后确定本次迭代的目标后，将迭代内容视为一个项目，在 Gitlab 上创建一个 Repository，初始化工程代码结构，根据上线日期，比如 20150730 上线，开出分支 release20150730、dev20150730 两个分支，dev 分支作为日常开发主干分支，release 分支作为提测打包、Code Review 的分支。
2. 迭代开始，日常开发进行中，开发人员在 dev 分支上进行 Commit、Push 代码，并且解决掉日常协同开发中的冲突等问题，等到达到提测条件的时候，提测者，首先 Merge Master 分支上的最新代码 git merge --no-ff origin/master ，使得 Master 分支上的变更更新到迭代开发分支 dev 上面，之后，在 Gitlab 上面发起 pull request 请求，并指定 Code Review 人，请求的分支选择本次上线的 release 分支，即 release20150730。
3. 被指定 Code Review 的人，对发起者的代码 Review 后，决定是否可以提交测试，若有问题，评论注释代码后，提交者对代码进行进行修改，重复步骤 2，直到代码 Review 者认为 Ok。之后便可以借助自己公司的打包部署，对这些代码发布到测试环境验证。
4. 步骤 2-3 重复多次后，就会达到一个稳定可发布的版本，即上线版本，上线后，将 release 版本上面最后的提交（图中 0.2.4 上线对应处）合并到 Master 分支上面，并打 Tag0.3。至此，一次完整的迭代开发完成。
5. 若此次上线后，不久发现生产环境有 Bug 需要修复，则从 Tag 处新开分支 release_bugfix_20150731、dev_bugfix_20150731 ，开发人员从 dev_bugfix_20150731 分支上进行开发，提测 code review 在 release_bugfix_20150731 分支上，具体步骤参考 2-3，测试环境验证通过后，发布到线上，验证 OK，合并到 Master 分支，并打 Tag0.2.3，此次 Bug 修复完毕，专为解 Bug 而生的这两个分支可以退伍了，删除 release_bugfix_20150731、dev_bugfix_20150731 两分支即可。（所有的历史 Commit 信息均已经提交到了 Master 分支上，不用担心丢失）

这样经过上面的 1-5 步骤，企业日常迭代开发中的代码版本控制基本上就 Ok 了，有问题欢迎 Issue 讨论。