2

我在分支 B。经过一堆提交后，分支 A 准备好/需要一些文件，但很多文件还没有准备好/不需要。我只想合并这些文件，保留正确的 git 历史记录。后来，当我真正合并时，我不希望对这些更改的起源有任何误导性的线索——它们应该正确引用它们来自的提交，即使作为这些提交的一部分的其他文件中的更改没有被合并（但）。我想这意味着将提交分为与这些文件无关的部分。

当我后来想将 B 合并到 A 但 B 的一些更改已经存在时，所有为此提出的解决方案最终都会丢失这些更改的历史并导致一个大问题。我想要一个避免这种情况的解决方案。

在 tortoise 中，我可以查看单个文件的日志并选择一些较旧的版本来恢复。因此，原则上，我可以从 B 创建一个新分支 C，并将我不想合并的所有文件恢复到 B 从 A 分支时的点。然后我可以将 C 合并到 A。这似乎是正确的跟踪 git 历史并让我将 B 合并到 A 中，而不会惊讶于 B 的一些更改已经存在。

但是当我只想合并2个文件时，手动识别和还原20个文件很痛苦。为什么这不是一个常见的一步操作？tortoise 的 revert 是如何工作的——因为它可以对单个文件进行操作，所以它必须是 sub-commit，这是我正在寻找的基本功能。它是否抛弃了我从较新的修订版到较旧的修订版的事实，并使它看起来像我只是进行了一些手动更改，然后与最终将 B 合并回 A 相冲突？

4

2 回答 2

1

您正在寻找cherry pick一种仅从要合并的分支中选择某些提交的方法。

要仅合并某些文件（当您不想合并整个提交时），您确实有多种解决方案，我喜欢使用本文中很好表达的一个，无论如何这都是一个痛苦，有点更简单我发现到那种事情。

您还可以拆分一些提交并仅合并包含正确文件的提交，您可以像其他文章所说的那样做

于 2012-06-07T13:48:04.433 回答
0

这不是一个常见的一步操作，因为Git 是一个内容跟踪器，而不是一个文件跟踪器。

您可以轻松地将更改应用于从分支 B 到分支 A 的特定文件，就像 Tortoise 一样：

# raw file, no history
git checkout A
git checkout B myfile

或者

# copy a set of history from someplace else
git checkout A
git cherry-pick commit-hash-1..commit-hash-2

但是这些都不会将历史记录保留为来自分支 B 的合并。如果这是您要尝试做的，取决于分支 B 中的提交的组织方式，这可能对您更好：Git：主要版本的分段合并方法变化？

于 2012-06-07T14:12:13.307 回答