git合并覆盖内容

以下是我的情况：

• 我有两个功能分支A和B

• 我想合并这两个分支

我做了以下工作：

• 创建一个新的分支C，从

• 签出新的分支C

• 从命令行运行

  git merge B

我希望这两个分支合并在一起。如果对相同文件的更改存在冲突，则该命令应引发合并冲突

但实际上，有一个相同的文件在分支a和B中有不同的内容，但没有报告合并冲突。相反，来自分支A的文件内容被来自分支B的文件内容覆盖

我不知道为什么没有报告合并冲突，更担心的是为什么文件内容被覆盖

---

任何提示或指针都会有所帮助。谢谢。

让我们来说明发生了什么

• 我有两个功能分支A和B

通常是这样的

           4 - 5 [A]
          /
 1 - 2 - 3 - 6 [master]
              \
               7 - 8 [B]

A和B从

master

分支。他们分歧了

但你可能有这个

                 6 - 7 [B]
                /
           4 - 5 [A]
          /
 1 - 2 - 3 - 6 [master]

这里B是A的分支。B分享A的所有承诺。让我们假设一下

• 创建一个新的分支C，从

在Git中创建一个新分支只需在提交的同时创建一个新标签

                 6 - 7 [B]
                /
           4 - 5 [A][C]
          /
 1 - 2 - 3 - 6 [master]

• 签出新的分支C
• 从命令行运行

  git merge B

当这种情况发生时，Git注意到C是B的祖先。因此它执行“快进”操作，这意味着它不需要进行合并，它只是将C推进到B所在的位置

                 6 - 7 [B][C]
                /
           4 - 5 [A]
          /
 1 - 2 - 3 - 6 [master]

如果A和B更改了相同的文件，则B似乎重写了A中的更改

---

git日志

和Github不幸地抹平了您的git历史，给您一个线性的错误印象。您可以使用

git log--graph--decoration--all

查看存储库的真实结构，并检查它是否与此处的场景匹配。

您可以链接到GitHub上的分支吗？您可以向我们展示

git log--graph--decoration--all

的相关部分吗？然后我们可以看到分支之间的关系。

git config-l

中有什么奇怪的地方吗？你能告诉我们你运行的命令的确切顺序和git merge的输出吗？也许B是从A分支出来的？@JBallin你的意思是提供分支的链接吗？在我的例子中，我可以看到A和B分支都是从master分支出来的（虽然可能不是同时）。如果是这样，我是否应该从master创建分支C，然后将A合并到C，然后将B合并到C？为了确保A和B都没有丢失提交？