What is the difference between origin and upstream on GitHub?

Asked 13/2, 2012 at 8:35 Answered 19/8, 2022 at 20:7

562

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/..).

Quintet answered 13/2, 2012 at 8:35 Comment(1)

Related: Definition of "downstream" and "upstream" in git. – Compressive 12/8, 2017 at 2:51

1074

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

upstream generally refers to the original repo that you have forked
(see also "Definition of “downstream” and “upstream”" for more on upstream term)
origin is your fork: your own repo on GitHub, clone of the original repo of GitHub

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

Wurst answered 13/2, 2012 at 9:10 Comment(23)

It also helps knowing what upstream is generally: stackoverflow.com/questions/2739376/… – Wurst 10/3, 2012 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. – Whichever 3/4, 2013 at 6:34

@MaxRydahlAndersen true, but I like using Git without wrapper, so I will keep that convention (upstream vs. origin) for now. – Wurst 3/4, 2013 at 6:41

By far the best explanation of how forks work that I have seen. You get my upvote. – Homogenetic 23/7, 2015 at 13:2

Great work on the visual. Very straight forward and understandable answer. This was exactly what I was looking for. – Subalpine 20/7, 2016 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. – Yuriyuria 28/7, 2016 at 3: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? . – Yuriyuria 28/7, 2016 at 3: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. – Wurst 28/7, 2016 at 6:0

@Wurst 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? – Yuriyuria 29/7, 2016 at 1:16

@BrianThomas At this point, it is best you ask a new question where you clearly lay out the specifics of your scenario. – Wurst 29/7, 2016 at 6:39

@Wurst - 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? – Gink 11/8, 2016 at 7:5

@iamrudra if git remote -v shows the same url for origin and upstream, then yes, you are pushing to the same remote repo. – Wurst 11/8, 2016 at 7:8

@Wurst - Just checked it - They are indeed the same. Thanks much! – Gink 11/8, 2016 at 7:12

Does this mean that git fetch will get from upstream and git pull from origin? – Calamite 27/9, 2017 at 18:42

@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. – Wurst 27/9, 2017 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? – Roose 8/9, 2018 at 4:47

@StigPerez It is a naming convention, here to reference the original repo you forked. See also the definition of upstream (https://mcmap.net/q/11895/-definition-of-quot-downstream-quot-and-quot-upstream-quot). You could use another name, but upstream is the one generally considered. – Wurst 8/9, 2018 at 4: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? – Kellum 20/10, 2018 at 10:59

@glc Yes, that is correct. No fork needed in that case. – Wurst 20/10, 2018 at 11:31

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. – Kan 18/11, 2021 at 17:38

@Kan 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. – Wurst 18/11, 2021 at 21:22

Fantastic answer. Nit: apparently as of late something changed and git://github.com/<aUser>/<aRepo.git> should be changed to https://github.com/<aUser>/<aRepo.git>? At least the former did not work for me but the latter did. – Serration 2/5, 2022 at 14:0

@Serration 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. – Wurst 2/5, 2022 at 14:6

In a nutshell answer.

origin: the fork
upstream: the forked

Umbilicate answered 13/12, 2020 at 3:34 Comment(0)

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:

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".
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.
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.
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.

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.

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.

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.

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.

Godfry answered 19/8, 2022 at 20:7 Comment(0)

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.

Bray answered 13/10, 2020 at 4:28 Comment(6)

can't do pull request from local, local first has to be uploaded to repository/remote.. – Catholicon 1/12, 2020 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) – Bray 6/12, 2020 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? – Hanseatic 7/10, 2021 at 10:47

did you try - "git push -u origin <branch>" ? – Bray 8/10, 2021 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. – Bray 3/11, 2021 at 9:25

so, which means, If I dont fork then there is no upstream? @JudeUkana – Hanseatic 4/11, 2021 at 3:48

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

What is the difference between origin and upstream on GitHub?

Recommended topics

Hot tags