未分類
15 4 月 2020

gitflow 在开发中的一个疑惑

gitflow 在开发中的一个疑惑

資深大佬 : hakono 47

按照 gitflow 的流程，开发时有 Develop Release Master 三个主要分支，

普通的 gitflow 开发流程就是：

  1. 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
  2. 新功能开发完成后 feature 合并入 Develop 分支
  3. 然后 Develop 合并入 Release 分支
  4. 最后确认无误后 Release 合并入 Master 分支正式发布到生产环境

但是最近在使用这套流程的时候遇到了个非常大的问题，而所有讲解 gitflow 的文章都似乎特意避开了这个问题不谈，明明是实际开发的话一定会遇到的问题，所以来问问大家怎么解决

问题：

同时有两个新功能需要开发，我们就叫 feature/01 feautre/02 吧

两个功能开发完毕，先后合并入了 Develop 进行线上 dev 环境的测试。

那么然后问题就来了，如果只想发布功能 feature/02 到生产换件的话，我该怎么做？

现在 Develop 分支上已经合并入了 feature/01 和 feature/02，如果按照 gitflow 的做法，把 Develop 分支合并入 Release 分支的话， 那么 feautre/01 的变更也会同时被合并

当然，一个解决办法就是不按照 gitflow 的做法，不把 Develop 分支合并入 Release 分支，而是直接把 feature/02 分支合并到 Release 分支上。但是这么做的话，只有两个 feature 分支还好，如果同时开发的 feature 分支非常多的话，每次发布功能都是直接 feature 分支合并入 Release 分支，那么 Development 分支的还有什么意义，以及这么做同时还能预见到，Develop 分支和 Release 区别会越来越大。

这个问题相信大家开发时一定都有遇到过，不知道大家是怎么解决这个问题的？

大佬有話說 (19)

  • 資深大佬 : tt67wq

    1. 有新功能需要开发的话，就在 Develop 上新建 feature/xxx 分支进行开发
    2. 新功能开发完成后 feature 合并入 Develop 分支，测试环境测试
    3. 然后 feature 合并入 Release 分支， 预发测试
    4. 最后确认无误后 Release 合并入 Master 分支正式发布到生产环境

    难道不是这个流程，怎么会有把测试分支合并进 release 的哟

  • 資深大佬 : wellsc

    我们是能用 rebase 合并就尽量不用 merge 合并，能 fork 仓库开发功能，就尽量不会开 feature 分支。子仓库开发完成之后触发 ci 通过之后再 pr 到 主仓库版本分支，版本分支合并之后进 develop 测试，develop 测试完成之后进 prerelease， 再之后进 master

  • 資深大佬 : ispinfx

    不发布为啥急着合并到 dev ？

  • 資深大佬 : mcfog

    – 确定要发的再合并
    – 如果就是确定不确定发不发，但就是要测 /合并，那么就在 feature 分支开发的时候就带上 feature switch，测试的时候同时测 feature on/off 的情况
    – feature 相关 bugfix 不进 dev 而是进各自 feature 再重新合并
    – 需要加急单独发布某个 feature 时从 prod 拉 release-urgent 合入 feature 后测试发布，然后再把 release-urgent 并入 release 后移除
    – 即使要测也不合并 dev，而是每次由 ci 过程来 merge （不推送 vcs ）

    大概就是以上几种措施的排列组合

  • 資深大佬 : wangyzj

    你说的情况貌似叫 hotfix 了吧

  • 資深大佬 : gouflv

    你可能需要一个迭代分支，feature 合并到 dev 测试完后，再将 feature 合并到迭代分支，迭代整个完成的时候，将迭代分支合并到 master。

  • 資深大佬 : xcstream

    加个开关，代码和用不用这个功能分开

  • 資深大佬 : xxapp

    cherry pick

  • 主 資深大佬 : hakono

    @tt67wq 因为说的是 gitflow 啊，所有讲解 git flow 的都是 Dev -> Release -> master 的合并流程，feature 生于 Dev 最终也是合并回 Dev

  • 資深大佬 : avenger

    我们一开始用 gitflow，现在换成 github flow 了

  • 資深大佬 : dbskcnc

    feature flags 了解下

    https://medium.com/@tmaslen/getting-started-with-feature-flags-fc3e617260fe

    gitlab 用得很多,各种新功能都先放在 flags 中，https://docs.gitlab.com/ee/development/feature_flags/

  • 資深大佬 : KuroNekoFan

    还是 github flow 好

  • 資深大佬 : rioshikelong121

    测试完成以后，从 feature 分支直接合并到 release ？

  • 資深大佬 : MinonHeart

    觉得这是版本规划的问题。我们是 feature 完成后不会进入 develop，只有确定要测试并上线才会进入 develop。

    gitflow 流程是一说的那种。不过我们为了配合 ci，分支合并后就删除，我们用的和主的方式相似，属于 gitflow 的变种。

    另外，你不上线的 feature 测试后，待要上线时不需要重新测吗（比如合并有冲突的情况）？浪费测试资源

  • 資深大佬 : MinonHeart

    按照我们的方式，master 和线上同步，develop 最多到下个版本的内容，下下个版本的 feature 都是处于 pending 状态

  • 資深大佬 : hantsy

    Git Flow 应该还要包括 hotfix, 适合多个版本维护开发。

    一般项目用 Github Flow 简单些。

  • 主 資深大佬 : hakono

    @ispinfx
    @mcfog
    感谢回复，虽说之后我也觉得解决这个问题的一个最简单方法就是不发布的 feature 就不合并到 Dev
    但也架不住总有几个 feature 是客户要求先开发出来放到 Dev 环境上，给他们先用着，然后根据情况选择再决定先后发布到生产环境里

  • 資深大佬 : angel001ma

    dev 是测试环境，feature/xxx 上线合到 release
    有新功能需要开发的话，就在 master 上新建 feature/xxx 分支进行开发

  • 資深大佬 : kassadin

    git flow/github flow 之类的主要是对外线性单版本的情况，发布的也都是最近何如 feature

    你的问题是 release 时才确定 feature，所以这个模型不适用很正常，不用生搬硬套

    细节操作还按这个来，把 feature 当 dev 用就可以了，release 时选 feature，发布后合回 dev， 其他 feature merge dev 即可。