I effectively have this:
a -- b -- c <-- Master
\
d -- e <-- BranchA
\
f -- g -- H -- i <-- BranchB
What I want is to integrate my changes from BranchA and BranchB into Master. I normally like to rebase, but I don't think it's a good idea as my changes are in public repos, and in particular, commit H is someone else's work.
So if I am right in my assumption that a merge is easier, I am wondering, do I need to merge Master into BranchA, then merge BranchA into BranchB, before merging BranchB back into Master, or can I save some time and just merge Master into BranchB, then merge it all back in? I understand this will leave a messy commit history, hence my previous paragraph.
There are changes in the master as this is a team project.
Just check out the master
and merge BranchB
into it, this merges all changes into master as BranchB
contains all changes from BranchA
.
a -- b -- c
\
d -- e <-- BranchA
\
f -- g -- H -- i <-- Master, BranchB
Since this will lead to a fast forward merge, if there are no changes on the master
, you might want to consider the option --no-ff
that creates a new commit telling explicitly that the branch hand been merged.
a -- b -- c -------------------------- j <-- Master
\ /
d -- e / <-- BranchA
\ /
f -- g -- H -- i <-- BranchB
Depending on what you want to "tell" with the history, you can also merge first merge BranchA
first and then BranchB
.
a -- b -- c -------j------------------ k <-- Master
\ / /
d -- e / <-- BranchA
\ /
f -- g -- H -- i <-- BranchB
in all three cases, the resulting code of the merge is the same, just the history is different.