多个版本的 Git 分支策略答案

【问题标题】：Git branching strategy for multiple releases多个版本的 Git 分支策略
【发布时间】：2017-11-02 20:05:37
【问题描述】：

我的团队是 GIT 新手（使用 GitLab），我们正在尝试解决以下问题。

我有项目 A，它有 3 个团队在工作。

团队 1 有一个 1 月版本

Team 2 发布了 3 月版本

Team 3 7 月发布

我们有 Master for Production Code 的想法。我们正在努力解决的问题是什么是强制执行团队 2 拥有团队 1 的所有更改并且团队 3 拥有团队 1 和 2 的所有更改的最佳方式。

我们有 DevJan、DevMarch、DevJuly 分支。但似乎没有什么好的方法可以让更改正确地向上游流动。

我们只是定期变基吗？如果您是团队 1，请提交所有 3 个分支？我在所有 GIT 讨论中都没有发现类似的场景。

【问题讨论】：

标签： git gitlab branching-and-merging

【解决方案1】：

因为有问题的分支专门用于协作目的，所以我不会将它们重新设置为工作流程的一部分。您可以定期将 DevJan 合并到 DevMarch 中，然后将 DevMarch 合并到 DevJuly 中。

该工作流程的缺点... 团队 2 和 3 将吸收团队 1 在周期性块中的更改，这可能会加剧合并问题 - 但这是决定同时拥有三个长期存在的开发分支所固有的。缓解这种情况的最佳方法是使“定期”合并非常频繁 - 可能每天 - 这意味着您将获得大量合并提交，将“早期版本”更改带入“后期版本”分支。虽然有些人不喜欢“额外的”合并提交，但如果您使用功能分支（我建议您应该这样做），那么无论如何，开发分支将不过是一系列合并提交。

【讨论】：

我的团队使用的另一种方法是针对受问题影响的版本提交多个 PR。无论哪种方式都很痛苦。

【解决方案2】：

嗯。您可以将它们放入 1 个存储库中。

您可以 git checkout -b Release/July ，提交您当前 7 月项目的所有源代码，然后从那里 git checkout -b Release/March，从 3 月再次提交，然后 git checkout -b Release/Jan，提交。所以你会有一个像

这样的结构

----------- Release/July   Team 3
    \------- Release/March   Team 2 
     \-------- Release/Jan     Team 1

现在他们每个人都可以有自己的合并策略到他们自己的发布分支，并且您可以向上合并分支，请注意，在合并时可能会出现很好的冲突，您需要从下面的分支“链接”所有内容。

rebase 或cherry-pick 如果您在分支之间有无法合并的部分（例如数据库方案），并且必须严格合并必须合并的部分，则可能会更好。但恕我直言，无论哪种方式，维护多个版本都很棘手。

【讨论】：