this depends on your workflow. In the workflow of one of my projects we
would rebase branch1, test and fast-forward merge it to master. Then rebase
branch2 to the new master, test, ff-merge, etc.
On GitHub this would probably mean 4 subsequent merging.
On some other project it may be an octopus merge.
If you ask what is the easiest way, personally I'd go with 4 subsequent
merges. This may result in more merge conflicts, but they would be probably
easier to resolve.
Or, if these are features made by other people, ask the first one to
rebase, they you can ff-merge, then ask the second one to rebase, etc. so
you don't have to resolve conflicts at all :)
On 31 Aug 2015 04:02, "Michael" <keybou...@gmail.com> wrote:
> Lets say I have 4 branches off master. I have tested, and found that they
> are all ready to go. What's the best way to merge them in?
> Is it:
> 1. A single merge onto master of all 4 branches at once.
> 2. One-by-one merging from the commit where they branched off, in order of
> oldest branch first.
> 3. Re-basing each of them to the current head of master, and then merging,
> one at a time.
> 4. Something else?
> Entertaining minecraft videos
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.