Git：您的分支领先于 'upstream/master' 2 次提交

Question

I have seen something like: Your branch is ahead of 'origin/master' by 2 commits . But this time I am getting upstream/master instead of origin/master . Not able to get why?

abc@xyz MINGW64 /d/new (master)
$ git status
On branch master
Your branch is ahead of 'upstream/master' by 2 commits.
  (use "git push" to publish your local commits)

Prior to this, I had updated my master (twice) via git pull upstream master , which surprisingly created a new commit for the update. I think that these two update commits are the 2 commits that the local master is "ahead of the upstream/master". But is there any specific reason/solution to this?

Now, If I merge my master to any branch, these 2 commits also become a part of the branch and of course, occur in my PR when I push it.

I am working on Windows 7.

Answer 1

I have seen something like: Your branch is ahead of ' origin /master' by 2 commits . But this time I am getting upstream /master ... why?

You set the upstream of your branch to upstream/master . Every branch can have one upstream (or no upstream, if you like). The git status command will compare reachable commits from the branch and its upstream, counting, and tell you if your branch is ahead, behind, or diverged based on these counts.

You only get one upstream (or no upstream) setting per branch. Note that the word "upstream" here is not the same as the upstream remote , ie, the fact that some branch has some upstream is not dependent on the fact that you have a remote named upstream . (Git is very bad about using words confusingly like this.)

But is there any specific reason [for being two ahead]?

git pull means Run two Git commands: First, run git fetch . Then, run a second Git command of my choice, git merge or git rebase , using whatever you got when you ran the first Git command.

In this case, you ran git pull upstream master , so this ran:

git fetch upstream

followed by (probably, unless you changed your settings)

git merge <something>

The <something> here is a little tricky to explain, ¹ but git merge can, and in this case probably did, create a new commit.

To know exactly what happened, we would have to know:

• what was in each repository before the git fetch , which tells us
• what the git fetch did, which lets us determine
• what the git merge did.

I generally recommend that those new to Git avoid git pull and instead (1) learn what each of these commands ( git fetch , git merge , and git rebase ) does, then (2) use the commands individually and separately. This can still be confusing and a bit difficult but you have a much better chance of understanding what is going on, if you do it this way.

Note that when you do this, you have the opportunity to insert some third Git command between the two. For example, when you know how to interpret git log output, you can say: I ran fetch, now I'd like to run git log --all --decorate --oneline --graph to see what git fetch did.

(Once you know what each command does and can predict everything, then it's safe, or at least safe-ish, to use the all-in-one convenience "fetch and then merge-or-rebase" git pull . I still mostly don't: I like to run those extra git log commands, or some of them, based on what git fetch says.)

If you want to get rid of these merge commits, you can do this with git reset or with most varieties of git rebase . But maybe you should just keep these merge commits—that might be best. What to use, and when, is a matter of situation and also personal taste in some cases—there's no blanket always-right action here. Git provides a lot of individual tools with which you can build your own solutions, but for the most part, isn't a solution itself.

---

¹ git fetch leaves, in a file in your Git repository named FETCH_HEAD , some trace information. The pull command fishes this information back out and builds the git merge command from that. Given the arguments upstream and master , the effect is much the same as if you had run git merge upstream/master , but there are some minor differences.