blocks|key|1599683|text|既没有任何实际的成本，也没有任何实际的好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1599684|请记住，分支名称很大程度上是ephemeral，并且在任何情况下都会随着时间的推移而演变。如果您保留这两个名称很长时间-名为master的名称，您可能会保留-然后在未来的某个时候，您将看到这种提交模式：|offset|length|style|CODE|1599685|(time+increasing+towards+the+right)

o--o---------M-----N+++<--+master
++++\+++++++/+++++/
+++++o--o--o--o--o+++<--+dev|code-block|syntax|javascript|1599686|对于第一种情况，您在某个时间T使用git+merge+--no-ff+dev到master中以创建合并M，然后在稍后的某个时间再次使用git+merge以创建合并N。|1599687|(OP+notes+that+this+first+pattern+might+be+something+desirable+in+a+release+branch,+e.g.,+one+named+production+where+the+name+on+the+lower+row+is+master.)|1599688|如果您允许dev在M重新加入master，您将得到：|1599689|o--o---------M------N+++<--+master
++++\+++++++/+\++++/
+++++o--o--o+++o--o+++<--+dev|1599690|这样好点了吗？是不是更糟？你会在意吗？|1599691|如果去掉dev名称，转而使用feature名称，您可能会看到：|1599692|o--o---------M------N+++<--+master
++++\+++++++/+\++++/
+++++o--o--o+++o--o|1599693|其中，沿着底行的第一个气泡是临时名称feature/foo，第二个气泡是临时名称feature/zorg。|1599694|同样，真正的问题是:你关心吗？这里唯一永久的东西就是提交本身。使提交消息更好-默认的merge+...消息有点可怕，但至少是这样的：|1599695|merge+branch+feature/foo|1599696|和：|1599697|merge+branch+feature/zorg|1599698|提供一些关于这是关于什么的线索。请比较：|1599699|merge+branch+dev|1599700|这根本不会告诉你任何事情，不管你在提交中观察到的是哪种针脚模式。|1599701|entityMap|0|LINK|mutability|MUTABLE|url|https://www.merriam-webster.com/dictionary/ephemeral|1|https://stackoverflow.com/questions/56657893/should-i-fast-forward-a-branch-after-merged-to-a-different-branch/56657987?noredirect=1#comment99886892_56657987^0|0|1Q|6|E|9|0|0|0|H|H|Z|3|13|6|1F|1|1V|9|29|1|0|2S|A|42|6|0|4A|1|0|5|3|9|1|E|6|0|0|0|4|3|E|7|0|0|I|B|14|C|0|16|9|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1R|8|@$D|1S|E|1T|F|G]]|9|@$D|1U|E|1V|1|1W]]|A|$]]|$1|H|3|I|5|J|7|1X|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1Y|8|@$D|1Z|E|20|F|G]|$D|21|E|22|F|G]|$D|23|E|24|F|G]|$D|25|E|26|F|G]|$D|27|E|28|F|G]|$D|29|E|2A|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|2B|8|@$D|2C|E|2D|F|G]|$D|2E|E|2F|F|G]]|9|@$D|2G|E|2H|1|2I]]|A|$]]|$1|Q|3|R|5|6|7|2J|8|@$D|2K|E|2L|F|G]|$D|2M|E|2N|F|G]|$D|2O|E|2P|F|G]]|9|@]|A|$]]|$1|S|3|T|5|J|7|2Q|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|2R|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2S|8|@$D|2T|E|2U|F|G]|$D|2V|E|2W|F|G]]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|2X|8|@]|9|@]|A|$K|L]]|$1|10|3|11|5|6|7|2Y|8|@$D|2Z|E|30|F|G]|$D|31|E|32|F|G]]|9|@]|A|$]]|$1|12|3|13|5|6|7|33|8|@$D|34|E|35|F|G]]|9|@]|A|$]]|$1|14|3|15|5|J|7|36|8|@]|9|@]|A|$K|L]]|$1|16|3|17|5|6|7|37|8|@]|9|@]|A|$]]|$1|18|3|19|5|J|7|38|8|@]|9|@]|A|$K|L]]|$1|1A|3|1B|5|6|7|39|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|J|7|3A|8|@]|9|@]|A|$K|L]]|$1|1E|3|1F|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]]|1H|$1I|$5|1J|1K|1L|A|$1M|1N]]|1O|$5|1J|1K|1L|A|$1M|1P]]]]

There is neither any real cost, nor any real benefit.

Remember that branch names are largely <a href="https://www.merriam-webster.com/dictionary/ephemeral" rel="nofollow noreferrer">ephemeral</a>, and in any case certainly evolve over time. If you keep both names around for a long time—the one named <code>master</code>, you'll probably keep—then at some time in the future, you would see this pattern of commits:

<pre><code>(time increasing towards the right)

o--o---------M-----N &lt;-- master
 \ / /
 o--o--o--o--o &lt;-- dev
</code></pre>

for the first case, where you <code>git merge --no-ff</code> <code>dev</code> into <code>master</code> to create merge <code>M</code> at some time T, and then <code>git merge</code> again to create merge <code>N</code> at some later time.

<a href="https://stackoverflow.com/questions/56657893/should-i-fast-forward-a-branch-after-merged-to-a-different-branch/56657987?noredirect=1#comment99886892_56657987">(OP notes that this first pattern might be something desirable in a release branch, e.g., one named <code>production</code> where the name on the lower row is <code>master</code>.)</a>

If you allow <code>dev</code> to rejoin <code>master</code> at <code>M</code>, you will instead get:

<pre><code>o--o---------M------N &lt;-- master
 \ / \ /
 o--o--o o--o &lt;-- dev
</code></pre>

Is this better? Is it worse? Will you care?

If you take away the <code>dev</code> name, and instead use <code>feature</code> names, you might see:

<pre><code>o--o---------M------N &lt;-- master
 \ / \ /
 o--o--o o--o
</code></pre>

where the first bubble along the bottom row was temporary name <code>feature/foo</code> and the second bubble was temporary name <code>feature/zorg</code>.

Again, the real question will be: do you care? The only things that are permanent here are the commits themselves. Make the commit messages good—the default <code>merge ...</code> messages are kind of terrible, but at least something like:

<pre><code>merge branch feature/foo
</code></pre>

and:

<pre><code>merge branch feature/zorg
</code></pre>

offer some clue as to what this was about. Compare with:

<pre><code>merge branch dev
</code></pre>

which tells you nothing at all, regardless of which stitch pattern you observe in the commits.

Given that I have two branches <code>dev</code> and <code>master</code>

I do most of development on <code>dev</code> and then make a merge to <code>master</code> with <code>--no-ff</code>.

Because I used <code>--no-ff</code>, there is a new commit created on <code>master</code> (Let's call this commit A). 

Should I fast-forward commit A onto my <code>dev</code> branch before I continue to develop on <code>dev</code>?

Is there any benefit of bringing commit A onto my <code>dev</code>? Would it be an anti-pattern to bring this commit A onto <code>dev</code> branch?

Should I fast-forward a branch after merged to a different branch

我在dev上做了大部分开发，然后用--no-ff合并到master。因为我使用了--no-ff，所以在master上创建了一个新的提交(让我们称之为提交A)。在继续在dev上开发之前，我应该在dev分支上快进提交A吗将commit A引入我的dev有什么好处吗？将这个提交A带到dev分支上会不会是反模式？

问合并到不同的分支后，我是否应该快进一个分支
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问合并到不同的分支后，我是否应该快进一个分支EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问合并到不同的分支后，我是否应该快进一个分支
EN