git与多个父级丢失父级合并 [英] git merge with multiple parent loss parent
问题描述
我有一棵这样的树
* b
|\
| * a
|/
* master,m
现在我想将 a和b 合并为master
now I want to merge a and b into master
git checkout m
git merge --no-ff a b
但它给出了
* m
|\
| * b
| |\
| | * a
| |/
| /
|/
* master
表示合并后m没有父a的
.
which shows m has no parent a after merge.
这是预期的行为吗?
我该怎么做(m有父母master，b和a)?最好只使用单个(合并)命令.
Is this expected behavior?
can I do what I want (m has parents master,b, and a)? better just use single (merge) command.
此脚本重现了情况
git init
git commit --allow-empty -m "init"
git branch m
git branch a
git branch b
git checkout a
git commit --allow-empty -m "a"
git checkout b
git merge --no-ff a
git checkout m
git merge --no-ff a b
git --version: 2.16.2.windows.1
推荐答案
这是正常行为.
要合并的部分有两个:
- 为快照派生正确的源树.
- 产生正确的更新的提交图.
在这里，我们假设第1步已经神奇地完成了. :-)也就是说，我们只关心最终的提交图.
We'll assume here that step 1 has magically been taken care of. :-) That is, we'll concern ourselves only with the final commit graph.
在Git中合并(无论是否是章鱼)都涉及确保选择的最终提交具有所有输入提交作为祖先.如果您当前的提交是所有提议的合并提交的始祖，则合并 可以作为快进操作完成，默认情况下， 可以作为快速操作完成-向前操作.
Merging, whether octopus or not, in Git involves making sure that the final commit chosen has all the input commits as ancestors. If your current commit is an ancestor of all your proposed merge commits, the merge can be done as a fast-forward operation, and by default, will be done as a fast-forward operation.
这里的缺点是有时我们希望通过--first-parent区分代表分支的单行提交.如果Git进行快进操作，则该行(至少潜在地)将其他合并提交的其他第一父级混合在一起而被销毁.例如，在您的情况下，b指向合并提交，其父标签为a(在一侧)，然后是master和m(在另一侧).因此，Git提供了--no-ff来强制进行真正的合并，方法是进行第一个父项为当前提交的新提交.
The drawback here is that sometimes we wish to distinguish, via --first-parent, a singular line of commits that represent a branch. If Git were to do a fast-forward operation, this line would (at least potentially) be destroyed by mingling other first-parents of other merge commits. For instance, in your case, b points to a merge commit with parents labeled a (on one side) and then master and m (on the other). So Git offers --no-ff to force a real merge, by making a new commit whose first parent is the current commit.
但是，即使对于多头章鱼"合并，如果您的参数提交名称或哈希ID是彼此的祖先，则Git也会丢弃作为祖先的祖先:由于a是b，Git不必使用a来生成 正确的图形或正确的源代码快照，因此就不必.
But, even for a multiple-head "octopus" merge, if your argument commit names or hash IDs are ancestors of each other, Git will drop the one(s) that are ancestors: since a is an ancestor of b, Git does not have to use a to produce either a correct graph or the correct source code snapshot—so it just doesn't.
Git根本没有理由不能将两者 b 和 a都作为新合并的父母(第二和第三，可能以此顺序)犯罪.所有常用算法将继续起作用.只是不必要.
There's no fundamental reason that Git could not include both b and a as parents—second and third, probably in that order—of the new merge commit. All the usual algorithms will continue to work. It's just unnecessary.
这篇关于git与多个父级丢失父级合并的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
