是否分支。 <name> .merge`代表远程跟踪分支还是上游分支？

Question

Does branch.<name>.merge represent a remote tracking branch or an upstream branch?

1. Version Control with Git says

   But how did Git know to merge those particular branches? The answer comes from the configuration file:

    [branch "master"] remote = origin merge = refs/heads/master 

   Paraphrased, this gives Git two key pieces of information: When master is the current, checked out branch, use origin as the default remote from which to fetch updates during a fetch (or pull). Further, during the merge step of git pull, use refs/heads/master from the remote as the default branch to merge into this, the master branch.

   The quote says "during the merge step of git pull, use refs/heads/master from the remote as the default branch to merge into this, the master branch." It seems to me that branch.<name>.merge represents a remote tracking branch instead of an upstream branch.

   But refs/heads/master in merge = refs/heads/master doesn't look like a remote tracking branch (which should look like refs/remotes/<remote>/master ), but a topic branch, so it seems only an upstream branch to me.

2. The manpage of git config says

    branch.<name>.merge 

   Defines, together with branch..remote, the upstream branch for the given branch.

   It seems to say branch.<name>.merge represents an upstream branch instead of a remote tracking branch.

3. Is it possible that branch.<name>.merge implies both a remote tracking branch and an upstream branch? I don't think it is possible, because a remote tracking branch and its corresponding upstream branch(es) can have different basenames, according to how remote.<remote>.fetch is configured.

Answer 1

In short, branch.<name>.merge contains the name of the remote branch on the remote server: it is the upstream branch.

How to convince yourself this is true:

Assuming branch origin/dev1 exists but not the local dev1 yet, run this:

git checkout dev1
git branch -m dev1 dev2

These commands set up dev1 as having origin/dev1 as its upstream, then renames it as dev2 .

The results in my .git/config is this:

[branch "dev2"]
    remote = origin
    merge = refs/heads/dev1

Now, refs/heads/dev1 is something that does not exist anywhere in my sandbox, only on the remote.

Some further clarification of names, based on the discussion in the comments:

local branch : master or dev2 are local branches that can get updated from their upstream branch.

remote-tracking branch : origin/master or refs/remotes/origin/master is a pointer stored locally to the state of the remote branch at the time of the last git fetch or git pull .

upstream branch : this is the real remote branch, on the remote server itself, not something local.

Answer 2

git config remote.origin.fetch will show you the "refspec" that maps refnames on the origin remote to the local "remote-tracking branch" refs.

The default is

+refs/heads/*:refs/remotes/origin/*

and it says fetch all the refs on origin that start "refs/heads/" and substitute the * 'd text in the local rewrite, so refs/heads/master the * is master , and that's what gets subbed in for the * in the local ref, the "remote-tracking branch" ref ¹ .

The config file specifies which repository a branch's upstream came from and what the refname in that repository is. When you go to rebase or pull or merge and take the implicit upstream, Git looks at the branch name and the refspec for its source repo, usually origin , and figures out what ref that would map to in this repository.

So

[branch "master"]
        remote = origin
        merge = refs/heads/master

[remote "origin"]
        url = git://github.com/git/git
        fetch = +refs/heads/*:refs/remotes/origin/*

the local branch master tracks origin 's branch master , and fetching from origin maps that branch there to refs/remotes/origin/master here, so that's the history rebase and pull and probably some others examine by default to find where or whether the histories have diverged.

---

^{1 The leading + just means "don't complain if the fetch abandons history", which is of course exactly how you want fetch to operate when you're simply tracking what's going on with a remote's refs. See the fetch docs for more of its default behavior, eg there's times when you want tags fetched, times when you don't}