Does `origin` have any special meaning_?

I’ve setup a few github repos using this documentation:

echo "# foo" >>
git init
git add
git commit -m "first commit"
git remote add origin
git push -u origin master

Does the name origin have any special meaning?

  • ignore all _notes directories with GIT
  • File keeps coming back
  • updated local but unable to push
  • How to deal with a file getting added to a wrong commit in git?
  • Why is git is rejecting my pull simply because I have a commit on my local branch?
  • How to ignore to level directory in Git but not other directories starting with same name?
  • If so is it purely semantical?

  • Timestamps in Git
  • When should I use rm, git rm, git rm --cached, git add
  • Tools or utilities to check correct Javascript syntax
  • Is a format-only update a frivolous Git commit?
  • Git: unable to create symlink (File name too long)
  • Is it correct that subversion, but not git, allows empty folders?
  • One Solution collect form web for “Does `origin` have any special meaning_?”

    It is now just the default name for the cloned upstream repo.
    But it used to be a branch as well originally (up until git 1.5.0 in early 2007):

    The very first commit introducing ‘origin‘ dates from 1cadb5a (July 2005, git 0.99.2).
    It is followed by commit a692b96, which explained:

    A recommended work cycle for an “individual developer” who does not have a “public” repository is somewhat different. It goes like this:

    (1) Prepare your work repository, by “git clone” the public repository of the “project lead” (or a “subsystem maintainer”, if you work on a subsystem).
    The URL used for the initial cloning is stored in .git/branches/origin.

    (2) Do your work there. Make commits.

    (3) Run “git fetch origin” from the public repository of your upstream every once in a while. This does only the first half of “git pull” but does not merge.
    The head of the public repository is stored in .git/refs/heads/origin.

    That workflow was obviously very much tailored to the distributed development of the Linux kernel, in which you had only one upstream repo.

    The .git/branches/origin won’t become .git/remotes/origin before commit 6687f8f (Aug. 2005, git v0.99.5), when you can fetch more than one upstream repo.

    Now multi-head fetch is complete, let’s migrate the default configuration for new repositories created with the “git clone” command.

    The original $GIT_DIR/branches is not deprecated yet, but create remotes directory by default from the templates as well.

    Then commit e125c1a (Nov. 2005, v0.99.9c) added:

    The newly cloned repository by default had .git/remotes/origin set up to track the remote master to origin, but forgot to create the origin branch ourselves.
    Also it hardcoded the assumption that the remote HEAD points at “master“, which may not always be true.

    It started to evolve to ‘origin’ as an upstream repo in commit dfeff66 (March 2006, git 1.3.0), where:

    The upstream branch heads are copied in .git/refs/remotes/ instead of .git/refs/heads/ and .git/remotes/origin file is set up to reflect this as well.
    It requires to have fetch/pull update to understand .git/refs/remotes by Eric Wong to further update the repository cloned this way.

    This is detailed in commit c72112e.

    Defaulting to ‘origin’ when fetching was introduced in commit 5e27e27 (July 2006, git 1.4.2).

    The remote origin is stored in ./git/config in commit 255cae8 (Nov. 2006, git 1.5.0)

    For example what was previously .git/remotes/origin:

      URL: proto://host/path
      Pull: refs/heads/master:refs/heads/origin

    Is now added to .git/config as:

      [remote "origin"]
      url = proto://host/path
      fetch = refs/heads/master:refs/heads/origin 

    git pull defaults to origin with commit 955289b (Dec. 2006, git 1.5.0):

    Without any specification in the .git/config file, git-pull will execute
    git-pull origin“; which in turn defaults to pull from the first “pull”
    definition for the remote, “origin“.

    The glossary is then updated:


    The default upstream repository. Most projects have at least one upstream project which they track. By default ‘origin‘ is used for that purpose.
    New upstream updates will be fetched into remote tracking branches named origin/name-of-upstream-branch, which you can see using “git branch -r“.

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