Git 将错误修复反向移植到旧分支的策略(cherry-pick vs. merge)

Question

我们团队的工作方式如下:

• 我们的 GitHub 存储库中只有一个 master 分支，它不稳定 - 每天都会被推送到那里；对于稳定版本，我们使用标签(为了开发，我们在 GitHub 上使用私有(private)分支)
• 我们每 3 周发布一个新的次要版本，其中包含错误修复和新功能(例如 1.2.4、1.2.5、1.2.6...)
• 我们还必须在有限的时间(几个月)内维护每个次要的旧版本，因此当有人使用 1.2.4 而最新版本是 1.2.7 时，他们发现了一个错误，他们可以要求我们修复他们使用的分支上的错误。然后我们发布一个补丁版本，1.2.4A。
• 补丁非常特别。我们通常为次要版本做不超过 1-2 个补丁。对于大多数版本，我们不打补丁。

问题是，同时修复 master 和旧分支上的 bug 的最佳策略是什么？

我可以想到两个主要策略:

1. 修复 master 上的错误，然后 checkout v1.2.4，然后 cherry-pick 适当的提交(假设错误修复是一个始终持有的提交)并将生成的提交标记为 v1.2.4A。

2. checkout v1.2.4，修复错误并提交，将提交标记为 v1.2.4A，并将其 merge 到 master，执行 merge 。

我更倾向于第一个版本(cherry-picking)，但我想听听其他人对优缺点的评论。

当然，当中间的提交引入一些重大更改时，事情会变得复杂，这些更改可能导致无法创建在 1.2.4 和 master 中都有效的提交 (例如，当某些函数名称更改或更复杂的事情时)。但更常见的情况是可以毫无问题地移植修复程序。

从大师那里 cherry-pick 的优势:

• 我认为 cherry-pick 后的历史更“可食用”。考虑一下:

  | <- bugfix done on master
  |
  |
  | <- v1.2.7
  ...
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |  - <- v.1.2.4A (cherry-picked from master)
  | / 
  | <- v1.2.4
  

  对比这个:

  | <- bugfix merged to master
  |\ 
  | \
  |  |
  |  |   <- v1.2.7
  ...
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  - <- v.1.2.4A (direct bugfix)
  | / 
  | <- v1.2.4
  

  想想中间有几十次提交。考虑像这样并行应用多个补丁。一半的屏幕会被污染。

• 假设我在 v1.2.4 上修复了一个问题，但几天后有人要求我提供 v1.2.3 上的补丁。 Cherry-pick 是最明智的做法。

在我们的案例中，是否有任何我忽略的 merge 优势？我可以理解它比 cherry-picking 更好地保留了两个提交之间的联系，但我们保留了一份发布文档，所有这些也都在那里进行了跟踪。

Answer 1

在我参与的开源项目中，共识似乎是修复应该首先登陆 master，在那里进行测试，然后才向后移植到旧版本。您可以在 Linux 内核如何执行稳定版本中看到这一点，例如:开发人员为主线提交补丁，但也提名它们包含在稳定版本中。

在这种情况下进行挑选时，您可能希望使用 -x 标志:

When recording the commit, append a line that says "(cherry picked from commit ...)" to the original commit message in order to indicate which commit this change was cherry-picked from. This is done only for cherry picks without conflicts. ... [If] you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.