Git 为什么分支B在第一次合并提交后从A到B的所有合并提交中都有冲突？

我有一个历史悠久的初级发展分部（a）。中的所有发布提交都被标记为这样。我检查了A的根提交，并分支到测试（B）

所以我有一个主分支a，分支B的头指向a的根提交。我的目标是通过将每个标记的提交从a合并到B来创建所有发布的历史记录

从A到B的第一次合并按预期进行，没有冲突

$git checkout B
$git merge [release-commit-ID] --squash
$git commit -m "release#"

第一次提交非常有效，但所有其他提交都将所有合并提交视为完全冲突。我看到B的根与A的根相同，但在A中第一次发布提交到B中的第一次压缩合并提交之后，没有识别出共享历史。是什么导致了冲突以及如何识别共享历史

冲突的原因是什么？我如何让共享的历史得到认可

没有共同的历史（或者说，还不够）。没有什么需要承认的，这就是为什么会有冲突

$git checkout B
$git merge [release-commit-ID] --squash
$git commit -m "release#"

关键是

--squash

标志：

第一步将您的

头

附加到分支名称

B

，检查名称

B

标识的提交：

...--*--C--D--E   <-- B (HEAD)
      \
       F--G--H   <-- somebranch

然后重复，比如说，

G

：

git diff --find-renames <hash-of-*> <hash-of-G>   # what they changed

现在，这两行之间最新的公共起点是commit

G

。但是如果您确实使用了

--squash

，Git只记录一个父级的新提交：

给我们：

...--*--C--D--E--I   <-- B, newbranch (HEAD)
      \         /
       F-------G--H   <-- somebranch

我们现在可以放弃

somebranch

：

$ git branch -D somebranch

如果我们愿意的话，可以将

newbranch

重命名为

somebranch

---

（请注意，我们可以使用

git-rebase--to

，使用

git-checkout-somebranch；git-rebase--to-B

，一步完成名称移动的复制。但是，不管您如何做，请注意，

git-cherry-pick

无法复制合并提交，任何使用提交的人都要在这里杀死

F-G-H

chain必须通过复制来保存内容来完成这项工作。因此，在使用

--squash

之前，请确保您理解所有含义。）

谢谢，我忽略了squash将只有一个父对象，然后在所述squash之后的所有提交都将与之前的所有其他squash冲突。这非常有帮助。

...--*--C--D--E--I   <-- B (HEAD)
      \
       F--G--H   <-- somebranch

$ git checkout -b newbranch B

...--*--C--D--E--I   <-- B, newbranch (HEAD)
      \         /
       F-------G--H   <-- somebranch

$ git cherry-pick somebranch   # or <hash of H>

                   H'   <-- newbranch (HEAD)
                  /
...--*--C--D--E--I   <-- B
      \         /
       F-------G--H   <-- somebranch

$ git branch -D somebranch