如何从 master 的另一个功能分支 rebase 或合并分支

Question

So the question is this: Let's imagine I have a master , and I start developing from that state onto a branch A, but then I create a PR from branch A to master , I then start to develop something on top of branch A , because I need some changes from the that branch A , so I create Branch B .

a -- b -- c  ---- h       <-- Master
           \
           d -- e           <-- Branch A
                 \
                  f -- g     <-- Branch B

This is my current state, then for some reason, I have to make a small change in Branch A, so I proceed to create some commits, and finally merge Branch A into Master. By then I would need to rebase Branch B in order to get the latest commits from Branch A.What should I do, this would be what I imagine.

a -- b -- c  ---     -- h       <-- Master
           \          /
           d -- e -- i     <-- Branch A
                      \
                       f -- g     <-- Branch B

Answer 1

When you've added commit i to your Branch-A you end up with:

a -- b -- c ------ h       <-- Master
           \
            d -- e -- i     <-- Branch-A
             \
              f -- g     <-- Branch-B

(Remember, your original drawing includes commit h so it must be there before the merge happens.) Making the actual merge produces a new commit j :

a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i     <-- Branch-A
             \
              f -- g     <-- Branch-B

This merge is required because existing commit h must be preserved, while new commits dei become reachable from the tip of master : this requires a merge commit j whose parents are the two existing commits h and i . (If h did not exist, a fast-forward operation would be possible: that changes the resulting graph shape, so its effect ripples through the rest of this answer. Let's assume that h does exist, and/or you force a non-fast-forward merge anyway.)

At this point you now have the option of deleting the name Branch-A entirely (at any time), and also the option of copying existing commits f and g to new-and-improved commits f' and g' . That's the rebase you're asking about.

Should you rebase them? That's a harder question. But, provided everyone else agrees that original commits f and g can be abandoned in favor of the new-and-improved f' and g' , it's fine. It might also make things prettier later. If you decide not to rebase them, the question of how to do it is moot.

If you do decide to rebase them, your next question needs to be: upon which target commit? Should f' come after i , or should it come after j ? Let's draw both scenarios:

(option 1: after i)

a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i     <-- Branch-A
             \         \
              \         f' -- g'   <-- Branch-B
               \
                f -- g   [abandoned]

(option 2: after j)

                          f' -- g'   <-- Branch-B
                         /
a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i
             \
              f -- g  [abandoned]

To make option 2 happen, run:

git checkout Branch-B
git rebase Master

(I prefer to use two separate commands here, but you can spell this git rebase Master Branch-B if you like: the extra Branch-B argument makes git rebase start by running git checkout first.) Note that I've deleted the name Branch-A : we didn't need it here. You may or may not have deleted it at this point, and if not, you might delete it later.

To make option 1 happen, run:

git checkout Branch-B
git rebase Branch-A

This time we need the name Branch-A to easily find the hash ID of commit j . So if you want to make option 1 happen, and don't want to have to run git log and cut and paste hash IDs, keep the name Branch-A around at least until this point. After the rebase finishes, we don't need the name Branch-A any more and now it's safe to delete.

Technically , we didn't need it before the rebase either, because we could look up the hash ID of j any time: git log Master starts at j and shows us that, then shows us one of h or i , and eventually we see i and therefore see its hash ID. So we can find it the hard way no matter what—but if you keep the name for a little while, we don't have to do that.

Note: If you use GitHub's "rebase and merge" or "squash and merge" clicky buttons, those do not do a standard merge. Instead, they copy commits to new ones, similar to rebase. That is, they'll make new and supposedly improved copies of the commits you're trying to incorporate. In that case none of your own existing names find the correct commit hash IDs any more because all of your names still remember your original commits, with their hash IDs, not the copies / new-commits that GitHub will have made. So if you do use GitHub's fancier operations, you will have to run git fetch to get the new commits from GitHub, then use other names, or raw commit hash IDs; you should ditch, or fix up, your own branch names soon, to avoid getting confused as to which commits were the originals and which were the new, and supposedly improved, copies. (Is commit f9131d9 the original, or is it 70abf32c ? What about a31cf2a vs 0449acd ? The hash IDs look totally random and keeping them straight is... not fun.)

Answer 2

This approach is "overbranched". Just develop new features related to branch A inside it. Don't create branch B. If new features goes to master - commit branch A and merge to master.