‘.PICK/CHERRY_PICK_HEAD`’在犯罪时有什么区别？

Question

NB:，这是我以前的一篇文章(现在被删除)的重新措辞。重新措辞的目的是使该员额具有不同的侧重点。

在运行git cherry-pick时，git报告说发生了冲突。我解决了冲突，然后运行了git cherry-pick --continue。此时，$GIT_EDITOR弹出了一个预先填充了樱桃选择提交的原始消息的COMMIT_EDITMSG缓冲区，并提供了一些附加信息，其中包括警告：

# It looks like you may be committing a cherry-pick.
# If this is not correct, please remove the file
#   .git/CHERRY_PICK_HEAD
# and try again.

我检查了如果我“删除”(实际上只是暂时重命名) .git/CHERRY_PICK_HEAD文件发生了什么。这样做的直接外部效果是从我的git-aware提示符中移除git指示。

除了我的提示符中的这一更改，以及COMMIT_EDITMSG缓冲区中预先填充的信息中可能存在的一些差异之外，在.git/CHERRY_PICK_HEAD文件是否到位的情况下执行提交会有什么不同呢？

更准确地说，我在这里尝试比较两种情况。

在第一个场景中，我运行

% git cherry-pick --continue

...and (无视前面引用的警告)我将一如既往地进行提交。

在第二个场景中，我运行

% rm .git/CHERRY_PICK_HEAD
% git commit

...and像往常一样继续提交。

(假设我在两种场景中都使用相同的提交消息。)

这两种情况的最终结果有何不同？

Answer 1

答案取决于你在做什么。使用--continue可以完成这个序列--但是如果这个序列只是一个樱桃-选择，那么就没有真正的序列了。

然而，不管是哪种方式，删除.git/CHERRY_PICK_HEAD肯定还有一个额外的显著效果:完成一个冲突的樱桃精选，重新使用原始提交的作者姓名、电子邮件和日期信息。您始终是任何新提交的提交者，但所有提交都不只是一个人和时间戳:每个新提交都有两个条目，一个用于“提交者”(您刚刚提交)，另一个用于“作者”(编写原始提交的人，每当他们这样做时)。樱桃-选择保存原始提交的作者信息。

排序器

git cherry-pick和git revert-which实际上在内部都是相同的命令；revert只是“向后工作”，Git称之为排序器。也就是说，您可以同时选择多个提交：

git cherry-pick notthis..that thistoo

要选择所有提交“在”notthis之后，通过并包括that，以及特定的提交thistoo。例如，您可能决定在feature/X上选择从develop中生成的每个提交，再加上一个bug修复提交fix-1234，用于测试目的：

git checkout master
git checkout -b testbranch
git cherry-pick develop..feature/X fix-1234

无论如何，这里的要点是，这可能会选择十几个或更多的提交，并且在此过程中的某个地方可能会出现合并冲突，这需要git cherry-pick停止并获得帮助。

旁白:这里的模型- Unix/Linux命令行-是将一个命令输入到一个名为shell的命令解释器中。shell将对人工接口的控制传递给新命令，新命令保留它，直到命令完成并退出。一旦命令退出，就没有命令本身的痕迹了:任何永久的东西都必须保存在文件中。

所以:如果樱桃必须停止，它怎么知道在哪里恢复呢？答案是将信息保存在文件中。如果您选择一个提交，则Git只保存CHERRY_PICK_HEAD文件，该文件记录被选中提交的ID。但是，如果您选择多个提交，则Git保存冲突的提交与单个提交一样，并将剩余的信息保存在排序目录中(其位置随着时间的推移移动了一些)。

运行git cherry-pick --continue将引导(新的、单独的) cherry命令从上一个中断的位置拾取。Git将首先为您运行一个git commit，然后定位测序信息并尽可能多地完成序列，在下一次冲突时再次停止，或者完成所有的樱桃挑选。

运行git commit时，Git会注意到CHERRY_PICK_HEAD文件并使用它，正如您所看到的。当提交完成时，该命令退出，不对排序器执行任何操作。如果遗留了排序器数据，现在可以使用git cherry-pick --continue：Git注意到提交已经完成，只需继续/完成排序器操作。

请注意，您可以使用git cherry-pick --abort，而不是完成操作。这将终止操作，并使事情恢复到您开始之前的状态。从Git 2.19开始，您可以使用git cherry-pick --quit来停止(a la --abort)，但不能将事情恢复到开始之前的状态。也就是说，它会停止任何未来的采摘操作，而不会取消到目前为止所做的工作。(这项行动在2.19之前就失踪了。)

git status命令现在注意到是否有正在进行的序列，并报告您正在进行的任何操作。(与Git 1.7时代相比，这是一个很大的进步，当时它没有这样做。)