企业开发git工作流模式探索部分休整

Author: xirong

git-workflow-tutorial.md

@@ -1087,7 +1087,7 @@ git push origin some-branch
 
 #### 小明接受`Pull Request`
 
-最终，小明接受变更，合并功能分支到`master`分支，并关闭`Pull Request`。
+最终，小明接受变更，合并功能分支到`Master`分支，并关闭`Pull Request`。
 至此，功能集成到项目中，其它的项目开发者可以用标准的`git pull`命令`pull`这些变更到自己的本地仓库中。
 
 
@@ -1099,16 +1099,27 @@ git push origin some-branch
 
 # 三、企业日常开发模式探索
 
-![图片](images/branch_module.png)
+在看这部分前，请先回顾阅读业界认可的成功的 Git Branch Work Flow 模型 [A Successful Git Branching Model](http://nvie.com/posts/a-successful-git-branching-model/) ，了解日常开发中的场景，有助于熟悉下面的使用过程。
+
+在企业开发中，使用 Git 作为版本控制软件最看重的还是结合公司自己搭建的 [Gitlab](https://about.gitlab.com/)，将 Code Review 加入打包部署持续集成的流程中，这样，代码开发完成，提交测试前，便可以对开发人员提交的代码进行 Review，发现潜在的问题，及时指导，对于新人来讲，也能更快更好的学习。
+
+解决的需求场景如下：
 
-在企业开发中，使用git作为版本控制软件最看重的还是结合公司自己搭建的 [gitlab](https://about.gitlab.com/)，将 code review 加入打包部署持续集成的流程中，这样，代码开发完成，提交测试前，便可以对开发人员提交的代码进行review，发现潜在的问题，及时指导，对于新人来讲，也能更快更好的学习。
+- 能支持日常迭代开发、紧急线上bug修复、多功能并行开发
+- 大概50人左右的团队，平日迭代项目较多，且周期短（1~2周一个迭代）
+- 能够通过tag重建整个系统
+- 支持code review
+- 所有上线的代码必须都是经过测试保证，且能自动同步到下一次的迭代中
+- 能和公司的项目管理/持续集成系统整合
+
+![图片](images/branch_module.png)
 
-上图就是 xirong 团队在日常开发中总结出来的适合企业开发的模式，下面进行简单的介绍，方便大家学习了解，欢迎提交 issue 进行讨论。（本模式适合敏捷开发流程，小迭代上线，传统的瀑布开发模型并没有进行测试）
+上图就是 xirong 团队在日常开发中总结出来的适合企业开发的模式，下面进行简单的介绍，方便大家学习了解，欢迎提交 Issue 进行讨论。（本模式适合敏捷开发流程，小迭代上线，传统的瀑布开发模型并没有进行测试）
 
-1. 迭代需求会、冲刺会后确定本次迭代的目标后，将迭代内容视为一个项目，在 gitlab 上创建一个repository，初始化工程代码结构，根据上线日期，比如20150730上线，开出分支 release20150730、dev20150730 两个分支，dev 分支作为日常开发主干分支，release分支作为提测打包、codereview的分支。
-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. 迭代需求会、冲刺会后确定本次迭代的目标后，将迭代内容视为一个项目，在 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 讨论。
+这样经过上面的1-5步骤，企业日常迭代开发中的代码版本控制基本上就 Ok 了，有问题欢迎 Issue 讨论。