你说的书里提到的概念，可能跟 git flow 里的概念并不完全相同。一个 branch 如果长期没有 merge/rebase，理所当然的会有大量的 conflicts，不管代码上的还是逻辑上的。
个人认为，branching model 也是项目管理的一种，总体上来说是经验总结。所以，很难有一种放到任何情况都适用的方法。或者说，某个模型在某个机构里用起来没问题，换个地方应用，可能一个非常不起眼的差别，就导致用起来很不顺畅。
我们的 model 槽点太多，老板希望做成 saas，但一直以来是按照版本号（v1.2.3.0）来的。我们号称是 agile，每个 sprint 选几个比较重要的东西进来，以前想做成大概1个月的工作量，就升一个版本（1.2.4.0）。然后就是常规的需求描述不清，或者改需求，总之就是可能搞到3个月都没法完成（1.2.3.3）。结果就是不同客户运行的版本不一样，有的可能还在跑一年前的版本。如果发现一个新 bug，大概需要经过15个版本号才能到 develop。项目用了 sub-module，直接用的 hash 而不是 tag 或版本号。8月份还迁移了 bitbucket 的服务器（之前是自己的服务器），如果问题出在 sub-module 里，不花点儿时间都找不到应该基于哪个 commit 修。修完之后，按道理就又得挨个小版本改 sub-module 的 hash，反正我是不知道现在是咋搞的……
迁 git 也是一堆破事儿，反正就他一个人有 write 的权限，结果丢了一堆 commits。等过了一个星期 QA 问我问题，我才注意到丢代码了。然后花了大半天时间，我才终于确定丢了哪几个 PR。而且隔太久才发现，都出 conflicts 了。可能都懒得 git fetch --all 一下，就直接 push 本地的上去了，tags 也全都没了。很自然的也没 git fetch --prune，非说 sub-modules 没问题，是你们的问题。有次早会太多人抱怨，他终于 prune 了，然后回头默默修了大半天。小20个版本号，平均4个 sub-modules，每个小版本平均变2个，一直到上个月才修干净。
顺便说一下，这些 sub-modules 起到的作用相当于 ruby gem，也就是一个相对独立的包，对应着 node package 的概念，跟 dll 的作用类似。之所以做成 sub-module，而不是打包发布，也是有一堆历史原因的。最重要的两条，一个是之前的私有 bitbucket server 在公司内网里，需要走 vpn/gateway，sub-module 的话比较容易 deploy；另外一个是每次都得打包，开发和更新的体验太差。反正第一个问题已经不存在了，第二个问题我个人认为，相比之下个人的开发体验相对次要。我们的这种版本号（m）+ sub-module（n）的模型，把问题的复杂度放大成 m*n 了。
我们目前也想尝试其它的 branching model，但还是老话，人的因素。反正我已经努力了，也可能不是母语表达没那么清楚，感觉很多点人家还是没理解。
【 在 xunery (寻) 的大作中提到: 】
: 《持续交付：发布可靠软件的系统方法》这本书里是不提倡feature branch这种方式的，比方说要不要而对这个分支配置CI/CD，如果长时间不能合并到主干，合并的时候还有很多问题。还有很多其他理由
: 实际操作中，我们是小地迭代都在主干做（哪怕有新feature），非常大的版本升级，会新拉一个主干，以后都基于新主干，CI/CD和QA的工作主要基于主干来做，感觉效果还是可以的
: 我们主要是desktop应用程序，不是web程序，也许不同类型可能有区别
: ...................
--
FROM 203.211.111.*