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

答案是：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代表提交的s之一）：

        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需要引入三个最新的提交。

这就是为什么，如果您确定from中的某个内容feature已损坏master，然后在添加merge之前“撤消”它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

但是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在下面放下强调，“顶”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”的目的。

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