如何一次将一个当前分支合并到多个后续分支？

Question

Edit: Question is NOT merging multiple branches into current branch. Something that was already answered a couple times on Stackoverflow.

I'm trying to find the best way to maintain a tutorial for a great but still changing technology ( Trailblazer ).

Following the awesome Trailblazer book , I would like to offer the TRB community the easiest followable repo.

This is the Git-branch structure I created so far:

master
  |
  + setup
    |
    + chapter-03-01
      |
      + chapter-03-02
        |
        + chapter-03-03

So my question is… Is it possible to make changes on setup and merge it to all following branches at once, and make changes for example on chapter-03-01 and merge it to successive branches at once as well?

Answer 1

I am not 100% sure, but I think the strategy that you're looking to apply would be an " Octopus Merge "

From the git documentation :

Octopus

" This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch ."

Answer 2

You can merge as many branches as you wish

git merge <b1> <b2> <b3>...

There is a nice tool which you can read about here:
https://developer.atlassian.com/blog/2015/01/git-merge-distinct-octopus-merge/

Taken form the article - you can see that there is a multiple merge of many branches

---

Git's merge command supports multiple merging strategies when used with -s flag.

There are two strategies that can merge more than two branches at a time (octopus & ours).

octopus

This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.

The default merge strategy for this: git merge b1 b2... bn , is octopus .

ours

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version.

Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.