Git 官方 Gitflow Workflow 不适用于所有项目

hiveer · 2020年03月06日 · 最后由 lanzhiheng 回复于 2020年03月07日 · 3854 次阅读

最近公司团队在讨论采用什么样的 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 产生

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

个人觉得吧,官方的 Gitflow 给出的只能说是一份参考,或者说是基石。并不能把它当成像是军队守则那样必须去遵守的东西。我工作中参加过不少的项目,基本上都是根据不同项目的需求来对 Gitflow 做出一些调整,简化。

我现在公司的大部分项目都是周期较短的项目以 develop 来作为主开发分支,发布版本的时候才会合并到 master 去,偶尔会有大功能需要开发的话则从develop拉出一个分支来做主分支比方说feature-for-post,接下来会基于这个分支feature-for-post来做开发,develop那边也会因为要修 bug 而有一些新的 commit。由于我们没有走rebase merge, 正式把feature-for-post合并到develop之前还需要先将develop合并到feature-for-post然后再把功能分支合并到develop避免冲突。可能对于一些开发周期比较短,需要组员之间相互 Review 的项目,并且需要对何人提交代码,何人合并代码,这些记录进行跟踪的项目比较合适这种流程。

另外还参与过一个外包的需要长期维护的项目,有专门的人员来 Review 代码, 于是也就不需要去跟踪到底是谁合并了你的代码,此时可以走rebase merge 。当时只需要一条master分支,我们的组员都基于这条分支来做开发,需要提交 MR 的时候则 rebase 一下 master 好处就是 commit log 更加简洁。

两种流程差别较大,也无关对错,都是基于原来 Gitflow 根据项目本身的特征做出的调整。如果让我选我会选择第二种,因为能少很多 commit log,适合个人项目。我觉得公司也一样,每个公司会根据自身项目的特征以及采取的合并方案去调整原来的 Gitflow,总能找到比官方 Gitflow 更舒服的解决方案。

@lanzhiheng 我也觉得应该根据场景的不同来制定不同的方案。

你说的第一种方案中避免冲突的那块没有看懂,先把 develop 合并到 feature-for-post,也不能避免冲突啊,你合并的时候其实就把冲突解决了。

你说的第二种方案,我觉得挺神奇的,没有这样干过。你还是应该有 feature branch 吧。最后合并的时候怎么操作的? 是:

git checkout feature
git rebase master

还是

git checkout master
git rebase feature
hiveer 回复

第二种情况是

@master > git checkout feature
@feature > git rebase master

然后再发 MR,经常需要 rebase 解决冲突。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号