如何创建一个将 master 中的更改和从旧 master 分支出来的另一个分支中的更改都集成在一起的分支？

Question

So I made a PR in GitHub that got merged to master. Now I have another PR that will take some time to merge and was branched off of master before the first PR was merged.

Now I want to work on a third PR but it has to be branched off the latest master and also include changes that were made in 2nd PR that I mentioned (one that will take time to merge).

I imagine I'll need to branch off of master and then rebase 2nd PR's branch on top of the new branch. Not sure if that's the right way though, or how to exactly go about doing it.

How do I integrate latest version of master and also changes from unmerged branch into a new branch?

Answer 1

How do I integrate latest version of master and also changes from unmerged branch into a new branch?

Simplest thing to do is to make a new branch off master and the merge in the 2nd PR.

$ git checkout -b 3rdPR master
$ git merge 2ndPR

After the 2nd PR is merged into master, update the 3rd PR by merging master into the 3rd PR again.

$ git checkout 3rdPR
$ git merge master

Alternatively, rebase the 3rdPR on top of master.

$ git checkout 3rdPR
$ git rebase master

This will result in a cleaner history without all the intermediate update merges.

---

The more advanced thing to do is to first rebase your 2nd PR onto master. This is a good idea regardless, it means the 2nd PR is up-to-date during review. Then you can simply branch off the 2nd PR.

You have this.

     G - H [2ndPR]
    /
A - B ----- F [master]
     \     /
      D - E

Then rebase.

$ git checkout 2ndPR
$ git rebase master

              G1 - H1 [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

(Since you already pushed 2ndPR, you will need to force push the update. Do not use --force , use git push --force-with-lease . Explanation here .)

Now make a branch off 2ndPR.

$ git checkout -b 3rdPR 2ndPR

              G1 - H1 [2ndPR][3rdPR]
             /
A - B ----- F [master]
     \     /
      D - E

And some work on 3rdPR.

                     J - K [3rdPR]
                    /
              G1 - H1 [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

If 2ndPR is updated...

                     J - K [3rdPR]
                    /
              G1 - H1 - L - M [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

...you can rebase 3rdPR on top of 2ndPR again.

$ git rebase 2ndPR
                              J1 - K1 [3rdPR]
                             /
              G1 - H1 - L - M [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

When 2ndPR is merged...

                              J1 - K1 [3rdPR]
                             /
              G1 - H1 - L - M
             /               \
A - B ----- F --------------- N [master]
     \     /
      D - E

...rebase 3rdPR onto master.

$ git rebase master
              G1 - H1 - L - M   J2 - K2 [3rdPR]
             /               \ /
A - B ----- F --------------- N [master]
     \     /
      D - E

This is more complex, but it results in a more controlled update process, more accurate QA, and a cleaner history no matter how often you update branches. It does require confidence in being able to visualize a Git repository.

Answer 2

I imagine I'll need to branch off of master and then rebase 2nd PR's branch on top of the new branch. Not sure if that's the right way though, or how to exactly go about doing it.

Rebasing it will probably take just as long as merging it, and may make things much harder if done improperly. If in doubt, don't rebase, just merge. It's easier to undo later if something goes wrong.

Basically, in your case, the way to go (IMHO) is to go to branch PR2 (the one that takes long time to merge), create a new branch called PR3 (the one you will work on now) and then checkout PR3, and then ... merge master into PR3.

Yeah. I feel your pain. It's just like merging PR2 into master. But you will have to merge PR2 to master at some point eventually. Better now than later. In most cases, the longer you delay it, the worse the conflicts become.

Also, of you need the PR3 to have changes both from PR2 and the most recent master... then you need to merge them. master to PR2/3, PR2/3 into master, it doesn't matter. Even if you rebase , it still will end up with the same conflicts. It's because you need content from both branches, and it's the content changes from one branch that conflicts with content changes from the other branch. If you want both sets of change, you have to resolve the conflicts..

The only way to "get away" from resolving conflicts would be to start PR3 off the most recent master, then manually walk through all changes from PR2 and re-apply them manually as new commits on PR3 (hence on master, since we start PR3 on master in this excercise). After doing this (meaning: copying each change to each file and pasting it in the right place, committing, taking next change, etc, etc) you will end up with PR3 having both the most-recent master and changes from PR2...

...but in fact, what you did, was doing a rebase -like thing, just manually. And you manually resolved all conflicts on the fly. So you ended up kind-of manually merging PR2->master, callin it PR3, and then NOT telling git that you merged it all and resolved all problems.

So. Seriously. I'd advise:

• create branch PR3 on PR2
• checkout PR3
• merge master into PR3 //A
• resolve conflicts //B
• commit //C
• work on PR3

and as a bonus, the result of A+B+C is a ready-to-go candidate for a PR called "finally merged PR2 into master"

(also note that in the to-do list above there's not a single update to PR2 or master. They stay untouched. If something goes wrong with A/B/C, just delete PR3 branch and start over)