问题标签 [cherry-pick]

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

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

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

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

我试图了解如何撤消提交并将更改提交到 Git 中的另一个分支？但我认为不必那么难。（答案正在使用branch -f并且stash我认为我不需要这些。）

我在我的开发分支工作。在脏工作目录中有两个不同的提交。在两个不同的提交中提交所有更改。最后一次提交是 WIP（所以是开发材料）。倒数第二个已完成，应复制到stable分支。

我想像

但我很确定不是这样。

樱桃采摘与它有关吗？

可以肯定的是：我希望提交保持在dev. 所以不是mv它，而是cp它。

我仍然对所有这些 GIT 选项和命令感到困惑。

上下文：我有一个实验分支crazy-idea，我在一个专门的子目录中做了一些疯狂的事情madness/{src,docs}。大量的提交，带有注释、图片、hacky 脚本来创建情节。现在我已经完全理解了我在做什么，是时候src/通过添加新功能和更改现有功能来编辑实际的源文件了。

由于混乱crazy-idea会使 master 的历史变得混乱，good-idea因此创建了一个新分支来将更改合并src/到 master 中。Convince 建议我更改src/仍然存在的文件crazy-idea，然后从内部挑选提交good-idea。

现在我的问题：鉴于good-idea已合并到 master 中，并且在此事件之后在 master 中完成了一些提交。当我回去crazy-idea进一步解决我的想法的其他方面时，src/在 rebase 到 master 时会遇到麻烦吗？

另一种方法是单独留src/在内部crazy-idea，复制子目录并以这种方式查看我的笔记，同时直接在good-idea.

大家有什么建议更聪明的吗？

编辑好吧，正如预期的那样，我在

在crazy-idea. 将来我只会在一个分支中引入更改，并且只有在我知道它或多或少被放弃时才使用樱桃采摘。

编辑我解决了我的情况如下：有 N 次提交，在src/. 可以说最后一个src/不变的提交有消息'foobar'。变基失败后：

完毕。这显然不像我希望的那样直截了当，但也不算太糟糕。我想我会走这条路，而不是抄袭madness/。

我这里有 2 个分支，比如 branch1 和 branch2。branch1 增加了很多新特性，branch2 是稳定的。今天，我只想将分支 1 的 1 个特性合并到分支 2。所以，我只是跑git cherry-pick <commit-for-feature1-in-branch1。我想应该只有更改<commit-for-featur1-in-branch1才会合并到branch2中。但我发现包含其他功能的更多更改。

我认为它只会为指定的提交获得差异，对吧？

仅供参考，branch1 中的提交是从其他开发分支合并的，这可能导致这个问题吗？

我做错了什么吗？

谢谢。

我正在尝试使用 Gerrit 实现“git-flow”类型的工作流，但我似乎无法弄清楚最后一块拼图。

我的问题有两个先决条件：

• Gerrit 只会合并到一个分支
• 我不允许将合并提交推送到 Gerrit。更改获得批准后，合并必须由 Gerrit 完成

我要解决的问题如下。考虑这种 git 情况：

有一个带有一个提交的 master 分支和一个从 master 派生的带有几个附加提交的开发分支。一段时间后，develop 分支合并回 master 以创建下一个生产版本。开发人员使用来自开发的主题分支和严格的变基。在推送之前，他们的提交总是基于最新的上游开发。这应该会导致线性历史记录，并且只会快进提交。

现在假设有人从 master 创建了一个 hotfix 分支并合并回 master：

这个提交现在只合并到主分支，但开发人员需要在他们的开发分支中提交这个提交，以将错误修复合并到他们的更改中。通常你会合并主分支来开发开发分支，但考虑到我的先决条件，这是不可能的，因为它会创建一个本地合并提交。

我的问题是：如何将主分支的新提交合并到本地开发分支中，以便开发人员的任何新更改都包含错误修复？理想情况下，我会修改我的脚本以首先将错误修复更改应用到本地开发分支（合并但没有合并提交），然后重新设置开发人员的提交并推送。这样，错误修复将自动添加到他们的新更改中，并将被视为新提交的一部分，而不是单独的提交。

我一直在考虑可能的解决方案：

• Cherry 选择提交到开发分支。我相信下次开发与 master 合并时，这将始终导致重复提交。有没有办法解决？
• 如此处所述的变基： http ://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ 。自从发布了开发分支后，这可能会导致问题，或者不会？

我希望我的问题很清楚。如果需要进一步澄清，请告诉我。我知道我的工作流程非常严格，但与 Gerrit 结合使用将是理想的选择。如果它不能完成，那么我可能会允许合并提交......

我有一个 python 项目，我决定今天把它放在 github 上。我是新手。我看到几个教程。除了我想做的事情之外，所有工作都很好：

我白天在笔记本电脑上编码，回家后在电脑上继续工作。现在我在笔记本电脑上创建了一个 repo，并将其推送到我的 github 上。当我回到我的电脑上时，我做了一个 repo 的克隆以继续处理代码。但是当我再次将它推送到 github 上时，一切正常，除了我不知道如何再次在我的笔记本电脑上“下载”它以在第二天继续工作。

我发现唯一的事情就是做一个“樱桃采摘”。我不知道它是否正确以及在这种情况下如何处理。

我正在从 Subversion 过渡到 Mercurial，我习惯使用 svnmerge.py 来跟踪已合并或已被阻止合并的更改：

我希望能够为 hg pull/push/merge/graft 做类似的事情，这样如果我知道我永远不想合并给定的更改，我可以阻止它考虑，进行后续的挑选、合并、等等，变成了一个更加一劳永逸的事情。我已经做了很多谷歌搜索，但还没有找到一种方法来做到这一点。

似乎也无法查看尚未移植的更改列表。

由于我经常在其他开发人员之后进行整理并帮助他们进行合并，因此能够做这些事情非常有帮助，人们可能会认为这是“逆向挑选”；即，标记您不想合并的更改，然后对其余部分进行批量合并。

我在 git 中有两个分支，master/ 和 1.7/。我使用cherry-pick将一些修复从master/移植到1.7/。（我没有使用合并，因为我只想要一些更改。）：

稍后，我将 1.7/ 合并回 master/，因为我希望将所有已进入 1.7/ 的更改（除了樱桃挑选本身）合并回主线：

我的问题是，这会将cherry-picks（最初来自 master/）再次提交到 master/ 中：

在我的真实存储库中，它甚至导致了合并冲突。

所以我的问题是，我可以避免这种情况（如果可以，如何避免）？

重现此行为的完整命令列表：

我有另一个组织的存储库的一个分支。我在 repo 中的最新标签，它不是头部，我已经从该标签创建了一个永远不会被推送到上游的分支。这就是为什么我认为分支是私有的。

我已经对我的私人分支做出了承诺，并在我的生产环境中使用了该代码。当对上游存储库进行新标记时，我希望能够提取他们的更改。

但是，我希望始终将我的提交保持在最后一个标签之上的整洁堆栈中。那时我不想合并，因为我的提交最终会在历史上很久很久，我希望看到它们就在最前面，这样当我在我的存储库上使用某些工具时，我可以轻松地使用它们。

所以真的，我想要一个“浮动”分支，当我将上游更改带到我的存储库时，我可以移植到任意点。

[编辑] 但是，我不相信我可以使用变基，因为这是一个历史重写操作。你看，我在两台机器上使用我的存储库，我的开发和生产。我在开发机器上提交，推送到 github，然后拉到生产环境。所有这些都与我最初派生的上游存储库的更改无关。

我对移植、摘樱桃或任何其他可能适合的工具并不完全清楚。不管它是什么工具，我认为它不应该重写历史。从我的阅读中，我看到在 push 时重写 repo 历史是一个禁忌。所以我不确定我应该使用什么命令来移植一个分支而不重写历史。

如果我使用的是 mercurial，我可能会考虑使用版本控制的 mq。我不知道 git 的类似解决方案是否有，或者是否有另一种更适合 git 的工具。

[编辑]

在评估了我在这里得到的回复后，我最终确定挑选樱桃是正确的答案。在所有情况下，rebase 都会删除历史记录，并且由于这是一个共享存储库，因此删除历史记录是不可接受的，至少根据我读过的每个来源都是如此。

然而，Cherry-picking 会将提交复制到我的工作树，而不会将其从其原始位置删除。所以我可以将我的更改副本放在最新标签的顶部，并将它们整齐地堆放在一起。

作为记录，我还尝试使用 Mercurial 执行此操作，方法是使用 hg-git 扩展，它允许您使用 hg 克隆 git 存储库。这有利有弊。最大的缺点是，我用完后，它无法推动。hg-git 在那之前一直工作得很愉快，然后告诉你它不支持 hg 1.9。假的，至少可以这么说。另一个缺点是克隆和提取大量更改非常慢。但是，mq 和 TortoiseHg 的合并冲突解决工具是对 git cherry-pick 和 Smartgit 的合并冲突解决的巨大改进。我希望 hg-git 可以工作。

我想最后，“浮动”对于我的更改分支来说并不是一个很好的描述，因为结果是复制它而不是移动它。抱歉我的描述可能很糟糕，我仍在弄清楚这些选项到底是什么。谢谢您的帮助。

我有一个简单的问题要问你们 GIT 大师：

在 GIT 手册页中，我有这个

我的疑问是：当我选择一个提交到另一个分支时，这个提交会被移动到另一个分支还是被复制（在两个分支中都应用）？