Git合并进程忽略文件

有两个分支：

branch A

带有一些文件，以及

branch B

带有名为

FolderB

的文件夹。当我将分支B合并到分支A中时，提交中的暂存文件中没有“FolderB”。这是我意想不到的行为。我记得几天前，在这次合并之前，我进行了另一次合并，最后通过选择选项

保留我们的
解决了冲突。也许这个选项保存在某个地方，现在它会产生副作用。如果是，我在哪里可以删除这些设置？
通常，当一个文件被git进程忽略时，这是因为该文件与
.gitignore
文件的一行匹配

如果您确定
FolderB
应该是回购的一部分，请确保分支A和B的
.gitignore
文件不包含
FolderB
。还要确保
FolderB
尚未完全合并到分支A中

我记得几天前，在这次合并之前，我进行了另一次合并，最后通过选择选项
保留我们的
解决了冲突。也许这个选项保存在某个地方，现在它会产生副作用

我无法与其他接口（可以做这类事情）对话，但命令行Git不保存合并策略和策略选项。然而，您已经合并的事实意味着您并不是从您认为的起点开始

首先，让我们做一个简单的说明：“合并”并不意味着“使相同”。如果是这样的话，我们就根本不用担心树枝了。假设您和我都从软件的
v1.1
开始，我对我的副本做了一些更改，而您对您的副本做了一些更改。如果我从你那里得到你的承诺，然后跑：

$ git merge yours

这取代了我所做的和你所做的，我可能不会很高兴

因此，
git merge
所做的是找到一些共同的起点，git称之为合并基提交，并找出您和他们，无论“他们”是谁，从那时起都做了什么。但这意味着您必须理解Git是如何找到这个共同的起点的

合并基
让我们看看正常的提交过程。我们首先克隆一些现有的存储库：

$ git clone <url>

其中名称
master
记住提交
H
的ID。Commit
H
记住Commit
G的ID，它记住Commit
F
的ID，依此类推。这些内部联系，我们可以像这样画成向后的箭头，总是从子提交到父提交，从子提交到父提交：提交知道他们的祖先，但不知道他们的后代。一旦做出承诺，任何承诺都无法更改，因此不能更改承诺以记住其子代，但子代也不能忘记其父代

因此，假设您克隆了存储库，我克隆了存储库，我们都有：

...--F--G--H   <-- master

Git现在的工作是组合这些更改，将它们应用到
H
中的快照，并根据结果进行新的合并提交。如果一切顺利，Git将自行完成这项工作。如果没有，则会出现合并冲突，必须正确解决这些冲突。您告诉Git您已经这样做了，然后Git进行新的合并提交：

...--F--G--H--I---L   <-- master (HEAD)
            \    /
             J--K   <-- other

如果您现在再次运行
git merge other
，git必须使用我的最新提交
Q
找到您的最新提交
N
的合并基础。这次的合并基数不是
H
！我们从
N
和
Q
开始，向后查找最近的共享提交。从
Q
开始，只有一条向后的路径，通过
P
，
O
，
K
，
J
，
H
，等等

然而，从
N
开始，我们可以在commit
L
中双向执行：
N
，
M
，
L
，然后是
I
和
K
。1因此，第一次共享提交现在是
K

这次，
git merge
将针对两个分支tip提交执行diff commit
K
，
N
和
Q
。同时，我们早期的合并commit
L
，就是我们告诉Git将
K
与我们的工作相结合的正确方法

那么，假设这些新文件添加到提交
J
或
K
中，但不在
L
中，因为我们选择了“保留我们的”选项。从
K
到
N
的差异将显示：删除这些文件。从
K
到
Q
的差异可能会也可能不会修改这些新文件。我们可以猜测，在这种情况下，它不会修改它们，因为如果它修改了，我们将得到一个新的合并冲突，Git告诉我们，我们删除了这些文件，而它们更改了这些文件。如果他们没有更改它们，Git会假定我们的“删除”是正确的答案，并将它们保持删除状态


1请记住，内部箭头总是以我在此处绘制的方式向后指向左侧。我们可以从
L
到
K
，但不能从
K
到
L


怎么办
如果这是正在发生的事情（根据我的经验，确实是这样），那么真正的问题是您先前合并我们上面绘制为
L
的提交是错误的：它删除了文件。但我们已经注意到，您不能更改任何先前的提交

有两种解决问题的策略。第一种方法（通常也是最好的方法）是确认错误并将其保留在原位：将错误的合并保留在原来的位置，但现在添加一个新的commit来存储已更正的快照。我们可以用多种方式来实现这一点。所有这些都涉及很多工作。对于大多数情况，我首选的方法是重新执行合并，但这次要正确执行：在不正确的合并之前创建一个指向提交的新分支：

                ............<-- rework (HEAD)
               .
...--F--G--H--I---L--M--N   <-- master
            \    /
             J--K--O--P--Q   <-- other

或者，如果你确定你想为每一天“保留我们的”
...--F--G--H--I   <-- master
            \
             J--K   <-- other

git diff --find-renames <hash-of-H> <hash-of-I>   # what we did on master
git diff --find-renames <hash-of-H> <hash-of-K>   # what they did on other

...--F--G--H--I---L   <-- master (HEAD)
            \    /
             J--K   <-- other

...--F--G--H--I---L--M--N   <-- master (HEAD)
            \    /
             J--K--O--P--Q   <-- other

                ............<-- rework (HEAD)
               .
...--F--G--H--I---L--M--N   <-- master
            \    /
             J--K--O--P--Q   <-- other

$ git diff <hash-of-L> <hash-of-new-merge> > /tmp/patch
$ git checkout master
$ git apply /tmp/patch