Git Flow工作流总结

---

GitFlow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。

GitFlow 工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

1、Git Flow常用的分支

• Master分支：
  也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
• Develop 分支：
  这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
• Feature 分支：
  这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
• Release分支：
  当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
• Hotfix分支
  当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

2、Git Flow如何工作

创建开发分支（develop）

为 master 分支配套一个 develop 分支。简单来做可以本地创建一个空的 develop 分支，push 到服务器上：

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好 develop 分支的跟踪分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

创建功能分支（ 分支命名规则: feature-* ）

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。新功能提交应该从不直接与master分支交互。

git checkout -b feature-some develop

功能分支上：编辑、暂存、提交：

git status
git add
git commit
git pull
git push

功能 开发测试没有问题后了。如果团队使用 Pull Requests，这时候可以发起一个用于合并到 develop 分支。否则直接合并到本地的 develop 分支后 push 到中央仓库。

git pull origin develop
git checkout develop
git merge --no-ff feature-some
git push origin develop
git branch -d feature-some
# If you pushed branch to origin:
git push origin --delete feature-some   

创建发布分支(分支命名规则: release-*)

Release分支基于Develop分支创建，打完Release分支之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)。

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

新的分支来做发布准备，确定了发布的版本号，并创建分支。这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。

git checkout -b release-0.1.0 develop

只要创建这个分支并 push 到中央仓库，这个发布就是功能冻结的。任何不在 develop 分支中的新功能都推到下个发布循环中。一旦准备好了对外发布，release分支合并修改到 master 分支和 develop 分支上，最后删除release分支。合并回 develop 分支很重要，因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。另外，如果团队要求 Code Review，这是一个发起 Pull Request 的理想时机。

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 以方便跟踪。

git tag -a 0.1 -m "Initial public release" master
git push --tags

创建维护分支(分支命名规则:hotfix-*)

对外发布后，处理项目Bug。为了处理 Bug，从 master 分支上拉出了一个hotfix分支，提交修改以解决问题，然后直接合并回 master 分支：

git checkout -b hotfix-#001 master
# Fix the bug
git checkout master
git merge hotfix-#001
git push

就像release分支，hotfix分支中新加这些重要修改需要包含到 develop 分支中，所以要执行一个合并操作，合并到develop分支，然后就可以安全地删除这个分支了。

git checkout develop
git merge issue-#001
git push
git branch -d issue-#00