如何在不使用 gitcherry-pick 的情况下解决此补丁发布问题？

Question

我读过@raymond-chen的停止择优挑选系列，但如果不使用择优挑选就能解决以下问题，我就无法理解：

时间线如下：

• 我们从 Master 分支分支出来，准备在 M1 点发布我们软件的 v1.0.0 版本
• 我们并行开发两个功能：F1 和 F2 在不同的功能分支上。 F2 进入发布版本，同时我们推迟 F1 并合并到 master。
• 在 v1.0.0 发布并随后将 F2 合并回 master 后，我们开发了一个功能 F3 并将其合并回 M4 的 master
• T1 管理层决定我们需要在基于

  v1.0.1

  的补丁版本

  v1.0.0

  中尽快将功能 F3 交付到生产环境。 功能 F1 不得包含在该版本中

如何在不进行挑选的情况下实现这一目标？

回想起来，功能 F3 应该是从 F2 分支出来的，但现在已经太晚了。我们不想重写 master 分支上的 git 提交历史记录。

Answer 1

我个人对雷蒙德文章背后动机的总结可能是这样的：

为了避免在长期共享分支中重复提交，尽可能选择合并而不是挑选。

择优挑选本质上没有什么“错误”，但是当您在长期存在的共享分支中执行此操作时，您会创建提交的重复副本，这在查看历史记录时可能会导致（少量）混乱。至少，如果择优挑选会导致长期分支中出现重复提交，我建议使用 -x 选项，以便在查看历史记录时，其中一个提交将显示预告片，说明该提交是cherry-摘了。请注意，当从未合并的功能分支中挑选提交时，这是不必要的。 根据您的具体情况，我可以想到实现您目标的 3 个选项：

在

F1
1. 上恢复

   master

   。由于某种原因，您不希望包含此功能，因此请将其删除。您是否选择此选项可能取决于您的

   master

   分支应该代表什么。如果它代表您要发布的内容，那么这是一个不错的选择。当准备好发布时，您可以随时将

   F1

   添加回来。 （也许通过恢复恢复。）挑选
F3
2. 到您的新版本。有时挑选樱桃是必要的，那没关系。你可以通过合并做一些疯狂的事情，但这太令人困惑了，我不推荐它：

git switch -c release F2
git merge --ours M2 # this will bring in M2 without taking the changes
git merge M4
# now make your hotfix changes

这解决了眼前的问题，但当您将其合并到

master

时，又创建了一个新问题。

旁注：

您说过：

回想起来，功能 F3 应该是从 F2 分支出来的，但现在已经太晚了。

这可能是真的，但如果

master

代表可发布的代码，那么也许如果你可以重新做一遍，你就会推迟将

F1

合并到

master

中。如果这是真的，那么目前恢复

F1

的选项 1 可能是最好的。

提示：

如果您决定恢复 F1，并且

F1

只是功能分支上多个提交的缩写，您可以按每个提交发生的相反顺序恢复，也可以恢复合并提交

M2

。如果有超过 1 个提交，我几乎总是喜欢恢复合并提交，并且在执行此操作时，我仍然使用

-x

选项来将预告片语句自动写入提交消息详细信息中。