git - 在git中与master merge 后功能分支会发生什么

Question

我对git merge感到困惑。

假设我有一个feature分支取自master，并且他们对此有分歧
他们像这样合并



现在我想知道此命令后的关系图

git checkout master
git merge new-feature

此命令后的关系图是什么

git checkout master
git merge new-feature

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

Answer 1

答案是：合并不会对feature分支造成任何影响。新的合并提交将添加到当前分支（合并完成后为master）。现有的提交不会受到影响，因为根本无法更改任何现有的提交。

顺便说一句，提交之间的箭头确实应该指向其他方向。新的提交指向旧的提交；较旧的提交永远都不能修改，至少要修改一点，因此无法向较旧的提交“添加箭头”。您只能对一个或多个较旧的提交进行一次新提交，然后再提交，该提交带有一个或多个向后箭头。 （每个指向提交的箭头，也就是说。您甚至可以不带向后箭头的情况下进行新的提交：这是新的“根提交”。不过，这是高级的东西，但并非全部在存储库中很常见。）

尽管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

编辑：让我们重新绘制最后一张图片（相同的图片，我们只是将名称m1表示为“合并＃1”，代替代表提交的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

新合并的合并基础是通过查看旧合并而得出的，因此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中：

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

但是commit f故意禁用了部分新功能。您可能需要手动修复合并（撤消在m2中的修复）（在提交m2之前，或者在f之后的单独提交中，具体取决于您的意愿），重新启用全部功能。



无论以后是否以及何时将feature重新合并到master中，您都可以选择是否将master合并到feature中。让我们假设，例如，在G中特别有一些master ood应该带入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放在下面以强调指出，“顶部” 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。这基本上就是“与--no-ff合并的其他方向”的目的。

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