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.
Edit:
There are changes in the master as this is a team project.
Just check out the
masterand mergeBranchBinto it, this merges all changes into master asBranchBcontains all changes fromBranchA.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-ffthat creates a new commit telling explicitly that the branch hand been merged.Depending on what you want to "tell" with the history, you can also merge first merge
BranchAfirst and thenBranchB.in all three cases, the resulting code of the merge is the same, just the history is different.