问题标签 [cherry-pick]

我即将将主干中的某些修订合并到发布分支中。我已经用mergeinfo检查了有多少修订有资格被合并，那是42个。虽然检查每个修订日志并决定是否应该合并绝对是可能的，而且并不难。然后，我会使用 TortoiseSVN 检查日志并使用命令行svn merge -c rev1,rev2功能或-r当然是范围。

我想知道 TortoiseSVN 是否有一个工具可以让这种挑选工作变得更容易。我用谷歌搜索了它，但发现只有 TortoiseGit 可能有它。

也欢迎任何其他使此过程更容易（和更快）的方法！

我们刚刚从 Subversion 切换到 Git。

今天早上出现的问题是，我们从一个分支中挑选了一个提交到 master 中，这样 maser 就会有一个错误修复。然后我们将master合并回分支。

当我们尝试编译时，所有来自精心挑选的提交的添加都在代码中出现了两次。

精心挑选的提交包括添加几行代码，最终在代码中出现两次。幸运的是，它们是完整的函数，因此会引发编译器错误。

从来没有发生过冲突。

我们如何避免这种情况。这是一个大问题。

谢谢。

假设我们有一个master分支。

然后我们创建一个newbranch

并做出两个新的提交newbranch：commit1和commit2

然后我们切换到master并制作cherry-pick

调查gitk我们看到commit1及其精选版本具有不同的哈希值，因此从技术上讲，它们是两个不同的提交。

最后我们合并newbranch成master：

并看到这两个具有不同哈希值的提交合并没有问题，尽管它们暗示应该应用两次相同的更改，因此其中一个应该失败。

git 在合并时是否真的对提交的内容进行了智能分析，并决定不应两次应用更改，或者这些提交在内部被标记为链接在一起？

我想在获取的遥控器上挑选一个提交，同时保留它的原始 SHA 提交代码（我当前的分支基于我重置为以前状态的这个遥控器）。

我做了以下事情：

选择的提交已被干净地应用，只是在其中一个文件中它具有与我在之前的提交中所做的完全相同的更改，因此不会重新应用这些更改。

代码方面的一切都很好，但我想在我的历史中拥有提交哈希。在我的历史中，它以一个新名字出现。这甚至可能吗？就我正在阅读 git merge “我们的” 策略而言，它似乎通常是可能的，但如何为单个提交做到这一点？

我想要这个，以便以后更容易识别提交所做upstream的事情我没有。目前在 githubnetwork视图中，我认为精心挑选的提交是我没有的独立的东西。

附加信息：@CharlesB 所说的对我来说很有意义。但是merge -s ours魔法是怎么做到的呢？在这种情况下，这对我来说并不重要cherry-pick。因为我想要进行的更改只是一个并且在upstream/master. 所以只是为了尝试一下，我做了：git merge -s ours upstream/master

现在git log --graph --pretty=oneline --abbrev-commit我看到了类似的东西：

之前 的相同命令git merge -s ours看起来像：

正如您在挑选提交 aa7117d 之后所看到的，没有迹象表明 aa7117d 已应用于我的 fork 存储库。但是在合并后它表明它在那里，尽管我的文件中没有任何变化。

这使我认为确实可以声明一个分支中包含的许多提交，尽管它们的应用与上游应用的完全不同。

update2：我看到了如何在 Git 中合并特定提交及其最佳答案的问题。因此，也将不胜感激解释为什么它不可能或未实施。

在 Git 中，cherry-pick至少在没有冲突的情况下保留原始提交的作者、时间戳等。但是有没有办法确定哪个用户执行了将提交带到新分支的cherry-pick？

我对这个主题进行了很多搜索，但没有找到令人信服的答案。

我有一个分支 B，用于功能 F1、F2 和 F3。提交混合功能（例如，F1 提交，F2 提交，F1 提交）。功能 F1 现已完成，应该重新集成到主干，但 F2 和 F3 没有。

据我了解，重新集成到主干（使用 --reintegrate）与普通的 svn merge 不同，因此 svn merge 在这种情况下不可用（对吗？）。svnbook 提到了像樱桃采摘这样的选择性合并，但仅限于从主干/分支到分支。但是， --reintegrate 也会将 F2 和 F3 带到主干。

我如何（如果可能的话）将选定的修订从分支 B 重新集成到主干，然后继续完成分支 B 中的其他功能？

我发现一些答案提到 svn 将修订合并到主干，然后使用 --record-only 在分支中阻止这些修订。但是，由于 svn merge 和 svn merge --reintegrate 的根本区别，我不确定这是否是好的做法。svn 从一个分支合并到另一个主干不会复制主干中先前同步到分支的变更集吗？

我正在尝试在 git 中挑选一个提交，它添加了一堆文件，但也修改了一个在我的分支中尚不存在的文件。

存在冲突，要添加的文件都已暂存，并且在提交中更改但在分支中尚不存在的文件未暂存，并列为：

changed_file.rb如果我只是提交暂存文件，当最终合并到分支时会导致问题吗？

我一直在尝试使用

生成在 my-branch 中但不在 master 中的提交列表（根据 git-log 文档）。但是，列表中仍然有许多等效的提交。如果我展示它们和它们的补丁，除了提交 ID 之外没有任何区别。

甚至git patch-id显示它们是等价的：

如何不git log --cherry-pick将这些作为重复项？

我最近遇到了一个问题，我需要选择一些文件来使用 git 推送到远程分支。我的具体用例是在每次提交中只创建/修改一个文件，我需要以编程方式推送选定的文件（处于最新状态）。我做了一些研究，发现了两个接近我需要做的技巧：

1. 我可以使用cherry-pick 将某些提交挑选到一个新分支中并将该分支合并到远程主控中。
2. 我可以使用 rebase -i 重新排序提交，我假设我可以重新排序，以便与这些选定文件相关的提交都在前面，我可以推送该列表中的最后一个提交。

对于cherry-pick来说，这有点令人困惑。我可以创建一个没有所有脏提交的新分支，然后将文件提交选择到该分支中。但是，如果该文件已经存在于分支中，它总是会引发我必须手动修复的冲突，这并不理想。

对于 rebase -i，从我读过的内容来看，我需要转到一个交互式编辑器，我需要在其中手动重新排序提交，然后我可以执行 git push origin 以将所有内容应用到提交-SHA（重新排序） . 不理想，因为我必须做手工工作。

总的来说，我认为 rebase 更接近我的需要，但我找不到一种简单的方法来以编程方式完成它。谁能想出一些可以完成我任务的git类比操作？