553

What is the difference between origin and upstream on GitHub?

When a git branch -a command is executed, some branches it displays have a prefix of origin (remotes/origin/..) while others have a prefix of upstream (remotes/upstream/..).

David Ferenczy Rogožan
  • 23,966
  • 9
  • 79
  • 68
jan
  • 5,901
  • 4
  • 16
  • 5
  • 4
    Related: [Definition of "downstream" and "upstream"](https://stackoverflow.com/q/2739376/465053) in git. – RBT Aug 12 '17 at 02:51

4 Answers4

1060

This should be understood in the context of GitHub forks (where you fork a GitHub repo on GitHub before cloning that fork locally).

From the GitHub page:

When a repo is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repo it was forked from.
To keep track of the original repo, you need to add another remote named upstream

git remote add upstream https://github.com/<aUser>/<aRepo.git>

(with aUser/aRepo the reference for the original creator and repository, that you have forked)

Note: since Sept. 2021, the unauthenticated git protocol (git://...) on port 9418 is no longer supported on GitHub.

You will use upstream to fetch from the original repo (in order to keep your local copy in sync with the project you want to contribute to).

git fetch upstream

(git fetch alone would fetch from origin by default, which is not what is needed here)

You will use origin to pull and push since you can contribute to your own repository.

git pull
git push

(again, without parameters, 'origin' is used by default)

You will contribute back to the upstream repo by making a pull request.

fork and upstream

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 15
    It also helps knowing what `upstream` is generally: http://stackoverflow.com/questions/2739376/definition-of-downstream-and-upstream/2749166#2749166 – VonC Mar 10 '12 at 20:59
  • It is worth mentioning in context of github it makes more sense to have origin be the master-repo and use github username as the remote name for your and other forks. Tools like defunkt.io/hub does this and makes working with repositories and collaborating across forks much more uniform. – Max Rydahl Andersen Apr 03 '13 at 06:34
  • 2
    @MaxRydahlAndersen true, but I like using Git without wrapper, so I will keep that convention (upstream vs. origin) for now. – VonC Apr 03 '13 at 06:41
  • 39
    By far the best explanation of how forks work that I have seen. You get my upvote. – CodeChimp Jul 23 '15 at 13:02
  • 14
    Great work on the visual. Very straight forward and understandable answer. This was exactly what I was looking for. – tayopi Jul 20 '16 at 17:19
  • What about a scenario for using cloud (hub/bucket/etc) as the main source, cloning the package to be hosted(elsewhere on a server). This repo on the server is the main dev downstream, possibly even the exclusive one, but dont want it limited as such. and you want the cloud to be the obvious upstream. But would you add an origin, setting it identical, or leave out an origin for this special prod repo? devs from there clone to their userspace, and their origin becomes this servers repo(prod), but the question being for the server repos origin, not the devs clone. – blamb Jul 28 '16 at 03:14
  • Oh, in my scenario, the cloud being the "Original" in your diagram, and the server being your "Fork" i was thinking. This way another team can possible fork onto another server, rinse and repeat if more team was needed, i.e. front back split, or whatever reason. So, can the fork have no origin, or does it need to be set (for convenience) same as the upstream, in that case, or better suggestion? . – blamb Jul 28 '16 at 03:23
  • @BrianThomas "So, can the fork have no origin": it is best if the fork as for origin the original repo, in order to remember for which repo this fork is coming from. – VonC Jul 28 '16 at 06:00
  • @VonC Not sure how that could be mixed up assuming you have the upstream only, you know the origin would be that, when doing `git remote -v`, if only upstream was specified, in my case, unless your referring to other times, maybe when pushing? That is probably what i was asking, how does that impact pushing/pulling if i only have upstream, and no origin? Or could that instead be a correct(alternative) way to imply origin, by not specifying, just specify upstream?? Or, is it anti-pattern use, in favor of just double specifying, or should i just add origin and leave upstream empty for prod? – blamb Jul 29 '16 at 01:16
  • @BrianThomas At this point, it is best you ask a new question where you clearly lay out the specifics of your scenario. – VonC Jul 29 '16 at 06:39
  • @VonC - I created a repo (not forked) on Github. Is it normal to see all these (upstream as well as origin branches) since I added upstream that points to my repo itself. If I understand correctly, it points to the same repo so when I am committing to either, I am essentially writing to the same repo, isnt it? – mathakoot Aug 11 '16 at 07:05
  • 3
    @iamrudra if git remote -v shows the same url for origin and upstream, then yes, you are pushing to the same remote repo. – VonC Aug 11 '16 at 07:08
  • @VonC - Just checked it - They are indeed the same. Thanks much! – mathakoot Aug 11 '16 at 07:12
  • Does this mean that `git fetch` will get from `upstream` and `git pull` from `origin`? – Frank Meulenaar Sep 27 '17 at 18:42
  • 1
    @FrankMeulenaar By default no: fetch alone fetches from your fork (which is `origin`). But at any time, you can chose to fetch from upstream: `git fetch upstream`. – VonC Sep 27 '17 at 20:22
  • I may have missed this somehow, but does `upstream` mean anything specific or is it simply a conventional name used when working with forks in git, e.g. could you use any name instead of it? – Stig Perez Sep 08 '18 at 04:47
  • @StigPerez It is a naming convention, here to reference the original repo you forked. See also the definition of upstream (https://stackoverflow.com/a/2749166/6309). You could use another name, but upstream is the one generally considered. – VonC Sep 08 '18 at 04:59
  • So, given that, if I am the only one working on a branch (and on the repo to), I don't need to `upstream` that branch. Just work-locally -> git-add -> git-commit -> git-push, right? – glc78 Oct 20 '18 at 10:59
  • 1
    @glc Yes, that is correct. No fork needed in that case. – VonC Oct 20 '18 at 11:31
  • @VonC Thanks, I was going crazy with this upstream option. It is required when I fork comeone else repo/branch, because Git instantiates a copy of the original repo into mine. Then, with `upstream` option, I tell Git to 'link' the copy I own to the original one, so that I can `pull` changes eventually made by the original owner, right? – glc78 Oct 20 '18 at 12:46
  • @glc78 yes, tha is the general idea. – VonC Oct 20 '18 at 13:20
  • Hey @VonC, great explanation. One question on the forked workflow though... I know the local `master` branch is automatically linked to remote tracking branch `origin/master` because of the clone from origin after the fork. But wouldn't it make more sense that the local `master` branch track `upstream/master` since one would often do a fetch to sync the two? I don't think there would often be a need to keep local `master` in sync with updates from `origin/master`. Plus then the command `git branch -vv` would show how many commits the local `master` is behind from `upstream/commit`. – joeglin2000 Nov 18 '21 at 17:38
  • @joeglin2000 I agree, but the issue is with Git: the tool `git` has no idea that what it is cloning is a fork ("fork" is a GitHub feature). As such, it only set the upstream branch of `main` to `origin/main`, without knowing there could be an upstream original repository worth referencing. – VonC Nov 18 '21 at 21:22
  • Fantastic answer. Nit: apparently as of late something changed and `git://github.com//` should be changed to `https://github.com//`? At least the former did not work for me but the latter did. – mreferre May 02 '22 at 14:00
  • @mreferre Thank you for the feedback, and yes, `git://` is no longer supported. I have edited the answer accordingly, with a link illustrating why `git://` is no longer there. – VonC May 02 '22 at 14:06
60

In a nutshell answer.

  • origin: the fork
  • upstream: the forked
TUSqasi
  • 750
  • 6
  • 13
4

after cloning a fork you have to explicitly add a remote upstream, with git add remote "the original repo you forked from". This becomes your upstream, you mostly fetch and merge from your upstream. Any other business such as pushing from your local to upstream should be done using pull request.

Jude Ukana
  • 121
  • 7
  • can't do pull request from local, local first has to be uploaded to repository/remote.. – oOo Dec 01 '20 at 23:41
  • N/B - The pull request mentioned in my comment above implies to making a contribution from your forked version on your git to the original repo(in this case the upstream of your local) – Jude Ukana Dec 06 '20 at 18:12
  • I created a repo on github, cloned it to my local, then created a branch(locally), made some changes to code, when I tried to push to remote from the branch newly created, it says `fatal: The current branch branchName has no upstream branch. push the current branch and set the remote as upstream,` like - `git push --set-upstream origin branchName`. There is nothing related to fork here, so what is `upstream` here? Anyone can help? – Md.Habibur Rahman Oct 07 '21 at 10:47
  • did you try - "git push -u origin " ? – Jude Ukana Oct 08 '21 at 22:14
  • @Md.HabiburRahman if you have created a new local branch, search for the git syntax that would push your newly crated branch as well as create a new remote branch at the same time. Also to answer your comment on upstream, there is no upstream in this case because you didn't fork the repo. – Jude Ukana Nov 03 '21 at 09:25
  • so, which means, If I dont fork then there is no upstream? @JudeUkana – Md.Habibur Rahman Nov 04 '21 at 03:48
1

What is the difference between origin and upstream on GitHub?

In the context of GitHub, "origin" and "upstream" refer to two different repositories.

"Origin" typically refers to your own fork of a repository. When you fork a repository on GitHub, you create a copy of it in your own account. This copy is called a fork, and the original repository is called the upstream repository. When you clone your fork to your local machine, Git automatically sets up a remote called "origin" that points to your fork on GitHub.

"Upstream" refers to the original repository that you forked from. This is the repository that you originally copied when you created your fork. You can set up a remote called "upstream" that points to this repository, which allows you to keep your fork up to date with any changes that are made to the upstream repository.

"origin" refers to your own fork of a repository, while "upstream" refers to the original repository that you forked from.

Let's say you want to contribute to an open-source project on GitHub called "example-project" that is owned by another user. To contribute to this project, you would typically fork the repository to your own account, clone it to your local machine, make changes, and then submit a pull request to the original repository.

Here's how the "origin" and "upstream" repositories come into play:

  1. Fork the repository: You go to the "example-project" repository on GitHub and click the "Fork" button. This creates a copy of the repository in your own account, which is now called "your-username/example-project".

  2. Clone the repository: You clone your fork of the repository to your local machine using the git clone command. This sets up a local copy of the repository on your machine.

  3. Set up "origin" remote: When you clone your fork, Git automatically sets up a remote called "origin" that points to your fork on GitHub. This allows you to push changes to your fork using the git push command.

  4. Set up "upstream" remote: To keep your fork up to date with any changes that are made to the original repository, you can set up a remote called "upstream" that points to the original repository. You can do this using the git remote add command. For example:

    git remote add upstream https://github.com/original-user/example-project.git

This sets up a remote called "upstream" that points to the original repository.

  1. Fetch changes from "upstream": To get any changes that have been made to the original repository, you can run the git fetch command with the "upstream" remote. For example:

    git fetch upstream

This fetches any changes that have been made to the original repository.

  1. Merge changes into your fork: Once you've fetched changes from the original repository, you can merge them into your fork using the git merge command. For example:

    git merge upstream/main

This merges any changes that have been made to the "main" branch of the original repository into your local copy of the repository.

  1. Push changes to "origin": Once you've made changes to your local copy of the repository, you can push them to your fork on GitHub using the git push command. For example:

    git push origin main

This pushes any changes that you've made to the "main" branch of your fork to your fork on GitHub.

  1. Submit a pull request: Once you've pushed your changes to your fork, you can submit a pull request to the original repository. This allows the owner of the original repository to review and merge your changes into their repository.

In summary, "origin" refers to your own fork of the repository, while "upstream" refers to the original repository that you forked from. By setting up "upstream" as a remote, you can keep your fork up to date with any changes that are made to the original repository.

JustAG33K
  • 1,403
  • 3
  • 13
  • 28