Understanding the distinction between origin and upstream remotes in Git repositories

Other Questions Github
1

I’m currently working on a forked repository, and I’m a bit puzzled by the naming conventions for remote repositories. When I use git remote -v or look at my list of branches, I see two distinct remote names that seem to have different roles.

Could someone clarify how origin differs from upstream in Git projects? I’ve noticed that when I run git branch -r, some branches show up as remotes/origin/main, while others list as remotes/upstream/develop.

I’m particularly eager to grasp the following:

  • Which remote should I use to push my updates?
  • How do these remotes connect to the original repository and my fork?
  • When is it appropriate to fetch from each remote?

Here’s the output from my current configuration:

$ git remote -v
origin    https://github.com/myusername/project-fork.git (fetch)
origin    https://github.com/myusername/project-fork.git (push)
upstream  https://github.com/originalowner/project-fork.git (fetch)
upstream  https://github.com/originalowner/project-fork.git (push)

Any insights into how to properly work with these two remotes would greatly enhance my Git experience.

2

Your remote setup looks right - origin for your fork, upstream for the original repo. These serve different purposes in your workflow. Always push to origin since that’s your fork where you’ve got write access. Pushing to upstream will fail unless you’re a maintainer. I’d pull from upstream before starting new features so you’re working with the latest code. This avoids merge conflicts when you submit PRs. After fetching upstream changes and merging locally, push those updated branches to origin. Keeps your history clean and makes reviews easier.

3

here’s how i think about it - origin is ur personal notebook, upstream is the teacher’s master textbook. u write notes in ur copy (push to origin) and check the teacher’s book for updates (fetch from upstream). u can’t write in the teacher’s book unless ur the teacher!

4

In your fork workflow, origin is your personal fork on GitHub and upstream is the original repo you forked from. This matters when you’re maintaining your fork. Always push to origin since you’ve got write access to your own fork. You can’t push to upstream unless you maintain the original project. For fetching, I regularly pull from upstream to keep my fork synced with the latest changes from the original project. Keeps it from going stale. Fetch from origin when you want changes you pushed from another machine or when working with others on your fork. My typical workflow: fetch upstream changes, merge them into my local branch, then push the updated branch to origin. This way your contributions build on the most recent upstream version.

5

Yeah, this trips up everyone when they start with forks. Here’s the deal: origin is your personal copy, upstream is the original repo you forked from. The names are just convention - you could call them whatever, but these make sense for teamwork. When you cloned your fork, Git auto-created origin pointing to your copy. Someone probably added upstream manually later to track the original. Most of the time you’ll push branches and PRs to origin. But you need upstream when the original project gets updates you want. I pull from upstream weekly to stay current, merge locally, then push the updated stuff back to origin. Keeps your fork from getting way behind the main project.

6

totally get where u are coming from! origin is your fork, that’s where you push. upstream is the original repo. fetch from upstream whenever you wanna sync up with the latest changes. easy peasy!

7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.