diff --git a/git-workflows-and-tutorials/images/git-workflow-gitflow-enduserbug.png b/git-workflows-and-tutorials/images/git-workflow-gitflow-enduserbug.png new file mode 100644 index 0000000..1f85c0f Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-gitflow-enduserbug.png differ diff --git a/git-workflows-and-tutorials/images/git-workflow-release-cycle-5createdev.png b/git-workflows-and-tutorials/images/git-workflow-release-cycle-5createdev.png new file mode 100644 index 0000000..3060968 Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-release-cycle-5createdev.png differ diff --git a/git-workflows-and-tutorials/images/git-workflow-release-cycle-6maryjohnbeginnew.png b/git-workflows-and-tutorials/images/git-workflow-release-cycle-6maryjohnbeginnew.png new file mode 100644 index 0000000..c6b17f5 Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-release-cycle-6maryjohnbeginnew.png differ diff --git a/git-workflows-and-tutorials/images/git-workflow-release-cycle-7maryfinishes.png b/git-workflows-and-tutorials/images/git-workflow-release-cycle-7maryfinishes.png new file mode 100644 index 0000000..deabc59 Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-release-cycle-7maryfinishes.png differ diff --git a/git-workflows-and-tutorials/images/git-workflow-release-cycle-8maryprepsrelease.png b/git-workflows-and-tutorials/images/git-workflow-release-cycle-8maryprepsrelease.png new file mode 100644 index 0000000..4d2b850 Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-release-cycle-8maryprepsrelease.png differ diff --git a/git-workflows-and-tutorials/images/git-workflow-release-cycle-9maryfinishes.png b/git-workflows-and-tutorials/images/git-workflow-release-cycle-9maryfinishes.png new file mode 100644 index 0000000..fd800b0 Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-release-cycle-9maryfinishes.png differ diff --git a/git-workflows-and-tutorials/workflow-feature-branch.md b/git-workflows-and-tutorials/workflow-feature-branch.md index da0b39e..84194f7 100644 --- a/git-workflows-and-tutorials/workflow-feature-branch.md +++ b/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) diff --git a/git-workflows-and-tutorials/workflow-gitflow.md b/git-workflows-and-tutorials/workflow-gitflow.md index 81a395f..d915fc8 100644 --- a/git-workflows-and-tutorials/workflow-gitflow.md +++ b/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 +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)