0

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.

SwissCodeMen
  • 4,222
  • 8
  • 24
  • 34
Chucky
  • 1,701
  • 7
  • 28
  • 62
  • If there are additional commits in `master` past commit `c`, it would be helpful to include them in the diagram. – torek Mar 08 '21 at 21:41

2 Answers2

3

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.

Jens Baitinger
  • 2,230
  • 14
  • 34
  • 1
    See my edit, there are changes on the master. Sorry, I should have been more clear. – Chucky Mar 08 '21 at 15:13
  • In that case only the last two options are possible. still i would always use the `-no-ff` option, and additionally merge the brances as often as possible, so if feature A is finished, merge it into master. When that happened, you can rebase the branch B onto that result. It is not a good practice when multple persons work in the same branch, consider everyone working on their own branch, which makes also the merges (and potential conflicts) smaller – Jens Baitinger Mar 08 '21 at 15:19
0

This mostly depends on your workflow between and the other maintainers.

To achieve your goal, yes, you can simply merge branches A and B into master one after the other.

Unless... you are following some form of git flow where your BranchA is your release branch and you need it to merge both into master and BranchB, but given your diagram and question, I am assuming that's not the exact convention you are following.

mnestorov
  • 4,116
  • 2
  • 14
  • 24