git cherry-pick 不工作答案

【问题标题】：git cherry-pick not workinggit cherry-pick 不工作
【发布时间】：2011-10-27 16:07:54
【问题描述】：

我正在尝试从 master 中挑选一个提交并将其放入当前的生产分支。但是，当我执行git cherry-pick <SHA-hash> 时，我只会收到以下消息：

# On branch prod_20110801
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   site/test-result/
 nothing added to commit but untracked files present (use "git add" to track)
 The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

注意：我尝试过重置和重置 --hard HEAD^，但似乎都没有改变任何东西。

我很困惑为什么这对我不起作用。

任何有关如何解决此问题的见解、建议或想法都会有所帮助~！

【问题讨论】：

当我不小心尝试挑选错误的提交时，这发生在我身上。使用 gitk 时有时会发生。

标签： git branching-and-merging cherry-pick

【解决方案1】：

Git 正在将cherry-pick 解析为无操作——该提交引入的所有更改都是由您当前分支上的某个提交引入的。（或者这就是 Git 的想法，无论如何。）验证您正在挑选的提交尚未以某种方式合并，作为适当的合并、rebase/cherry-pick 或零碎补丁。（使用git show <commit-id> 查看差异。）

【讨论】：

感谢您的建议，事实证明樱桃采摘已经发生，我所要做的就是将其推送到 github。
对，我没有意识到它正在检查给定提交 ID 的文件的内容。我去日志中寻找提交ID，但找不到。原来它已经被合并了。
不幸的是，这不是问题的唯一原因。当我提交时，我遇到了完全相同的情况，它恢复了一些先前的提交，当我在另一个分支上挑选它时，历史没有恢复更改（即没有挑选恢复的提交)。当然，这是我的错。但在这种情况下，预计 git 应该以冲突状态失败，而不是尝试过于聪明，这会导致用户感到困惑。
如果您恢复合并提交并且要挑选的提交位于恢复的分支上，则可能会发生这种情况。
@HamDiou 当时我决定我已经失去了足够的时间并手动完成。签出提交，然后使用补丁、kdiff、winmerge 或任何你喜欢的方式移动必要的更改。

【解决方案2】：

在我的情况下，这让我发疯了，因为很明显我想要挑选的特定提交没有被合并到我当前的分支中。

原来有人在一周前已经樱桃选择了提交。变化，但不是特定的 SHA，已经在我当前的分支中，我没有注意到它们。

检查您尝试挑选的文件。如果他们已经进行了更改，则提交的版本已经被精心挑选或以另一种方式添加。因此没有必要再次挑选它。

【讨论】：

我很确定特定的提交在你的分支中是 never 当它被一个樱桃选择引入时，因为樱桃选择将是一个新的哈希，对吧?还是我误会了？
@msouth 我最初从其他答案中得到的是“提交已经合并”，但我可以看到它在我的分支中 not 。不过，您说的樱桃选择始终是新的 SHA 是对的。
是的，当我输入它时，我在想“由哈希标识的特定提交”。我的语言不准确。我经常回顾git log --graph --pretty --decorate --oneline 的输出，以查看给定的 SHA 是否在我的分支中。请参阅下面的我的回答，关于如何基于认为提交消息指示更改而混淆 - 有一种情况并非如此，这就是我最初提出这个问题的原因。人的大脑往往会走捷径，它们偶尔会回来咬你。

【解决方案3】：

另请注意，向树中添加空文件（例如 .gitkeep）被cherry-pick 视为空提交。

【讨论】：

【解决方案4】：

所以，这可能是另一个令人困惑的情况：我有以下情况：

我试图挑选 9a7b12e 这显然没什么——它甚至试图在 git log 输出的那一行告诉我 4497428 是我真正想要的。（我所做的只是寻找提交消息并抓住我看到的第一个哈希）。无论如何，只是想让人们知道，还有另一种方法可以欺骗您尝试挑选无操作。

【讨论】：

在没有解释的情况下对您投反对票并不是很有帮助——这是我遇到的问题的确切再现，导致我在搜索中找到了这个问题。如果您有改进的建议，请在 cmets 中告诉我，而不是仅仅投反对票。

【解决方案5】：

我和你有同样的问题，也许这会对你有所帮助，所以请确保你没有脱离 HEAD 然后尝试挑选它们，这意味着首先要做：

git checkout master

然后使用：

git cherry-pick <your-commit-hash>

【讨论】：

【解决方案6】：

发生此错误的另一个可能原因是传递给 git cherry-pick 的提交序列。您必须选择第一个提交作为开始提交，然后及时前进。

我有同样的问题，在我的情况下，提交历史如下，

   Commit Sequence   976e364---2b162b6---x...etc

我跑到下面，它产生了与问题相同的错误/问题，

git cherry-pick 2b162b6 976e364   //this is wrong commit sequence

上述案例的根本问题是提交顺序。

git cherry-pick 976e364 2b162b6   //this is correct commit sequence

在 git 官方文档中它声明为

注意：提交序列确实很重要。

# Find the range of commits you wish to re-add to your branch.
# then use cherry-pick to add them back to the branch
git cherry-pick start..end

# If you wish to include the start commit as well add the ^
# This will result in a cherry-pick of the start commit included as well 
git cherry-pick start^..end

【讨论】：

【解决方案7】：

我对这个主题有不同的变化，但我从未找到正确的解决方案。

git checkout master
git rm .travis.yml
git commit -m "Travis build no longer needed"
git checkout <mybranch>
git cherry-pick <lastcommit>

这因空提交错误而失败。我验证了分支上仍然存在相同的文件。在这种情况下，我只是重做了分支上的提交，但这很令人沮丧。

centos8 上的 git 2.27.0

【讨论】：