Skip to main content

Return to Answer

"The top answer" is a fleeting status. Link to a specific answer instead.
Source Link
isherwood
isherwood
  • 61.4k
  • 16
  • 122
  • 173

The top answer is great.

I would just add, that it becomes easy to understand if you think about remotes as locations other than your computer that you may want to move your code to.

The top answer is great.

I would just add, that it becomes easy to understand if you think about remotes as locations other than your computer that you may want to move your code to.

I would just add, that it becomes easy to understand if you think about remotes as locations other than your computer that you may want to move your code to.

added 121 characters in body
Source Link
stevec
stevec
  • 55.2k
  • 51
  • 314
  • 436

In the example above, we can see the 3 remotes with git remote:

git remote   
heroku
origin
staging

In the example above, we can see the 3 remotes with git remote:

git remote   
heroku
origin
staging
Source Link
stevec
stevec
  • 55.2k
  • 51
  • 314
  • 436

The top answer is great.

I would just add, that it becomes easy to understand if you think about remotes as locations other than your computer that you may want to move your code to.

Some very good examples are:

  • GitHub
  • A server to host your app

So you can certainly have multiple remotes. A very common pattern is to use GitHub to store your code, and a server to host your application (if it's a web application). Then you would have 2 remotes (possibly more if you have other environments).

Try opening your git config by typing git config -e

Note: press escape, then :, then q then enter to quit out

Example

Here's what you might see in your git configs if you had 3 remotes. In this example, 1 remote (called 'origin') is GitHub, another remote (called 'staging') is a staging server, and the third (called 'heroku') is a production server.

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = https://github.com/username/reponame.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[remote "heroku"]
        url = https://git.heroku.com/appname.git
        fetch = +refs/heads/*:refs/remotes/heroku/*
[remote "staging"]
        url = https://git.heroku.com/warm-bedlands-98000.git
        fetch = +refs/heads/*:refs/remotes/staging/*

The three lines starting with [remote ... show us the remotes we can push to.

Running git push origin will push to the url for '[remote "origin"]', i.e. to GitHub

But similarly, we could push to another remote, say, '[remote "staging"]', with git push staging, then it would push to https://git.heroku.com/warm-bedlands-98000.git.

Summary or origin

Remotes are simply places on the internet that you may have a reason to send your code to. GitHub is an obvious place, as are servers that host your app, and you may have other locations too. git push origin simply means it will push to 'origin', which is the name GitHub chooses to default to.

As for branchname

branchname is simply what you're pushing to the remote. According the git push help docs, the branchname argument is technically a refspec, which, for practical purposes, is the branch you want to push.

  • Read more in the docs for git push by running: git push --help