Git rebase 不会删除功能分支中的文件

Question

I created two branches b1 and b2 based on dev branch on a same day. Both branch have file named f1.txt .

After 1 day, I did a commit ( c1 ) deleting file f1.txt in branch b1 and pushed the changes to remote branch b1 and merged it to dev .

After 1 month I worked on a branch b2 , made a commit (c2) and did ( git pull origin/dev --rebase ). I mostly do ( git pull --rebase )

The file f1.txt is still there in branch b2 .

How can we update local branch in case of file deletion in branch b2 ?

Answer 1

First you must understand rebase completely

Rebase doesn't work with files . Rebase works with commits . Specifically, git rebase means:

• I have some commits.
• A lot of stuff about these commits is good.
• But some things about these commits is not so good.
• I know it's impossible to change an existing commit , but if you, Git, would be so kind, I'd like you to take each of these existing commits and apply them, one by one, starting somewhere I'd like, and giving me the option to stop and change the files around and/or change the commit message before you make the new copy.

That is, we take some existing series of commits:

          K--L   <-- my-feature (HEAD)
         /
...--G--H--I--J   <-- main

and, because we don't like the fact that the parent commit of K is H —these two commits are in the wrong place in the graph, in other words—we run:

git rebase main

and Git will take commits K and L and copy them to new commits. The new commits will:

• do the same thing as K and L , but
• come after J

so that we get:

          K--L   <-- my-feature
         /
...--G--H--I--J   <-- main
               \
                K'-L'  <-- new-and-improved-my-feature

Note how both branches co-exist at this point.

Now we make use of the fact that humans (though not Git) find commits by using a branch name . (Git uses hash IDs.) Commits K' and L' look a lot like K and L , and a human looking at L' will probably mistakenly think they are looking at L . ( Git won't, because L' will have a totally different random-looking hash ID.)

So now, we have Git swap the names around a bit! Then we have Git check out the new branch it built:

          K--L   <-- old-and-lousy-my-feature
         /
...--G--H--I--J   <-- main
               \
                K'-L'  <-- my-feature (HEAD)

and then delete the name on the old branch:

          K--L   [abandoned
         /
...--G--H--I--J   <-- main
               \
                K'-L'  <-- my-feature (HEAD)

We won't be able to find commits KL any more, because we use names. (Git can still find them, as long as Git can find the hash IDs. Git keeps those hash IDs around for a while, or on GitHub, forever.)

That's rebase in a nutshell, though we can get fancy using git rebase -i for instance. Here Git will put up an instruction sheet with pick commands, which we can modify to read edit or reword or whatever. This changes how Git does the copying-of-commits. Before we go any further, we should mention that the actual copying happens through git cherry-pick . ¹ The way cherry-pick "copies a commit" is, roughly speaking, to compare the commit's snapshot against the commit's parent's snapshot. Whatever changes this commit makes, those are the changes the copy will make, too.

Thus, in our example above, the change (the git diff output) you'll see if you show commit K —if you do this before rebasing, or if you save its hash ID so that you can pick it out after rebasing—will match the change that you'll see if you show commit K' after rebasing.

---

¹ This is true for all interactive git rebase operations, and for most git rebases in modern Git, but in Git before version 2.26, a lot of rebase operations used a different back-end. The result is usually the same, and you should generally think of rebase as "automated cherry-pick" anyway.

---

Next you must understand git pull completely

The pull command is basically a convenience command: it just runs two other Git commands for you. This makes it relatively easy to understand, except that to really understand it, you must understand both of the other two commands! So let's see what they are:

1. First, git pull runs git fetch .

   The git fetch command means reach out to some other Git repository and collect some commit(s) from it if and as needed . This can get complicated, so let's leave it at this for now. The new commits that git fetch picks up, if any, get recorded in a special file in the hidden .git folder: .git/FETCH_HEAD . Depending on your Git version and how you invoke git pull , this git fetch can also update things like origin/dev . But in all cases, this does not affect any of your current work .

   New commits, stuffed into your Git repository, are simply new commits. You aren't actually using any of them yet. Usually, we fetch new commits because we want to use them . So...

2. Having run git fetch , git pull runs a second Git command.

   This second command is up to you. You can choose to have Git run git merge —that's the default, if you haven't set anything else up—or you can choose to have Git run git rebase .

   The purpose of this second command is, of course, to make use of the new commits you fetched in step 1. This is where everything gets pretty tricky though.

We'll get back to git fetch in a moment as it is about to matter a lot. Let's take a look now at the information you have provided.

What you said

I created two branches b1 and b2 based on dev branch on a same day. Both branch have file named f1.txt .

This isn't quite the right description. Let's correct it.

Since Git is really about commits —not files, not branches, but commits —let's draw the situation you've described so far. You had a repository, which has some set of commits. Each commit holds a full snapshot of every file, plus some metadata (things like who made the commit and when, and the raw hash ID of the commit's parent commit). We'll draw this set of commits and the branch names, like this:

...--G--H   <-- dev, b1, b2

That is, all three branch names select some commit. Each commit has a unique hash ID—some big ugly string of letters and digits, unique to that one particular commit—and a branch name gives a way for a human to tell Git: Just get me the latest commit, whatever its hash ID is. Git does this by storing the latest commit's hash ID in the branch name. So the three branch names here, dev , b1 , and b2 all store the hash ID of commit H . Commit H stores, in its snapshot, the full set of files including file f1.txt ; commit H stores, in its metadata, the hash ID of earlier (parent) commit G .

Since all three branch names hold the same hash ID , all three branches select commit H . That one commit holds file f1.txt , and it will do so forever (no part of any commit can ever change).

After 1 day, I did a commit ( c1 ) deleting file f1.txt in branch b1

Let's draw commit C1 (I'll even call it C1 here):

          C1   <-- b1
         /
...--G--H   <-- dev, b2

Commit C1 has a new snapshot: in C1 's snapshot, file f1.txt doesn't exist. That's a full snapshot of every file, so when we compare the snapshot in H to the snapshot in C1 , one of the changes we see is "delete file f1.txt ".

Note that C1 does not store changes . It just stores a snapshot plus metadata. The "change" we see is a result of comparing H vs C1 , as obtained by following branch name dev or b2 to commit H , and following branch name b2 to C1 .

and pushed the changes to remote branch b1 and merged it to dev .

I presume this means: I ran git push origin b1 or I ran git push -u origin b1 . So far so good, but now, we have a bit of a problem. When you use git push , you are doing the closest thing there is to the opposite of git fetch . You have your Git call up some other Git software, that is working with a different but related Git repository—what Git calls a clone . You probably cloned your repository from theirs, but "clone-ness" is symmetric: if Fred2 is a clone of Fred1, then Fred1 is a clone of Fred2.

The thing here is that each clone has its own branches . That's why you said "remote branch b1 ": that's a branch named b1 over on origin . So now they have a b1 . Then you say and merged it to dev , but what is it here? How did you do this merge?

Given that you have your own dev and your own b1`, you might have run:

git checkout dev; git merge b1

Or, given that you tagged this whole thing with github , maybe you mean that after:

git push -u origin b1

you used a green clicky button on GitHub to cause the merge to happen in the GitHub repository over on GitHub . That is, you did the merging in their repository, without affecting your repository.

I don't know which of these might be right, but if we assume you used the button on GitHub for now, and did nothing locally, your local repository now has this:

          C1   <-- b1, origin/b1
         /
...--G--H   <-- dev, b2, origin/dev

Note that I've added the origin/ names. These are your Git's way of remembering what your Git thinks is set up in the GitHub repository over on GitHub. Your Git can only update these in certain cases. The most common case is when using git fetch , but even here it gets a bit complicated.

If you did the merge in your repository , though, here's what you'll have, assuming you allow git merge to do a fast-forward (which is its default):

          C1   <-- b1, dev, origin/b1
         /
...--G--H   <-- b2, origin/dev

Let's return to your own commands, as you've described them:

After 1 month I worked on a branch b2 ,

If we start with the drawing above, without any updates to it—which is all we can do given your description at this point—then b2 still points to commit H , which still has file f1.txt in it.

made a commit ( c2 )

Presumably you did not touch f1.txt in this commit, so it has the same f1.txt in the new commit:

          C1   <-- b1, [dev?], origin/b1
         /
...--G--H   <-- [dev?], origin/dev
         \
          C2   <-- b2

Note that I don't know which commit your dev selects, nor whether their (origin's) dev still selects commit H or not.

and did ( git pull origin/dev --rebase ).

We now have to get into some of the gory details of git fetch . When you run git pull , with or without the --rebase option, git pull passes most of your arguments on to git fetch . The --rebase option, however, is an option to git pull to tell it which second command to run , so it does not pass that one on to git fetch .

Let's add this to the mix too:

I mostly do ( git pull --rebase )

So one of these two will run:

git fetch origin/dev

and one of these will run:

git fetch

The gory details about git fetch

When you run git fetch with no additional arguments , as in:

git fetch

(as you'd get with git pull --rebase for instance), your Git will:

1. call up the other Git over at origin , using the URL stored under the name origin ;
2. have them list out all their branch names, and for each of those branch names, find out any new names and/or commits they have that you don't;
3. bring over, and stuff into your repository, all of those new-to-you names and commits;
4. update all your origin/* names based on what got brought over in step 3.

Any branch names they deleted won't show up in step 2, so won't be updated in step 3, so your Git won't delete the corresponding origin/ name in your own repository. That is, supposed they had a branch temporary , and you ran git fetch . You'd get an origin/temporary at this time. Later, they delete their temporary . You run git fetch , and your Git sees no temporary . But this just means your Git doesn't update your origin/temporary . So it sticks around from earlier, even though there's no point to its existence any more. Usually this doesn't matter much, it just means that "stale" names accumulate. ²

So git fetch by itself means get everything and update all my remote-tracking names, then stop there . That's pretty often exactly what I want , so it's what I normally use—I almost never use git pull at all myself. I like to see what got updated, see the new branch names if there are any, and maybe take a look at new commits that came in.

But, if you like git pull , remember that git pull origin dev means run git fetch origin dev . Remember that git pull origin/dev means *run git fetch origin/dev .

The latter doesn't work! You said that's what you ran, and if that's what you ran, that would explain why it didn't work. The first non-option word after git fetch is the name of the remote . The only remote you have is (probably ³ ) origin . There's no origin/dev remote, and git fetch origin/dev will thus fail.

This might have been a typo and maybe you ran git pull origin dev . That would run git fetch origin dev . Running this tells your Git: call up the other Git over at origin , and list out some or all of their branch names, but I'm only really interested in the one spelled dev . They'll list their names and your Git will see if they have a dev . If so, they'll find out which commit their dev has as its most recent commit.

If that commit is new to you—ie, if they have a dev and it has new-to-your commits—your Git will bring those commits over. In any case, whether or not they have new-to-you commits, your Git will write their most-recent- dev -commit hash ID into .git/FETCH_HEAD . If your Git version is at least 1.8.2, your Git will also update your origin/dev now, but if your Git is older than that, your Git will fail to update your origin/dev .

Once your git fetch finishes, it will return "success" if:

• it was able to look up the remote;
• it was able to connect to that Git; and
• it was able to find the right hash ID, and bring over any new commits if needed.

Otherwise your git fetch tells your git pull that it failed, and your pull stops at this point. So git fetch origin/dev would fail and would stop your rebase at this point.

If that was a typo and you actually ran git pull origin dev --rebase (not git pull origin/dev --rebase ), then your git fetch probably worked (GitHub's computers are almost always up and working) and you probably got a .git/FETCH_HEAD with the right hash ID in it.

In that case , your Git will run git rebase hash-ID , using the hash ID found in .git/FETCH_HEAD . This will conduct a git rebase as shown above, using the hash ID of their dev commit.

---

² If you want to get rid of these "stale" remote-tracking names, use git fetch --prune or git remote prune origin . I usually want my Git software to do this automatically every time; to make your Git do that, use git config --global fetch.prune true . Just be aware that this makes your Git remove remote-tracking names as soon as it realizes that they are gone!

³ You will set up one remote per other-Git-repository that you need to talk to regularly. When you use git clone to make an initial clone, that sets up one remote ("the other Git repository that I cloned") and calls it origin . That's the one remote that almost everyone has in almost every repository.

---

Returning to your problem once again

The file f1.txt is still there in branch b2 .

What we need to know, now, is:

• How did you do this merge, in which repository?
• Was the git rebase you showed correct, in which case it failed, or did you show us a typo, and the one you ran was correct and the one you showed was wrong?
• If a rebase ran, what hash ID was stored in their dev ? What was in the commit(s) there?

You can run:

git fetch origin
git log --all --decorate --oneline --graph

to get a Git-drawn diagram of the commit graph along with both your and their names for the various commits, and that will tell us more.