DEV Community

Irene Githundi
Irene Githundi

Posted on

Understanding Git Origins and Upstreams

#programming #devops #github #learning

When you fork a repository on GitHub, you're making a copy. But here's what nobody tells you clearly: you now have TWO versions of the same project.

git remote -v
Enter fullscreen mode Exit fullscreen mode 
origin    git@github.com:IreneGithundi/project.git
upstream  git@github.com:pravinmishra88/project.git
Enter fullscreen mode Exit fullscreen mode

Think of it like this:

upstream = The official project (the "source of truth")
origin = Your personal copy (your "sandbox")

Why Both?
Here's the scenario that made it clear after much struggle:

  • You fork a project on Monday
  • You spend Tuesday and Wednesday coding your feature
  • Meanwhile, 10 other developers push changes to the official project (upstream)
  • On Thursday, you try to contribute your code back

The problem: Your code is now outdated. You're working with Monday's version while everyone else is on Thursday's version.
The solution: Sync **with upstream **BEFORE you push.

# Get the latest from the official project
git fetch upstream

# Merge those updates into your branch
git merge upstream/main

# Now push to YOUR fork
git push origin my-feature-branch
Enter fullscreen mode Exit fullscreen mode

What's Actually Happening Here?
Think of upstream as the company headquarters and origin as your local office branch:

Fetch upstream = "Hey headquarters, what's new?"
Merge = "Let me update my local office with headquarters' latest policies"
Push to origin = "Now I'll save MY work to MY office"
Pull Request = "Headquarters, I've made improvements. Want to add them to the official policy?"

The lightbulb moment: You never push directly to upstream. You push to origin (your fork), then create a Pull Request asking upstream to accept your changes. This protects the official project from breaking.

Top comments (0)