git cherry-pick不起作用

Jay*_*lor 98 git cherry-pick branching-and-merging

我正在尝试从主人那里挑选一个提交并将其放入当前的生产分支.但是,当我执行时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'
Run Code Online (Sandbox Code Playgroud)

注意:我尝试过重置和重置 - 硬HEAD ^,似乎都没有改变任何东西.

我很困惑为什么这不适合我.

任何关于如何解决这个问题的见解,建议或想法都会有所帮助〜!

cdh*_*wie 129

Git正在解决这个问题,因为这个提交所引入的所有更改都是由当前分支上的一些提交引入的.(或者那就是Git认为的那样.)验证你所采摘的提交尚未以某种方式合并,无论是合适的合并,rebase/cherry-pick还是零碎的补丁.(git show <commit-id>用于查看差异.)

  • 感谢您的建议,事实证明已经发生了樱桃选择,我需要做的就是将其推送到github. (16认同)
  • 不幸的是,这并不是问题的唯一原因。当我提交时,我遇到了完全相同的情况,这会恢复一些早期的提交,当我在另一个分支上挑选它时,历史记录中的更改没有被恢复(即没有选择该恢复的提交) )。当然,那是我的错。但在这种情况下,预计 git 应该因冲突状态而失败,而不是尝试太聪明,这会导致用户感到困惑。 (2认同)
  • 如果您恢复合并提交并且要挑选的提交位于恢复的分支上,则可能会发生这种情况。 (2认同)

pka*_*amb 9

在我的情况下,这让我疯了,因为很明显我想要挑选的具体提交没有合并到我当前的分支中.

事实证明,有人已经在一周之前选择了提交.的变化,而不是特定的SHA,已经在我目前的分支,我没有注意到它们.

检查您尝试挑选的文件.如果他们已经有了更改,那么已经以另一种方式挑选或添加了提交的版本.因此没有必要再次挑选它.


Nea*_*mar 5

另外请注意,将一个空文件(例如.gitkeep)添加到树被Cherry-pick视为一个空提交。


mso*_*uth 5

所以,这是可能出现这种情况的另一个令人困惑的情况:我有以下情况:

git 日志截图

我试图挑选 9a7b12e ,这显然没什么——它甚至试图在 git 日志输出的那一行上告诉我 4497428 是我真正想要的。(我所做的只是查找提交消息并获取我看到的第一个包含它的哈希值)。不管怎样,只是想让人们知道,还有另一种方法可以让你被欺骗,试图选择一个不可行的操作。

  • 对于您在没有解释的情况下否决投票的帮助不大——这是我遇到的问题的精确再现,导致我在搜索中找到了这个问题。如果您有改进的建议,请在评论中告诉我,而不仅仅是否决。 (14认同)