git cherry-pick 可以追溯到多远？

Question

假设我做了以下事情：

1. 从 master 创建分支 My-new-feature
2. My-new-feature 代码更改第 1 部分
3. 从本地（最近拉出的）master 合并
4. My-new-feature 代码更改第 2 部分
5. 从 master 创建分支 release-2
6. 从本地（最近拉出的）master 合并
7. 提交并推送我的新功能

如果我现在想将步骤 2 和 4 中的更改挑选到 release-2 分支，我需要使用哪些步骤提交编号？

a) 从第 7 步开始（因为 cherry-pick 足够聪明，可以从 master 一路回到分支），或者

b) 从第 2 步和第 4 步开始（以避免将最近的更改引入主节点），或

c) 别的东西？

Answer 1

如果你和朋友去摘樱桃，请指着一棵树说“请为我摘那个樱桃”。您的朋友可能会回答“那个樱桃？你指的是哪个樱桃？” Git 做同样的事情。 cherry-pick command 需要您指定的单个提交或一系列提交。

git cherry-pick a1b2c3d4 # single commit

# or

git cherry-pick a1b2c3d4..b2c3d4e5 # range of commits

与 Git 中的大多数命令一样，您可以用标签或分支名称代替提交 ID，因为两者都只是指向提交的指针。

重要提示：当您使用范围时，列出的第一个提交是要选择的第一个提交的父提交，并且不会选择该父提交。

鉴于此信息，如果您在第 7 步之后显示提交图表，则应该相当直接地确定您需要挑选哪些提交或哪些提交来实现您的目标。

Answer 2

如果我现在想将步骤 2 和 4 中的更改挑选到 release-2 分支，我需要使用哪些步骤提交编号？

git cherry-pick 只选择你告诉它的提交。你可以给它一个提交列表，也可以给它一个提交范围。

Git has two primary ways of specifying a range, A..B and A...B.

A..B 表示要为您提供从 B 可访问但从 A 无法访问的所有提交。因此，如果您希望分支中的所有提交，而不是从 master 合并的提交，您将使用 master..my-new-feature .

A...B 是“对称差”。提交可以从 A 或 B 访问，但不能从两者访问。如果您想从两个分支而不是它们的共同祖先获取提交，这很有用。

例如，在几次合并更新后，您的存储库将如下所示。

A - B - C - D - E - F  - G - H - I - J - K [master]
         \           \            \
          1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9 [my-new-feature]

可从 my-new-feature 访问的提交是...

A - B - C - D - E - F  - G - H - I
         \           \            \
          1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9

并且可以从 master 访问的提交是......

A - B - C - D - E - F  - G - H - I - J - K

master..my-new-feature 是可从 my-new-feature 访问的提交减去可从 master 访问的提交。

1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9

master...my-new-feature 是可从 my-new-feature 或 master 访问的提交，但不能同时访问。

J - K

1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9

所以git cherry-pick master..my-new-feature 应该做你想做的事。 git log 采用相同的修订集，因此您可以通过 git log master..my-new-feature 进行检查。

---

请注意，如果您在更新分支时使用rebase 而不是merge，则可以避免大部分情况。 git rebase master。而不是将 master 的更改合并到您的分支中，这会将您的提交复制到新的 master 之上。结果是更简单的历史记录。

如果您重新定位而不是合并，您的历史记录将如下所示。

A - B - C - D - E - F  - G - H - I - J - K [master]
                                  \
                                   1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9 [my-new-feature]

如果你再次变基，它会是这个样子。

A - B - C - D - E - F  - G - H - I - J - K [master]
                                          \
                                           1 - 2 - 3 - M4 - 5 - 6 - M7 - 8 - 9 [my-new-feature]

就好像你一直在最新版本的 master 之上编写 my-new-feature 一样。

您的分支上的git rebase master 包含所有合并将删除合并，您最终会从上面获得更简单的历史记录。 但是 rebase introduces some complications of its own 所以不要在没有人指导的情况下尝试。