Why does tracking branch create a new remote branch?

I had a git repository with a remote branch origin/master.

I needed the repository to track a branch on another remote git server m1/master. So I added the new remote server using the git remote add command.

  • ssh: connect to host bitbucket.org port 22: Connection timed out
  • Capistano deploy:update fails at git clone
  • Set up git submodule without creating commit
  • fixing the git rebase
  • git-add only whitespace changes?
  • Does git tag mainly works as a kind of alias?
  • So I performed the following command:

    $ git branch -a
    * master

    So checking out the m1 master branch

    $ git checkout -b m1-master m1/master
    Branch mht-m1 set up to track remote branch master from m1.
    Switched to a new branch 'm1-master'

    Now doing a git push

    $ git push
    Total 0 (delta 0), reused 0 (delta 0)
    To git@<m1 server>/repo.git
    * [new branch]      m1-master -> m1-master 

    Why does git push on the tracking branch m1-master create a new remote branch, instead of pushing changes to the existing remote branch that it tracks? What am I missing here?

    PS: Using git version

  • How to default to side-by-side view for diff in GitWeb?
  • Git: how to update the working directory like hg up -C in Mercurial
  • How to run Git commands on remote repository
  • Restricting rights on GitHub
  • git orphan branches with same commits
  • Git zombie branch won't go away
  • 2 Solutions collect form web for “Why does tracking branch create a new remote branch?”

    OK, first, some terminology:

    • A (regular, ordinary, local) branch is something like master.

    • A “remote branch” like origin/master is something stored in your local repository, to remember where, on the remote, the remote had its own (local) branch pointing.

      A “remote branch” gets updated when you contact the remote (typically on fetch and push). At that time, your local git finds out what branches they have, and updates these.

    • A “tracking branch” is a local branch that records two items: a “remote”, typically a name like origin, and another “merge” name. For instance, if your local branch master is a tracking branch, it may be configured with branch.master.remote = origin and branch.master.merge = master. Annoyingly, you can’t always just string these together (you have to map through remote.origin.fetch to be completely correct with this) but in general this means that your local master is “tracking” origin/master“.

    You can’t1 create a “remote branch” locally. You have to fetch or push to/from the remote. If that remote has a local branch named X, your git then records the remote’s idea of that branch, using the origin/X style name.

    So, what’s going on here? Well, you did this:

    $ git checkout -b m1-master m1/master

    That creates a local branch named m1-master. (This local branch is also a tracking branch, but that’s only partly relevant here, because of the push.default setting below.)

    Then, you did this:

    $ git push

    (with no remote name and no refspecs after push). Git uses the default remote, which turns out to be m1 because of the tracking. Next though, git uses a default refspec, based on push.default and/or other git config items.

    As of git the “default push.default” is matching. This would not create a new branch (but also won’t push anything unless there’s an m1-master there). You have it set to current, which means: “please update or create, on the remote, the current branch, using its current name.” The current branch is m1-master, so that was created.

    Change push.default to upstream to fix this:

    git config push.default upstream

    (Also, see “Warning: push.default is unset; its implicit value is changing in Git 2.0” for various other options.)

    1Well, you can do it with git update-ref or manual poking about in your .git directory. 🙂 Just, not with “normal” user commands.

    Because of the push.default configuration option Git obeys. To cite the git-config(1) manual page:


    Defines the action git push should take if no refspec is given on the command line,
    no refspec is configured in the remote, and no refspec is implied by any of the
    optionsgiven on the command line. Possible values are:

    • nothing – do not push anything.

    • matching – push all branches having the same name in both ends. This is for those
      who prepare all the branches into a publishable shape and then push them out with a
      single command. It is not appropriate for pushing into a repository shared by multiple
      users, since locally stalled branches will attempt a non-fast forward push if other
      users updated the branch.

      This is currently the default, but Git 2.0 will change the default to simple.

    • upstream – push the current branch to its upstream branch. With this, git push will update the same remote ref as the one which is merged by git pull, making push and pull symmetrical. See “branch.<name>.merge” for how to configure the upstream

    • simple – like upstream, but refuses to push if the upstream branch’s name is different
      from the local one.

      This is the safest option and is well-suited for beginners. It will become the default in Git 2.0.

    • current – push the current branch to a branch of the same name.

    The simple, current and upstream modes are for those who want to push out a single
    branch after finishing work, even when the other branches are not yet ready to be pushed
    out. If you are working with other people to push into the same shared repository, you
    would want to use one of these.

    So I’d say for some reason you have push.default set to current or upstream and so mere running git push sends to the default remote your currently checked out branch trying to update there a ref with the same name (possibly creating it).

    You could verify if this is true by running

    git config --get-all push.default

    in your repository.

    Git Baby is a git and github fan, let's start git clone.