问题标签 [git-cherry-pick]

我有一个在 TFS 中启动的项目，然后转移到 Git。不幸的是，将它移至 Git 的人只是签入了当前文件，而不是使用 git-tfs。我试图在我使用 git-tfs 从 TFS 提取的提交之上重新调整他在 Git 中的新提交。

为此，我只是将他的提交重新设置在 git-tfs 提交之上。（我意识到这会弄乱远程 Git 分支，但我们是一个小团队，没关系。我也尝试过樱桃采摘，但我遇到了同样的问题。）

我遇到的问题是一组看起来像这样的冲突：

看来这是添加这些文件的 TFS 端的提交与添加它们的 Git 端的提交之间的冲突（因为 Git 存储库一开始是空的）。

合乎逻辑的事情可能是跳过这个提交，但是其中有几个文件（比如说几百个中有十个）是新的。当然，这些不会引起冲突。

为什么 Git 不能自己弄清楚这两个文件是相同的？即使我--ignore-whitespace在 rebase 时使用，Git 仍然会显示数十个类似的文件，这些文件似乎是相同的。我不知道如何解决这个问题。

这可能是一个幼稚的 git 问题，但它是：

在进行拉取请求之前，我通常从上游的最新提交创建一个新分支，并从我的开发分支中挑选重要的提交。然后从我的新分支向远程存储库发出拉取请求。

但是我讨厌合并冲突（尽管 git mergetool 在它们发生时有很大帮助）。我怀疑其中一些冲突是由樱桃挑选的顺序引起的。我通常会从最旧到最新的提交中挑选一组提交。这是正确的方法吗。还是提交顺序对git无关紧要？

是否有任何其他技巧可以最大限度地减少樱桃采摘期间的合并冲突？

在正常的 Git 合并冲突中，三路合并的文件的三个版本大致如下：

• 本地：我的分支的版本
• REMOTE：来自另一个分支的版本
• BASE：来自两个分支的共同祖先的版本（特别是我分支的 HEAD 和另一个分支的 HEAD 的共同祖先）

当一个 Git cherry-pick 产生合并冲突时，没有共同的祖先，正确地说，那么这些东西是如何确定的呢？关于变基也可以问同样的问题。

假设您从远程开源项目（例如在 Github 上）克隆了一个本地存储库。您在本地存储库中进行更改，添加分支等。

您有以下目标：您所做的一些更改是出于您自己的目的，不会回馈给主存储库，其他更改是社区感兴趣的，例如错误修复和功能添加以及您会喜欢回馈主回购。

因此，基于此，让我们假设两个主要分支：一个用于所有更改的 dev-proj，一个带有子集的 dev-comm 将被贡献回主 repo。

在一般情况下，您会知道给定的一组更改是否会进入 dev-comm，因此您可以将它们隔离到一个分支中。

但是，在一些复杂的情况下，您不希望分支受制于是否应在上游贡献更改。

以 Web 应用程序的本地化为例——翻译和视图的变化等。您为它创建了一个分支并打算将其保密，但在处理它时您发现原始代码存在 i18n 问题，因此您将这些问题作为您在此分支上工作的一部分进行修复。这些将 WRT 更改为 i18n，您希望将其隔离并推回主存储库。

我的问题是：挑选处理这种情况的最佳方法 - 我担心尝试细化提交会分散注意力，如果我错误地做出涉及大量私人和社区的提交会发生什么更改，那么我将不得不尝试为此应用修复程序。或者是否有更好的技术，即使它涉及一些手动元素。

编辑：我将用一个粗略的草图澄清一下：p 用于本地项目，c 用于专门为社区推送到上游的更改：

在处理主题 A 时，我们不想关心哪些部分是为社区服务的。但最后，我们希望有一些类似 topicAcomm 的东西，可以合并到 devComm 中并推送到上游。

我的问题是挑选樱桃是否是处理这个问题的方法，从检查文档/教程来看，这似乎是一种合理的方法。或者是否还有其他一些技巧，例如稍后注释代码或其他一些我不知道的技巧。

意外混合提交只是可能出现的问题之一。

假设有项目存储库（在 GitHub 上）和我的 fork（也在 GitHub 上）。我的 fork 是相同的，除了包含对单个文件（错误修复）的一个修订，该文件（尚未）被项目存储库接受。我正在尝试向第三方提供有关如何下载最新版本软件的安装说明，包括我的错误修复。

据我所知，他们必须这样做：

（假设我不打算让 myrepo 保持最新 - 我希望我的指示能够比我参与该项目的时间更长，该项目可能很快就会结束。还假设此文件可能会发生其他更改，因此只需下载一份整个文件不安全。）

一些次优的：

1. 他们需要转移两个完整的 Git 存储库
2. 仅获取一个文件就需要三个额外的命令。

有更好的解决方案吗？你能以更简单的方式获得一个修订版吗？

我正在尝试将来自分支的特定提交合并到 master 中，并将它们推送到原点。

这是我正在做的事情：

我哪里错了？

我担心的是，我在另一个本地分支中有旧的提交 [包含 abc.cpp，def.cpp]。

现在几个月后我想使用这些更改，但是在我当前的分支中 abc.cpp 已升级。那么，如果我选择樱桃，它会将旧 abc.cpp 的更改整合到新的 abc.cpp [最近的工作目录副本] 中吗？

I'd like to cherry-pick single commits from on branch to another. I expect file renames to be quite common but still want to be able to apply changes without human intervention.

Since the built-in cherry-pick command doesn't seam to detect renames (at least in my test cases), especially when combined with modification to the renamed file.

I tried a bit and finally came up with a solution involving two rebase operations.

Let's assume I have a branch named target pointing at the commit I want to apply the cherry-pick to. The commit I want to cherry-pick is pointed to by a branch named source.

I then execute the following commands:

1. create branch sourceTemp pointing at the same commit as source (since I want to retain the branch source )
2. git rebase --strategy="recursive" --strategy-option="rename-threshold=30" target sourceTemp (maybe use another threshold; the test file was quite small and the changes therefore relatively large)
3. git rebase --onto target sourceTemp~ sourceTemp

This applies only the changes introduced by the last commit in branch source to target.

I also put my test on github:

https://github.com/fraschfn/cherry-pick

What I like to know is, if this approach is feasible or if it only worked in my simple test setting!

Update: Alternative method

I rebase the patch to the merge base of source and target:

start situation

I want to cherry-pick D onto B.

1. rebase D onto M after creating a new branch patch

   /li>

2. merge C and D' to obtain a replacement for source

   merge B and D' to obtain the patched version of target

   /li>

The advantage is that E and F can now be merged without a problem. Alternative way: Include the patch as early as possible in the hierarchy thus not creating D but directly D' and saving yourself the rebase.

The advantage above the previous version is that you can merge the two branches "new source" and "patched target" and it will work (if the merge of source and target would work of course) and not introduce the same changeset twice since git knows due to the merge operation which introduced the changeset into both branches.

我在合并同事的提交时犯了一些错误。现在，我们发现了它，我们需要再次应用旧提交，以手动选择文件中的更改。情况如下所示：

我需要 git 再次要求我将 B 与 I 合并，就像 B 从未出现在历史上一样。换句话说，我需要 git 要求我为 B 和我提交的所有不同文件选择合并。做这种事情的最佳方法是什么？我可以用樱桃采摘来做到这一点吗？如何？

昨天我在我的主分支中挑选了两个提交，其中一个导致了合并冲突，我解决了它们，提交并将它们推送到原点。今天，当我收到以下错误时，我试图从服务器中提取：

Git状态读取：

我尝试了以下方法无济于事：

关于如何解决这个问题的任何想法？提前致谢！