变基时什么是内联合并
what is inlining merges when rebasing
我正在阅读 this article 关于 git rebase
的文章,其中包含以下段落:
By default, a rebase will inline merges. As we now make sure our
merges have clear semantics in our history graph, this inlining is
real bummer...
We can avoid this by telling rebase we want to preserve
merges: all we need to do is invoke it with --preserve-merges
(or the
shorthand -p
)
我不明白他说的内联是什么意思。你能提供一个详尽的例子让我明白吗?
Assume the following history exists and the current branch is "topic":
A---B---C topic
/
D---E---F---G master From this point, the result of either of the following commands:
git rebase master git rebase master topic would be:
A'--B'--C' topic
/
D---E---F---G master
因此,分支 topic
在基础 master
上的 rebase
操作获取不在 master 中的 topic
的所有提交,将当前状态重置为 master
,并逐一重放这些提交(要求用户处理一路上的不一致,这解释了提交 A'
、B'
... 可能不同于 A
B
..).
同样的逻辑适用于合并分支。正如您文章中的图片所示:
开始时,您有一个本地 master
,它是 master 和分支 origin/feature
之间的 merge commit。然后用户使用 rebase (git pull -rebase
) 进行拉取,这相当于在 origin/master
上重新设置分支 master
。在那个阶段,master
中不在 origin/master
中的所有提交都是 master
的 合并分支祖先 中的提交,也就是说, origin/feature
中的提交。问题在于,重播这些提交会消除这样一个事实,即那些曾经恰好合并到 master
中的外部分支。
也就是说,这个 replay
就是您要问的 inlining
。虽然对于常规分叉(上面文档中的示例)做这种事情可能没问题,但如果合并信息是您用来跟踪这些提交来自何处的信息(如您在文章中所述) link 到).
我正在阅读 this article 关于 git rebase
的文章,其中包含以下段落:
By default, a rebase will inline merges. As we now make sure our merges have clear semantics in our history graph, this inlining is real bummer...
We can avoid this by telling rebase we want to preserve merges: all we need to do is invoke it with
--preserve-merges
(or the shorthand-p
)
我不明白他说的内联是什么意思。你能提供一个详尽的例子让我明白吗?
Assume the following history exists and the current branch is "topic":
A---B---C topic / D---E---F---G master From this point, the result of either of the following commands:
git rebase master git rebase master topic would be:
A'--B'--C' topic / D---E---F---G master
因此,分支 topic
在基础 master
上的 rebase
操作获取不在 master 中的 topic
的所有提交,将当前状态重置为 master
,并逐一重放这些提交(要求用户处理一路上的不一致,这解释了提交 A'
、B'
... 可能不同于 A
B
..).
同样的逻辑适用于合并分支。正如您文章中的图片所示:
开始时,您有一个本地 master
,它是 master 和分支 origin/feature
之间的 merge commit。然后用户使用 rebase (git pull -rebase
) 进行拉取,这相当于在 origin/master
上重新设置分支 master
。在那个阶段,master
中不在 origin/master
中的所有提交都是 master
的 合并分支祖先 中的提交,也就是说, origin/feature
中的提交。问题在于,重播这些提交会消除这样一个事实,即那些曾经恰好合并到 master
中的外部分支。
也就是说,这个 replay
就是您要问的 inlining
。虽然对于常规分叉(上面文档中的示例)做这种事情可能没问题,但如果合并信息是您用来跟踪这些提交来自何处的信息(如您在文章中所述) link 到).