所以我们有一个项目，其中同时处理多个“主要”分支。所以有 1.0.0、2.0.0 和 3.0.0。进入 2.0.0 的东西不能进入 1.0.0，等等。每个分支都向前合并，1.0.0 > 2.0.0 > 3.0.0。
我不认为我们可以使用正常的流，因为如果我们设置发布分支，你不能从它们中获取特性分支，而且这些还不是“发布”，它们仍在积极开发中。如果我们往下走，那么一切都必须通过一个主分支才能到达发布，并且没有办法隔离文件。
所以我想我的问题是，有没有合适的方法来为这样的东西设置流？
谢谢
问问题
37 次
1 回答
1
许多关于使用主线模型的假设来自于一个版本被相对不频繁地削减（一年两次）并且只针对关键错误进行修补的环境——因此需要从一个版本到另一个版本的更改往往是例外而不是规则。在这个模型中，绝大多数合并只是来自最新版本（例如，当版本稳定时，它发生在周期中的某个点，在此之前的版本中几乎没有活动）或来自开发分支回到主线，然后从主线回到 dev 分支（因为 dev 分支主要致力于开发针对主线但不是任何发布分支的新功能）。更改仅从主线转到发布分支，如果他们' re 被手动挑选来解决一个严重的错误（这很少见），而不是直接从开发分支到发布分支。从一个旧的发布分支到一堆后来的发布分支中挑选一个修复程序有点尴尬，但在这个模型中很少见，所以尴尬并不重要。
如果您非常积极地同时处理多个版本，则主线模型的价值较小，因为您需要：
- 在兄弟/表兄弟分支之间合并（这通常可以正常工作，但如果有很多重构可能会变得尴尬）
- 仔细挑选进出主线的更改，以强制执行正确的更改流程（这使得合并更清晰，但需要更多手动跟踪）
这里的正统建议可能是重新考虑您的发布方法/政策，以不需要太多“瀑布”，但我假设您有商业原因要求它以这种方式工作。鉴于这种限制，我认为您可能根本不想使用不同流“类型”和“流”的概念，因为它们对内置的主线模型有假设，而您所做的基本上不是主线发展模式。
要在流中实现非主线模型（如果没有流管理指南，它仍然有一些价值，因为它可以帮助您管理客户端视图等），您可能需要使用以下组合：
- 使初始主线之后的每个流都成为
development流（我认为这是最宽容的） - 在每个流中设置
mergeany选项（允许在所有方向上合并，而不是试图强制执行作为主线模型概念的“坚定性”） - 合并时使用该
-F选项以忽略流向（mergeany如果您始终使用它，我认为这是不必要的）
于 2020-12-05T18:40:33.003 回答