Skip to content

Understanding Git Origin

You clone a repo. You type git push origin main. You see origin everywhere. What is it?

It's just a name. A shortcut. A reference to the remote repository on GitHub or GitLab or wherever your code lives.

What Origin Is

When you clone a repository, Git automatically creates a remote called origin. It points to the URL you cloned from.

Think of it as a bookmark. Instead of typing the full URL every time, you just say origin.

flowchart LR
    A[Your Computer] -->|origin points to| B[GitHub Repository]

    style A fill:#e8f5e9
    style B fill:#e1f5ff

That's it. origin is just a name for the remote location of your code.

The Basic Commands

This is what you'll use every day:

# Check what origin points to
git remote -v

Output:

origin  https://github.com/username/repo.git (fetch)
origin  https://github.com/username/repo.git (push)

Two lines. One for fetching. One for pushing. Both point to the same place.

Common operations:

# Fetch from origin
git fetch origin

# Pull from origin's main branch
git pull origin main

# Push to origin's main branch
git push origin main

You're using origin instead of typing the full URL. That's all it is.

How Origin Gets Created

You clone a repo:

git clone https://github.com/username/repo.git

Git automatically does this behind the scenes:

git remote add origin https://github.com/username/repo.git

You didn't have to set it up. Git did it for you.

Check it:

git remote -v

There it is. origin pointing to your repo.

Is Origin Special?

No. It's just a convention.

You could name it anything:

git remote add pizza https://github.com/username/repo.git
git push pizza main

That works. But everyone uses origin. It's the standard. Don't be different just to be different.

Stick with Convention

Use origin for your primary remote. Your team expects it. Tools assume it. Don't fight convention.

Quick Command Reference

Task Command
See all remotes git remote -v
Add a remote named origin git remote add origin <url>
Change origin URL git remote set-url origin <new-url>
Remove origin git remote remove origin
Rename origin git remote rename origin old-origin
Fetch from origin git fetch origin
Push to origin git push origin <branch>
Pull from origin git pull origin <branch>

Advanced Scenarios

Everything below is optional. But useful for complex setups.

Working with Multiple Remotes

Origin vs Upstream (Forked Repositories)

You forked a repository. You have two remotes:

  • origin → Your fork on GitHub
  • upstream → The original repository

Why two remotes?

You push to your fork (origin). You pull from the original repo (upstream) to stay up to date.

flowchart TB
    A[Original Repo] -->|You forked it| B[Your Fork]
    B -->|git clone| C[Your Computer]
    C -->|git push| B
    A -->|git fetch upstream| C

    style A fill:#fff3e0
    style B fill:#e1f5ff
    style C fill:#e8f5e9

Setup:

# Clone your fork (origin is created automatically)
git clone https://github.com/you/repo.git

# Add upstream
git remote add upstream https://github.com/original-owner/repo.git

Check your remotes:

git remote -v

Output:

origin    https://github.com/you/repo.git (fetch)
origin    https://github.com/you/repo.git (push)
upstream  https://github.com/original-owner/repo.git (fetch)
upstream  https://github.com/original-owner/repo.git (push)

Daily workflow:

# Fetch latest from original repo
git fetch upstream

# Update your local main
git checkout main
git merge upstream/main

# Push to your fork
git push origin main

Changing the Origin URL

Switching from HTTPS to SSH (or Vice Versa)

You cloned with HTTPS. Now you want SSH. Or the repo moved. Or you got the URL wrong.

Check current URL:

git remote -v

Output:

origin  https://github.com/username/repo.git (fetch)
origin  https://github.com/username/repo.git (push)

Change to SSH:

git remote set-url origin git@github.com:username/repo.git

Verify:

git remote -v

Output:

origin  git@github.com:username/repo.git (fetch)
origin  git@github.com:username/repo.git (push)

Done. No need to re-clone.

Adding Origin to an Existing Local Repo

When You Init Locally First

You created a repo on your machine:

mkdir my-project
cd my-project
git init

You made commits. Now you want to push to GitHub.

Create repo on GitHub (don't initialize with README).

Add origin:

git remote add origin https://github.com/username/my-project.git

Push your code:

git branch -M main
git push -u origin main

Your local repo is now connected to GitHub.

Working with Multiple Origins

Deploy to Different Servers

You have one codebase. Multiple deployment targets.

  • origin → GitHub for version control
  • production → Production server
  • staging → Staging server

Add multiple remotes:

git remote add origin https://github.com/username/repo.git
git remote add production user@prod-server:/var/www/repo.git
git remote add staging user@staging-server:/var/www/repo.git

Check all remotes:

git remote -v

Output:

origin      https://github.com/username/repo.git (fetch)
origin      https://github.com/username/repo.git (push)
production  user@prod-server:/var/www/repo.git (fetch)
production  user@prod-server:/var/www/repo.git (push)
staging     user@staging-server:/var/www/repo.git (fetch)
staging     user@staging-server:/var/www/repo.git (push)

Push to specific remote:

# Push to GitHub
git push origin main

# Deploy to staging
git push staging main

# Deploy to production
git push production main

Removing and Re-adding Origin

Fixing a Messed Up Remote

Your origin is broken. Wrong URL. Corrupted. Whatever.

Remove it:

git remote remove origin

Verify it's gone:

git remote -v
# Should show nothing or only other remotes

Add it back:

git remote add origin https://github.com/username/repo.git

Verify:

git remote -v

Renaming Origin

Using a Different Name

You want to call it something else. Maybe you have multiple repos with different conventions.

Rename origin to github:

git remote rename origin github

Now you push to github:

git push github main

But again: don't do this unless you have a good reason. Stick with origin.

Real-World Scenarios

Scenario 1: You Cloned Someone's Repo

You want to contribute. You fork their repo. You clone your fork.

# Fork on GitHub first, then:
git clone https://github.com/you/their-repo.git
cd their-repo

# Add upstream
git remote add upstream https://github.com/them/their-repo.git

# Check remotes
git remote -v

Output:

origin    https://github.com/you/their-repo.git (fetch)
origin    https://github.com/you/their-repo.git (push)
upstream  https://github.com/them/their-repo.git (fetch)
upstream  https://github.com/them/their-repo.git (push)

Now you can:

  • Push to your fork: git push origin feature/new-thing
  • Pull from original: git fetch upstream

Scenario 2: Repository Moved

Your company moved from GitHub to GitLab. Same repo, different URL.

# Check current origin
git remote -v

# Update the URL
git remote set-url origin https://gitlab.com/company/repo.git

# Verify
git remote -v

Your local repo now points to the new location. No need to re-clone.

Scenario 3: You Have No Origin

You ran git init locally. No remote. You want to add one.

# Create repo on GitHub, then:
git remote add origin https://github.com/username/new-repo.git

# Push
git push -u origin main

Common Mistakes

Don't Remove Origin Without a Backup

If you remove origin and forget the URL, you can't push. Make sure you know the URL before removing.

Wrong:

git remote remove origin
# Oh no, what was the URL?

Right:

# Save the URL first
git remote -v
# Copy the URL
git remote remove origin
# Now you can add it back if needed

Origin is Not Always Main Remote

In forked repos, upstream might be more important than origin. Don't assume origin is the source of truth.

Best Practices

Do This

  • Always check remotes after cloning: git remote -v
  • Use origin for your primary remote
  • Use upstream for the original repo in forks
  • Name other remotes clearly: production, staging, etc.
  • Verify URL before pushing to a new remote

Quick Health Check

When you start work in a repo:

git remote -v
git status
git fetch origin

You'll know exactly where your code lives and if you're synced.

What's Next?

You understand origin. It's just a name. A reference to your remote repository.

Next up: branches. How local branches track remote branches. What origin/main means. How tracking works.

But now you know: when you see origin, it's just pointing to GitHub (or wherever your code is stored).