具有两个发布目标的 Git 分支实践

Question

我有一个关于 git 分支实践的简单问题：

假设有 master 和 develop 分支。所有功能开发任务都在相应的功能分支上工作，针对develop 分支。 （功能分支从develop分支出来）

我有发布 1.0.0 版应用的任务，同时，我还有未来发布 1.1.0 版应用的任务。

我知道一般来说，任务应该针对 develop 分支，但我不想发布包含 1.1.0 功能的 1.0.0 ，所以我不能让所有任务合并到 develop分支。

我能想出的解决方案是为 1.1.0 创建一个 temporary 分支（从 develop 分支），将 1.1.0 的任务合并到该 temporary 分支。等到创建 1.0.0 的候选发布分支，然后将该 temporary 分支合并到 develop 以用于未来的 1.1.0 版本。

你有比我想出的更好的做法吗？

Answer 1

我知道一般来说，任务应该针对开发分支，

这主要适用于流行的git-flow 工作流程。没有“应该”之分，git 本身对你如何使用它也没有意见。

git-flow 适用于您只有一个“下一个”版本，如果您非常了解下一个版本的内容，并且您通常不希望从您的 develop 分支中退出更改。例如，在我目前的主要项目中，这三个假设是错误的。所以我们不使用git-flow。

我能想出的解决方案是有一个临时分支（从开发分支）

首先为什么要从develop 分支出来？您可以改用master（意思是“当前版本”）。如果您的所有分支都来自master，并且您摆脱了develop，并且您拥有经常从头开始重新构建的临时未来发布分支（重置为主，将所有相关功能合并到其中）以多个未来版本为目标，同时仍并行开发所有新功能是没有问题的。有一个名为 branch-per-feature 的工作流程非常适合此工作。

Answer 2

这个问题的答案会因工作流程而异（并且会因团队偏好和项目性质而异），所以这个问题可能是基于意见或过于宽泛......但我想一些普遍的想法是：

最简单的方法是尽量减少为多个版本开发功能的重叠时间。从优先和努力的角度来看，这通常是有道理的。

例如，流行的 gitflow 工作流程或多或少假设打开的 feature 分支都（至少可能）用于即将发布的版本。关闭版本 x 的功能集后，您将创建版本 x 发布分支。只有与发布相关的工作和小错误修复应该发生在发布分支上（最终合并回develop，这样这些修复就不会丢失）。当特性 x 发布分支被创建时，任何开放的特性都会变成“版本 x+1 特性”，并且你打开任何你已经为 x+1 版本保留的新特性。

（相关的一点：在什么功能发布到什么版本时保持灵活通常很有用，这样您就可以在时机成熟时发布任何已准备好的价值。这与敏捷思维有点相关。）

但是，如果您发现积极开发两个版本是您的项目的出路，那么您需要做一些不同的事情。我会完全摆脱 develop 分支的想法，因为会随之而来的分支名称杂乱无章。

然后发布开发分支（例如dev-1.0.0）可以替换develop。您将从先前的发布开发分支创建发布开发分支，但此后您必须定期将先前发布开发分支的更改合并到当前发布开发分支中。由于这是一个共享/长期存在的分支，您不会希望通过 rebase 执行此操作，这意味着您可能需要定期合并提交。

还有其他方法，就像我说的那样，一旦您摆脱了经过记录和时间考验的方法，它就会迅速进入舆论领域。