最近公司团队在讨论采用什么样的 Git 分支工作方式，在仔细读了 Atlassian 的官方推荐文章之后，有一些小心得分享下： https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

读前准备

• 这里用 'git-flow' 指代：官方 'Gitflow Workflow'，参考上面链接

git-flow 的应用场景

• 适用于 "larger projects"
• 适用于需要定期 release 的项目

核心：中的核心 feature branch

这是任何的 Git Flow 都会包含的，基础中的基础

请参见： https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

特色：develop 分支

这个分支是个关键，我在思考为什么要存在这个分支？我是否可以不要这个分支？

--1-- 为什么要存在？
下面这张图足以说明：

其存在的意义就是让 master 分支只记录发布历史，而所有的开发分支的集成都发生在 develop 分支。 从图上看很直观，master 的发布历史确实很简洁，而且每次 release 都有一个 tag。

--2-- 我是否可以不要 develop 分支
我的观点是看情况：
从技术层面，我们可以不要，后果就是 master 将成为集成分支，发布历史乱糟糟 而想要一个简洁的发布历史，那么你就需要 develop 分支

看起来是个很容易的决定

但是：

注意再看看上面的应用场景，其中一个是 适用于需要定期release的项目

那如果不是定期 release 的项目呢？

假设现在有个项目是经常有 change request，而且一些是要即时发布，一些是要稍后发布。 ------------ 这里暂且把这个项目叫做 奇怪的项目

那么这两种请求还能同时在 develop 分支工作吗？明显不行了，因为你需要分开部署上线。

对于即时发布的，你需要在完成后第一时间通过 Pull Request 的形式 merge 回 master

对于稍后发布的，你就需要放在另外一个地方存起来等待发布

对于这样的项目，develop 分支，我认为不是最佳的实践

release 分支

release 是从 develop checkout 的，用来做发布用。它存在的意义在于可以解脱 develop 分支，承担了发布的任务，而 develop 分支可以继续开发。 这对于定期发布的项目来讲，确实，堪称完美。

但是对于“奇怪的项目”，release 还能得心应手吗？其实不然，在奇怪的项目中，对于需要即时发布的需求，一天可能会有几个 release，每个 release 存在的周期及其短，这个时候对于 release 分支的维护成本会变得昂贵，而效用变得低下。

那对于非即时发布的需求呢？
这个时候个人觉得，release 分支可以用来存储非即时发布的任务，但是有一点较为关键，要做好 master 到 release 的同步，避免时间太久的 merge conflict 产生

先写这么多吧，跑步去了…… 随意讨论