When we start working with GitHub, especially with forks and pull requests, we quickly come across two important terms:
- origin
- upstream
These words appear in commands, tutorials, and GitHub workflows — but Git itself doesn’t explain what they mean. Understanding them clearly will make our Git and GitHub experience far easier.
In this post, we’ll break down these terms in the simplest way possible, using real examples and diagrams we can visualize.
1. What Is a Remote in Git? (Quick Foundation)
Before we understand origin and upstream, we need to know one thing: A remote is a link to a repository stored somewhere else (usually on GitHub).
When we clone a project, Git automatically creates a remote reference for us.
We can see our remotes using:
git remote -v2. What Is “origin”? (Our Fork or Main Remote)
origin is the default name Git gives to the remote we cloned from.
Examples:
If we clone our own repository:
- origin = our GitHub repo
If we fork someone else’s repository and clone our fork:
- origin = our fork
- origin/main = the main branch of our fork
In simple terms:
origin is “our copy of the repo on GitHub.”
This is where we normally push our work.
3. What Is “upstream”? (The Original Repository We Forked From)
When we fork a repository, we create a copy under our GitHub account.
But the original repository still exists — and it keeps receiving updates.
We add a remote pointing to that original repository and call it:
upstream
Example:
git remote add upstream https://github.com/original-owner/project.git
Now we have:
- origin → our fork
- upstream → the original project
We use upstream to pull updates from the original repo so our fork stays current.
In simple terms:
upstream is “the source project we forked from.”
4. Why Do These Terms Matter?
Because GitHub contributions follow this flow:
upstream (original repo) → origin (our fork) → our local machine
And when we send changes:
our local branch → origin branch → pull request → upstream
This relationship is essential for:
- contributing to open-source
- working with forks
- keeping our fork updated
- avoiding merge conflicts
- submitting clean pull requests
Once we understand origin and upstream, the entire GitHub workflow makes sense.
5. Simple Real-World Example
Imagine we want to contribute to a public project called cool-app.
Step 1: We fork it
A copy appears in our GitHub account.
Step 2: We clone our fork
git clone https://github.com/our-username/cool-app.git
Now:
- origin = our fork
Step 3: We add the original repo as upstream
git remote add upstream https://github.com/original-owner/cool-app.git
Now:
- upstream = original repo*
Step 4: Keep our fork updated
git fetch upstream
git merge upstream/main
Now our fork is synced with the real project.
6. Comparing “origin” vs “upstream”
Here’s the simplest way to remember:
| Concept | origin | upstream |
|---|---|---|
| Belongs to | Us | Original project |
| Used for | Pushing our changes | Pulling latest updates |
| Created when | We clone | We add it manually |
| Typical URL | our-username/repo | original-owner/repo |
| Role | Our working copy | Source of truth |
⚡ Quick memory trick
origin = us
upstream = them
That’s it!
7. Does Git Require These Names?
No.
These are conventions, not rules.
We could name them:
myforkinstead of originmainrepoinstead of upstream
But almost every GitHub tutorial, open-source repository, and DevOps team uses origin and upstream, so it’s best to follow the standard.
9. Other Related Git & GitHub Terms You Will See
When working with origin and upstream, several other Git and GitHub terms often appear in pull requests, branch workflows, and remote setup. Here is a clear explanation of each one.
a. Remote
A named link to a repository stored somewhere else (usually on GitHub).
Examples:
originupstream
b. Head (HEAD)
The branch or commit we are currently working on.
In Pull Requests:
- head branch = branch containing our new changes.
c. Base
The branch we want to merge changes into.
In PRs:
- base branch = the target branch (often
main).
So PRs always compare:
head → base
d. Tracking Branch
A local branch linked to a remote branch so Git knows where to pull from or push to.
Example:
dev (local) ↔ origin/dev (remote)
e. Remote-Tracking Branch
Git’s record of the branch on the remote.
Examples:
origin/mainupstream/main
These are not actual branches—just references.
f. Downstream
The repo or branch that receives changes.
Examples:
- Our fork is downstream of the original project.
- Contributors are downstream from maintainers.
g. Fork vs Clone
- Fork → copy on GitHub
- Clone → copy on our local machine
Fork is for collaboration, clone is for development.
h. Upstream Branch (Git Concept — Different from GitHub’s Upstream Remote)
This is where most beginners get confused.
In Git (not GitHub):
An upstream branch is the remote branch that our local branch is tracking.
Example:
If our local main tracks origin/main, then:
- Upstream branch =
origin/main
This is what Git refers to when it prints:
Your branch is ahead of its upstream branch by 2 commits.
Important:
This has nothing to do with GitHub’s “upstream” remote.
- GitHub upstream remote → the original project we forked
- Git upstream branch → the remote branch our local branch tracks
Two completely different ideas that share the same word.
10. Quick Reference Table
| Term | Meaning | Example |
|---|---|---|
| origin | Our GitHub repo (fork or main) | origin/main |
| upstream (GitHub) | Original repo we forked from | upstream/main |
| remote | A named link to a repo | origin, upstream |
| HEAD | Branch we’re on | HEAD → main |
| head branch (PR) | Branch with new changes | feature/login |
| base branch (PR) | Branch receiving changes | main |
| tracking branch | Local branch linked to remote | dev ↔ origin/dev |
| remote-tracking branch | Git’s record of remote branch | origin/main |
| upstream branch (Git) | Remote branch our local branch tracks | origin/main |
| downstream | Repo receiving updates | our fork |
| fork | Copy of repo on GitHub | user/project |
| clone | Local working copy | on our machine |
9. Summary
- origin is our fork or the repository we cloned
- upstream is the original repository we forked from
- We push to origin
- We pull updates from upstream
- This setup is essential for open-source and team collaboration
Once we understand these two terms, working with GitHub becomes much easier — especially when dealing with forks and pull requests.