问题标签 [cherry-pick]

我认为许多开发团队的常见做法是在单独的功能克隆存储库中创建新功能或错误修复，并在功能/错误修复准备好时拉回并合并。

但是，有时我不想包含所有传入的更改。为了利用 DVCS 的所有力量来审查传入的更改，我认为有必要能够完全修改和选择传入更改的单个方面。

这种情况下首选的工作流程是什么？

据我所知，移植扩展提供了选择单个变更集的可能性，但我也想修剪/选择路径/文件库，例如排除一些测试脚本或类似的东西，这不再是最终功能所必需的.

既然移植是一种扩展，那么在 HG 中进行“克隆、更改、……审查”循环的官方方式是什么？

我有这个结构：

B、C 和 D 提交是功能分支路径。A是一个共同的基础。此功能作为 E 提交合并回 master。我已经标记（自动）提交 A。

我希望在没有用户干预的情况下自动（来自脚本），无论功能分支中有多少次提交，在另一个分支中选择“mytag”到“master”作为 A、E（在这种情况下）。

现在，如果我这样做：

它将选择 A、B、C、D 和 E 提交。我希望它只从 master 分支中选择提交，即 A 和 E。注意：我不想以相反的方式合并到 E 中。我希望它成为大师的特色。而且 A 到 E 根本不确定那是分支。它可能是 A --- E。只是我需要像“..”这样的运算符，但要使用其他分支的方式。

我在这里先向您的帮助表示感谢！

另外：第三个分支是我应该挑选的，应该如下所示：

即 A 和 E 将在“其他”分支中被挑选出来。

我已经在一个分支上黑了一段时间，这个分支很快不会被合并。但是无论如何，我还是想在 master 中合并一些提交。

有没有办法获得一个交互式的挑选，它会显示提交及其更改，然后让我选择我真正想要挑选的那些？

我在我的主分支中进行了一些更改，并希望将这些更改带到上游。当我挑选以下提交时。但是，我卡在 fd9f578 上，git 说：

git 试图告诉我什么，并且挑选合适的东西在这里使用？master 分支确实包含对上游分支中已修改的文件的更改，因此我确信会有一些合并冲突，但这些冲突并不算太糟糕，无法理顺。我知道在哪里需要进行哪些更改。

这些是我想带到上游的提交。

我有以下 git 历史：

我们有一个政策来挑选从稳定到大师的所有变化；D' 和 E' 是来自稳定分支的精选提交，F 不是精选的（已被遗忘）。

我怎样才能得到一个与 F 相匹配的差异（它不是精心挑选的主人）？

我们不想使用合并，因为：

• 没有合并提交的更清晰的历史记录
• 对稳定的提交很少见
• 我们有很多不同的稳定分支

最近，我被要求cherry-pick提交。

那么在 git 中挑选提交是什么意思呢？你怎么做呢？

出于某种原因，当苍蝇发生合并冲突时，看起来 git cherry-pick 会拉入其他提交。这些在我们使用时会消失，git mergetool但会阻止我们手动编辑合并冲突的文件。

有谁知道为什么会这样？

为了说明我的意思，让我们使用一个带有单个文件的全新 git 1.7.4 存储库foo：

让我们在这一点上创建一个名为bar. 回到 master，让我们在单独的提交中添加三个更改到这个文件。

提交 1：

提交 2：

提交 3：

由于最后一次提交很重要，因此我们决定将其拉回分支bar并git cherry-pick <commit>在该分支上。

不幸的是，这会在 file 中产生一个有趣的合并冲突foo：

请注意，这git mergetool似乎做了正确的事情并产生了这个：

为什么合并冲突的文件包含我们试图挑选的那个之前的提交？

最近有几个关于在 Mercurial 中维护发布分支时跳过更改的问题。例如：

• Mercurial：分支特定更改在虚拟合并后不断返回
• 为什么一个分支中的 Mercurial 退出会影响其他分支？

由于它是在 2.0 中引入的，我一直想知道如何使用它graft来避免这个问题。给定这样的修订树：

假设我们需要创建一个跳过 Evil 更改的发布分支E。

给我们：

• Q1：这里发生了什么？我可以理解，transplant会从 生成补丁F::J，然后将它们应用到D，但graft据说使用 3 路合并而不是补丁。所以.......这是如何工作的？为什么更好？

假设我现在修复E，并将其合并到我的发布分支中。

M1是直接合并；那里没什么特别的。M2 正在合并具有“相同”（或至少等效）更改的分支。

• Q2：这种合并只是使用D,J'和的普通 3 路合并M1吗？
• Q3：mercurial 是否存储/使用了有关移植操作的额外信息来帮助它进行合并？

最后...

• Q4：这样的流程有哪些潜在问题？

我是 git 的新手，我确实了解 git cherry-pick 的工作原理，但这是我的问题：

最近，我的团队中有人更改了 master 中的目录结构，但没有更改另一个分支中的目录结构。

现在，当我在分支中对我的代码进行更改时，我想将它们（樱桃挑选）带入 master。这很好，直到主目录和分支中的目录结构相同。

topDir/some/subdir/file -- master
topDir/some/other/subdir/file -- 分支

文件，其更改将被带入 master 是相同的，但不是它包含的目录结构。当我尝试以通常的方式进行樱桃挑选时，我收到如下错误：

git checkout master git cherry-pick commit 错误：pathspec topDir/some/other/subdir/file 不存在

现在，在这种情况下挑选樱桃的最佳方法是什么？任何指针都受到高度赞赏。

好的。我只是注意到，在同样的场景中，当我进行挑选时，git 足够聪明，可以从提交中正确地选择一个文件，但不能识别另一个。

使用我在原始帖子中提到的相同示例：在同一个提交中，topDir/some/subdir/file1，topDir/some/subdir1/file2。

我去master，它有“file1”和“file2”，只是在不同的目录结构中：topDir/src/some/subdir/file1 topDir/src/some/subdir1/file2。

现在，如果我进行挑选，git 足够智能以获取 file1 中的更改，即使这是在不同的 dir 结构中，但不会获取 file2 的更改。任何指针？如果有人想让我更清楚，我会很乐意。

所以，我为解决这个问题所做的就是挑选一个樱桃，手动更改一个 git 没有拾取的，然后“git commit -C .

我有两个分支：主干，生产。我在主干中发现了一个问题，修复并提交了它，推送了它。现在它已经过测试，我需要将更改合并到生产分支中作为热修复。我尝试使用樱桃采摘。但是它不起作用，因为在一些我不想投入生产的重构过程中，修复程序中更改的文件在早些时候在主干中被重命名。

我不想合并所有东西，但只接受这个提交。樱桃挑选因“被我们删除”冲突而失败（当然，新文件甚至从未存在于生产分支中）。

将更改带入旧文件的正确方法是什么？