如何在创建的提交上将分支合并到 master

Question

I have this senario that i created a branch A from master where the master head was on 1234 commit id

and now some developers pushed more branchs and commits into master and now the master head is on 789 commit id.

Is it possible to merging the branch A into master on the commit 1234 ?

Answer 1

Don't try to push this analogy too far (because it will break down) but that's a bit like asking if you can get your package onto the cargo ship in China now that the ship is in port in LA. You can, but you'll have to get the ship back to China first somehow.

Instead of the above klunky analogy, let's look at how Git really works. Git is all about commits, and—as you've correctly described here—these commits are numbered . The number aren't simple, sequential counting numbers, though—commit #52 is not followed by commit #53 for instance—but instead they're big, ugly, random-looking hash IDs. So I like to represent them with single uppercase letters instead:

...--G--H   <-- master

Here, the name master points to commit H . H is the latest commit that is on master . Commit H itself reaches backwards to earlier commit G , which reaches backwards to yet another earlier commit, and so on.

In your case, you created a new name also pointing to commit H and then made some new commits:

          I--J   <-- your-branch
         /
...--G--H   <-- master

Unfortunately for you, since then, someone else has added more commits to master , like this:

          I--J   <-- your-branch
         /
...--G--H
         \
          K--L   <-- master

You're now asking about using git merge .

Merging is about combining work

When we do use git merge , we do this because we'd like to combine work . That is, you started with commit H —some particular set of files, stored forever in a commit with some big ugly hash ID. You changed a file or two and made a new commit, which got some other big ugly random-looking ID that I'm calling I , and maybe changed yet another file or two (or the same file or two) and made another commit J . So between H and J , you did some work, resulting in some changes to some files.

Git can show you what you did (summarized into one big all-at-once set of changes) by comparing the snapshot in commit H —the set of files frozen for all time from which you started—to the snapshot in your latest commit, I . This will have instructions like: in file main.py , delete line 47, and add some lines after line 300 .

Git can also show you what other people did by comparing what's in the snapshot in H —note that this snapshot is shared on both branches —with what's in the latest snapshot on master , in commit K . This may have instructions like change line 7 in README.md , along with instructions like add a line at line 100 in main.py .

What git merge can do for you—or anyone—is to combine these changes . That is, if they touched README.md and you didn't, Git will keep their changes. If you touched Documentation/info.md and they didn't, Git will keep your changes. If you and they both modified main.py , Git will try to keep both sets of changes to that one file.

If Git can combine all these changes on its own, Git will make a single new commit on its own. This new commit will have, as its snapshot, all the files from the snapshot in H —the common starting point—with the combined changes applied, so that Git keeps your changes and adds theirs, or—if you prefer to look at it this way—keeps their changes and adds yours. The result is the same either way, and it looks like this:

          I--J
         /    \
...--G--H      M
         \    /
          K--L

What I've left off here is which branch holds the new commit M . There are two names — master and your-branch —and Git will only update one of these two names so that it points to new commit M . The other name will continue to point to either commit J , or to commit L (whichever one it pointed-to before).

I've also left off another detail, which sometimes does matter: since commit M has two backwards links, or parents , pointing to commits J and L both, one of these two comes first. The other one is second, although for Git, that's just "not first". The --first-parent flag, later, can sometimes be useful to pick out the "first" parent. The snapshot in M is the same, no matter how you do the merge, but the choice of first-parent depends on which branch you git switch to, and which name you give to git merge :

git switch master
git merge your-branch

gives us:

          I--J   <-- your-branch
         /    \₂
...--G--H      M   <-- master
         \    /¹
          K--L

That is, master is the name that moves to point to M , and the first parent is now L .

This is usually what most people want to do—unless, that is, they want to use git rebase .

Is it possible to merging [my branch] into master on the [shared] commit?

Not exactly, because no matter what you do, master needs to point to some commit other than H in the end.

You can "eject" commits KL , like this:

          I--J   <-- your-branch
         /
...--G--H   <-- master
         \
          K--L   [abandoned]

The problem with doing this is that commits K and L are now lost . They're not gone —they are still there in the repository—but Git finds commits by starting with branch names. The name master used to find commit L . From L , Git could work backwards to K .

Git is unable to work forwards . Git always works backwards . So once you move master back two steps, to point to H , Git can't find K any more. Even if Git could find K , that would not help to find L . So these two commits are now "abandoned". This throws away their work . That's not what merging is for: merging is useful to keep someone else's work while adding yours , or, equivalently, to keep your work while adding someone else's .

Rebasing

Without going into a lot of detail, the idea behind rebasing is that we wish to copy some set of commits to some new-and-improved commits. In this particular case, you might wish to take your IJ commits, which you think are pretty good, and "improve" them by making two new commits—which for no as-yet obvious reason, we'll call I' (I-prime) and J' —that are a whole lot like I and J .

The difference between the new and improved I' , and the original I , is in two parts:

• The new I' will link backwards not to H , but to K .
• The new I' will have, as its snapshot, not the snapshot in H modified with your changes, but rather the snapshot in K modified with your changes.

The rest of I' will be exactly the same as I , including the commit log message . Let's draw I' now:

          I--J   <-- your-branch
         /
...--G--H
         \
          K--L   <-- master
              \
               I'  <-- temporary-branch

(The underlying Git command that produces I' from I is git cherry-pick . We have to have Git do this on a temporary branch , because Git needs to be able to find all the commits, including both the old ones and the new ones being built. The rebase command hides most of this complexity, but because Git is bad at certain things, sometimes you get to see it all.)

Once Git has copied I to I' , we need to have Git copy J to J' :

          I--J   <-- your-branch
         /
...--G--H
         \
          K--L   <-- master
              \
               I'-J'  <-- temporary-branch

Once all the commits that were exclusively on your-branch are copied to the new temporary branch, we then have Git "peel the branch name" your-branch off commit J and paste it onto commit J' —the last copy Git just made—and throw out the temporary name:

          I--J   [abandoned]
         /
...--G--H
         \
          K--L   <-- master
              \
               I'-J'  <-- your-branch

Because Git finds commits by branch name, if we look at this repository now, it will seem as though we waited until commit L existed, and only then began working and producing commits IJ . We'll see commits I' and J' , not I and J , but unless we memorize the actual hash IDs—and no human ever does that —we won't notice that we're now looking at two different commits. (Git will know. Git looks at the raw hash IDs. But we will forget, because that's what humans do.)

Whether and when to rebase is up to you

Because rebase replaces the old commits with new ones (new and supposedly improved), it's not always appropriate. In particular, if you've already given your I and J commits to someone else , and they are depending on them —including their hash IDs—then saying "throw those away, use these new and improved ones instead" makes them do extra work. Sometimes that's fine. (It's OK if they've already agreed to do that, for instance.) Sometimes it's not.

If you have never given these commits to anyone else , though, they won't ever even know you did this. So for that particular case—"private" commits—it's safe to rebase, as long as you know what you're doing.

The plus to rebasing is that, in the end, the Git history "looks simpler" and people can think about it with less mental load. The minus is that it's not what really happened: if you break something during a rebase, it can be hard to debug, and it's a lie. Is it a little white lie that makes things better, or is it a big ugly lie that causes death and destruction? We don't know, and you might not know yet , until you try it out.