image.png
- git flow init
- git flow feature start xxx
- git flow feature finish xxx
- git flow release start 0.1.xx
- git flow release finish 0.1.xx
- git flow hotfix start xxx
- git flow hotfix finish xxx

Git flow如何工作

  • Master: 用来放稳定、随时可上线的版本。只能从别的分支合并过来，不能直接提交到master
  • Develop: 所有开发的基础分支，新feature分支从这出去，也会合并回这来
  • Hotfix: 线上环境出bug，从master开一个hotfix，进行修复，修复完成后，合并回master和develop分支
  • Release: develop分支准备好后，合并到release，经过最终测试并修改，通过测试后，合并回master和develop
  • Feature: 开发新功能，从develop来，最终合并到develop去

    初始分支

    所有在Master分支上的Commit应该Tag
    image.png

Feature 分支

分支名 feature/*
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留
image.png

Release分支

分支名 release/*
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
image.png

Hotfix维护分支

分支名 hotfix/*
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
image.png

Git flow 的问题

合并冲突
合并冲突在使用 Git Flow 是非常常见。原因很简单：如果你有多个并行功能分支，他们长时间存在，那么很可能在代码库的相同部分在两个不同的分支中被更改。合并冲突不仅对于需要手动解决的开发人员来说是令人沮丧的。这也增加了在代码中破坏某些功能的风险，因为当你不得不决定使用哪个版本代码时，很容易犯错。即使你把一个分支合并到另一个分支时你做的都是正确的，可能也会发生这两个特性的组合影响了你的代码。

构建
功能分离
在合并到一个分支之前，你是不能测试两个功能的组合。当你在单独的分支机构中开发几天甚至几周的功能时，由于两个功能的相互作用而产生的问题发生了。当你对这些问题反映迟缓时，你可能不得不改变你为新功能编写的代码的更多部分。这意味着你已经浪费了很多的时间来创建你不再需要的代码。

许多不同的功能分支也可能会让你的软件的手动测试人员感到困惑。他们总是必须知道在哪个临时环境中可以找到新功能。不同的阶段环境通常也意味着不同的构建任务，用于监控任务的不同屏幕等。

不可预测的发布
Git Flow 还有另一个问题，这是以上两点的结果：如果功能分支尚未合并，则不可能知道需要多少时间才能发布。你不知道它是因为你不知道哪个合并会发生冲突，你也不知道新功能将如何相互影响。不能在任何时候发布将使你缺乏信心。

特点

首先，项目存在两个长期分支。

  • 主分支master
  • 开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支。

  • 功能分支（feature branch）
  • 补丁分支（hotfix branch）
  • 预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

Git flow的优点是清晰可控

  1. 职责清晰：每个分支都有明确的定位，从哪儿来，到哪去，都很明确
  2. 在制品分离：未完成的功能只存在于feature分支，不会污染到其它分支

缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。

  1. 分支较多，合并无处不在：光基础分支就4个，再加上feature分支
  2. 规则复杂：因为职责分得很细，学习成本和维护成本就会随之上升
  3. 频繁发布成本高：如果是一个很小的feature，很快就能开发完，我还是切到一个新的分支上，并且合并回来
  4. master 分支历史记录并不干净，只能通过打 Tag 标记哪些是 master 真正要部署的

更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。不适合“持续发布”的网站开发。

  • 适合同时开发多个版本，互相不影响
  • 适合较重的项目，有长周期的功能开发

不知道什么原因，ThoughtWorks这些年一直在抨击GitFlow模型，一年比一年严肃，后面我们会分析一下如何优化；

2011年：停用GitFlow的Feature分支
Disappointingly, we continue to see development teams embrace the practice of feature branching to isolate work and defer integration. Feature branches commonly cause significant pain and unpredictability during late merges, but more importantly prevent the continual design improvement necessary to maintain high quality software. We recommend continuous integration and branch by abstraction as an alternative to feature branching.

2015年：停用GitFlow的长时分支
Gitflow is a strict branching pattern for releases using Git. Although not an inherently bad pattern, we often see it misused. If the feature and develop branches are short lived and merged often, you are really using the power of Git, which makes these activities easy. However, a problem we often see is that these become long lived branches, which results in the dreaded merge conflicts many people began using Git to escape. A merge is a merge. Regardless of the source control tool or pattern you use. If you wait more than a day or two to merge, you could hit a big merge conflict. This becomes a real issue if you have a larger team. If you have more than a few people waiting to merge, you can have a serious a bottleneck. Introducing patterns like Gitflow require the discipline to merge often to be successful. So by all means use the pattern, but only if you have the discipline to prevent long lived branches

2016年：停用GitFlow
We firmly believe that long-lived version-control branches harm valuable engineering practices such as continuous integration, and this belief underlies our dislike for Gitflow. We love the flexibility of Git underneath but abhor tools that encourage bad engineering practices. Very short-lived branches hurt less, but most teams we see using Gitflow feel empowered to abuse its branch-heavy workflow, which encourages late integration (therefore discouraging true continuous integration).

这些内容的核心在于GitFlow重视管理，强调多分支开发，会造成集成滞后，合并困难，影响持续集成。在2016年发布的文章中，TW给出了几个其他的建议，包括推荐GitHub Flow 和 Trunk-Based Development