Question

我对git merge感到困惑。

假设我从feature获取了master分支，并且他们已经分歧了他们像这样合并了

enter image description here

现在我想知道这个命令之后的图表是什么

git checkout master
git merge new-feature

此命令后的图表是什么

git checkout master git merge new-feature

之后提供我之后不关闭功能分支，然后在功能分支上再做一次提交

Answer 1

答案是：由于合并，feature分支没有任何反应。新合并提交将添加到当前分支（合并完成时为master）。没有现有的提交受到影响，因为根本不能更改任何现有的提交。

顺便说一下，提交之间的箭头确实应该指向另一个方向。新提交指向旧提交;旧的提交永远不会被修改，而不是最小的一点，所以没有办法向旧的提交“添加箭头”。您只能向一个或多个较旧的提交创建一个新提交，该提交有一个或多个后向箭头。（每个指向提交一个箭头，即。你甚至可以使用 no 后向箭头进行新的提交：这是一个新的“root commit”。这是一个更高级的提升但是，事情并不是存储库中常见的东西。）

尽管ASCII艺术版本并不漂亮，但在图表之前和之后它们是相同的：

        o-o     <-- feature
       /
o--o--o--o      <-- master

[变为：

        o-o     <-- feature
       /   \
o--o--o--o--o   <-- master

如果您在此之后签出feature并向feature添加另一个提交，则会变为：

        o-o--o  <-- feature
       /   \
o--o--o--o--o   <-- master

编辑：让我们重新绘制最后一张图片（相同的图片，我们只是为“合并＃1”添加一个名称m1，代替其中一个o代表一个提交）：

        o-o--o  <-- feature
       /   \
o--o--o--o--m1  <-- master

现在假设您继续开发feature，再添加两个提交：

        o-o--o--o-o    <-- feature
       /   \
o--o--o--o--m1         <-- master

然后决定再次将feature合并到master。为此，git需要进行新的合并提交m2：

        o-o--o--o-o    <-- feature
       /   \       \
o--o--o--o--m1------m2 <-- master

new 合并的合并基础是通过查看旧合并得出的，因此git可以告诉我们只有三个最新的feature提交需要被带进来。

这就是为什么，如果您确定feature中的某些内容已损坏master而您在添加合并m2之前“撤消”它，则需要在需要时手动“重做”它。也就是说，假设在进行合并m1之后但在feature上添加三个新提交之前，您发现master已损坏且您添加了提交f（“修复删除一段功能“）：

        o-o         <-- feature
       /   \
o--o--o--o--m1--f   <-- master

现在你继续像以前一样在feature工作，添加三个提交：

        o-o------o-o-o    <-- feature
       /   \
o--o--o--o--m1--f         <-- master

现在，当您转到git merge feature进入master时，git将再次找到基础，并且知道只需从三个最新提交中进行更改并将其添加到f：< / p>

        o-o------o-o-o    <-- feature
       /   \          \
o--o--o--o--m1--f------m2 <-- master

但是提交f故意禁用部分新功能。您可能必须手动修复合并（在进行提交m2之前，或者在m2之后的单独提交中 - 您希望如何做到这一点取决于您）“撤消”修复f，重新启用完整功能。

无论以后是否以及何时将feature再次合并回master，您都可以选择是否将master合并到feature。例如，我们假设G中有一些特别master的内容，应带入feature：

        o-o        <-- feature
       /   \
o--o--o--G--m1     <-- master

在这里你可以：

git checkout feature && git merge --no-ff master

将G和m1中的更改纳入feature。当然m1中的变化已经存在，但是git可以自己解决这个问题，所以它实际上只会从G中引入好的东西：

        o-o----m2  <-- feature
       /   \  /
o--o--o--G--m1     <-- master

只有在需要显式合并提交时才需要--no-ff，这对于使“功能”的开发线脱颖而出非常有用。如果您遗漏--no-ff，git会发现将m1带入feature会导致m1，并且只会将分支标签移到“快进”中操作：

        o-o
       /   \
o--o--o--G--m1     <-- feature, master

如果你是“分支功能”（git checkout feature）并进行新的提交，那么标签master将指向m1，feature指向在你的“新的最新”承诺：

        o-o
       /   \
o--o--o--G--m1     <-- master
              \
               o   <-- feature

我在下面放了feature来强调“{1}}上的”顶部“o-o行不明显。

请注意，此图表与此替代图形相同，看起来有点像蜗牛：

feature

哪种提示o-o o <-- feature / \ / o--o--o--G--m1 <-- master 可能已出现在功能上;但与此绘图非常不同，后者包括o-o：

m2

这清楚地表明o-o----m2--o <-- feature / \ / o--o--o--G--m1 <-- master有一个不间断的血统可以追溯到前面的feature。这基本上是“与o-o合并的其他方向”。

（你想要它吗？嗯，这取决于你，真的。像“蜗牛”这样的图形很常见，你习惯了它们并且知道哪个分支标签在过去一段时间的某些提交序列通常不是很有用。但有时它很有用，然后你想要看起来更像帐篷和几何东西的图形，而不是蜗牛。:-)）

在git中与master合并后，功能分支会发生什么

1 个答案: