complete workflow-gitflow draft

git-workflows-and-tutorials/workflow-feature-branch.md

@@ -139,7 +139,7 @@ git push
 :beer: 下一站
 -----------------
 
-现在但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。
+到了这里，但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。
 另外，功能分支还使用了`Pull Request`，使得可以在你的版本控制`GUI`客户端中讨论某个提交。
 
 功能分支工作流是开发项目异常灵活的方式。问题是，有时候太灵活了。对于大型团队，常常需要给不同分支分配一个更具体的角色。
@@ -147,4 +147,4 @@ git push
 
 -----------------
 
-[集中式工作流 »](workflow-centralized.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[`Gitflow`工作流 »](workflow-gitflow.md)
+[« 集中式工作流](workflow-centralized.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[`Gitflow`工作流 »](workflow-gitflow.md)

git-workflows-and-tutorials/workflow-gitflow.md

@@ -56,3 +56,148 @@
 ### 维护分支
 
 ![](images/git-workflow-release-cycle-4maintenance.png)
+
+维护分支或说是热修复（`hotfix`）分支用于生成快速给发布版本打补丁，是唯一可以从`master`分支`fork`出来的分支。
+一旦修复完成，修改要合并回`master`分支和`develop`分支（当前的发布分支），`master`分支应该用新的版本号打好`Tag`。
+
+为`Bug`修复使用专门线路，让团队处理问题而不用打断其它工作或等待下一个发布循环。
+你可以把维护分支想成一个直接基于`master`分支的暂时分布。
+
+:beer: 示例
+---------------------
+
+下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。
+
+### 创建开发分支
+
+![](images/git-workflow-release-cycle-5createdev.png)
+
+第一步为`master`分支配套一个`develop`分支。简单来做可以[本地创建一个空的`develop`分支](https://www.atlassian.com/git/tutorial/git-branches#!branch)，`push`到服务器上：
+
+```bash
+git branch develop
+git push -u origin develop
+```
+
+这个分支包含了项目的全部历史，而`master`分支包含了删减版的历史。然后其它开发者应该克隆中央仓库，建好`develop`分支的跟踪分支：
+
+```bash
+git clone ssh://user@host/path/to/repo.git
+git checkout -b develop origin/develop
+```
+
+现在每个开发都有了历史分支的本地拷贝。
+
+### 小红和小明开始开发新功能
+
+![](images/git-workflow-release-cycle-6maryjohnbeginnew.png)
+
+这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。各自的新分支不是基于`master`分支，而是应该[基于`develop`分支](https://www.atlassian.com/git/tutorial/git-branches#!checkout)：
+
+```bash
+git checkout -b some-feature develop
+```
+
+他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：
+```bash
+git status
+git add <some-file>
+git commit
+```
+
+### 小红完成功能开发
+
+![](images/git-workflow-release-cycle-7maryfinishes.png)
+
+添加了提交后，小红觉得她的功能OK了。如果团队使用`Pull Requests`，是个合适的时候发起一个合并到`develop`分支。
+否则她可以直接合并到她本地的`develop`分支后`push`到中央仓库：
+
+```bash
+git pull origin develop
+git checkout develop
+git merge some-feature
+git push
+git branch -d some-feature
+```
+
+第一条命令在合并功能前确保`develop`分支是最新的。注意，功能决不应该直接合并到`master`分支。
+冲突解决方法像[集中式工作流](workflow-centralized.md)一样。
+
+### 小红开始准备发布
+
+![](images/git-workflow-release-cycle-8maryprepsrelease.png)
+
+这个时候小明正在实现他的功能，小红开始准备她的第一个项目正式发布。
+像功能开发一样，她用一个新分支来完成发布准备。这一步也确定了发布的版本号：
+
+```bash
+git checkout -b release-0.1 develop
+```
+
+这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方。像是一个专门用于改善发布的功能分支。
+
+只要小红创建这个分支并`push`到中央仓库，这个发布就是功能冻结的。任何不在`develop`分支中的新功能都推到下个发布循环中。
+
+### 小红完成发布
+
+![](images/git-workflow-release-cycle-9maryfinishes.png)
+
+一旦可以对外发布，小红合并修改到`master`分支和`develop`分支上，删除发布分支。合并回`develop`分支很重要，因为在发布分支中已经提交的更新需要在新功能中也有的。
+另外，如果小红的团队要求`Code Review`，这是一个发起`Pull Request`的理想时机。
+
+```bash
+git checkout master
+git merge release-0.1
+git push
+git checkout develop
+git merge release-0.1
+git push
+git branch -d release-0.1
+```
+
+发布分支是作为功能开发（`develop`分支）和对外发布（`master`分支）间的缓冲。只要有合并到`master`分支，就应该打好`Tag`以方便跟踪。
+
+```bash
+git tag -a 0.1 -m "Initial public release" master
+git push --tags
+```
+
+`Git`有提供勾子（`hook`），即仓库有事件发生时触发执行的脚本。
+可以配置勾子，在你`push`中央仓库的`master`分支时，自动执行对外发布的构建。
+
+### 最终用户发现`Bug`
+
+![](images/git-workflow-gitflow-enduserbug.png)
+
+对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有最终用户开了一个`Ticket`抱怨当前版本的一个`Bug`。
+为了处理`Bug`，小红（或小明）从`master`分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回`master`分支：
+
+```bash
+git checkout -b issue-#001 master
+# Fix the bug
+git checkout master
+git merge issue-#001
+git push
+```
+
+就像发布分支，维护分支中新加重要修改需要合到`develop`分支中，所以小红要执行一个合并操作。然后就可以安全地删除这个分支了：
+
+```bash
+git checkout develop
+git merge issue-#001
+git push
+git branch -d issue-#001
+```
+
+:beer: 下一站
+-----------------
+
+到了这里，但愿你已经对[集中式工作流](workflow-centralized.md)、[功能分支工作流](workflow-feature-branch.md)和`Gitflow`工作流感觉很舒适了。
+你应该牢固的掌握了本地仓库的潜能，`push`/`pull`模式和`Git`健壮的分支和合并模型。
+
+记住，这里展示的工作流只是可能例子，而不是在工作中使用`Git`不可违逆的条例。所以不畏惧去接受或忽略另一个工作流的某些用法。
+不变的目标就是让`Git`为你所用。
+
+-----------------
+
+[« 功能分支工作流](workflow-feature-branch.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[`Forking`工作流 »](workflow-forking.md)