Chapter 6.1 — Clone, Fetch, Pull & Push☕ 15 min read

Clone, Fetch, Pull & Push

Fetch = peepna, Pull = lena, Push = dena. Yeh Git ki duniya ka ABC hai.

01The Remote Connection: origin

Remote = a bookmark to another repository, usually on GitHub/GitLab. It is not the repository itself — it is a pointer (URL) to where the repository lives on the network.

The default remote name is origin. When you clone a repository, Git automatically names the source remote as origin. This is just a convention, not a requirement — you can name it anything.

git remote -v shows all your remote URLs — both fetch URL and push URL. This is the first command to run when you want to understand your remote setup.

You can add multiple remotes for different purposes:

origin — your fork or personal repository (the one you cloned from)
upstream — the original repository you forked from (for open-source contributions)
heroku or deploy — deployment targets

Remote-tracking branches (like origin/main) are local mirrors of the remote state. Git updates them during fetch and pull. You do NOT modify them directly — they represent what the remote looked like the last time you synced.

# View existing remotes
git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

# Add a new remote
git remote add upstream https://github.com/original/repo.git

# Rename a remote
git remote rename origin github

# Remove a remote
git remote remove upstream

# See remote details
git remote show origin
# * remote origin
#   Fetch URL: https://github.com/user/repo.git
#   Push  URL: https://github.com/user/repo.git
#   HEAD branch: main
#   Remote branches:
#     main tracked
#     feature tracked

02git clone: The Full Download

git clone <url> downloads the ENTIRE repository: all commits, all branches, all tags, the complete history. This is not just downloading the latest files — you get a full DVCS repository.

When you clone, Git does four things automatically:

Creates a new directory with the project files (working directory)
Initializes a .git/ directory with the complete history
Creates an origin remote pointing to the source URL
Checks out the default branch (usually main)

Clone vs init: git init creates a NEW empty repository from scratch. git clone copies an EXISTING repository with all its history. They serve completely different purposes.

git clone --depth 1 <url> creates a shallow clone — only the latest commit, no history. Faster for CI/CD pipelines but you cannot view history, create branches from old commits, or use bisect.

# Standard clone — full history
git clone https://github.com/user/repo.git
cd repo
# You have the ENTIRE history locally

# Clone into a specific folder
git clone https://github.com/user/repo.git my-project

# Shallow clone — only latest commit (faster for CI)
git clone --depth 1 https://github.com/user/repo.git

# Clone a specific branch only
git clone --branch feature --single-branch https://github.com/user/repo.git

# Verify what you got
git log --oneline  # full history (unless shallow)
git remote -v      # origin is automatically set
git branch -a      # see all remote branches

03git fetch: Look Before You Touch

git fetch downloads new commits from the remote but does NOT merge them into your local branches. It only updates your remote-tracking branches (origin/main, origin/feature, etc.).

Your working directory and local branches remain completely UNTOUCHED. This makes fetch the safest remote operation — you can run it anytime without worrying about breaking your code.

After fetching, you can inspect what changed before deciding to merge:

git log origin/main — see commits on the remote that you do not have
git diff main..origin/main — see the actual code differences
git checkout origin/main — explore the remote state in detached HEAD

Fetch is like checking your mailbox — you see what arrived, but you decide when to open it.

# Fetch from origin (default)
git fetch origin

# Fetch from all remotes
git fetch --all

# Fetch a specific branch
git fetch origin feature

# After fetching, see what is new
git log HEAD..origin/main --oneline
# Shows commits on origin/main that you do not have locally

# See the diff between your main and remote main
git diff main origin/main

# Fetch + check without merging
git fetch origin
git checkout origin/main  # detached HEAD at remote state
# Explore the code safely
git checkout main  # return to your branch

💡 Pro Tip: Always use git fetch before git pull to see what you are about to merge. If the remote has unexpected changes, you can plan your merge instead of being surprised by a conflict. Professional developers fetch frequently and pull deliberately.

04git pull: Fetch + Merge

git pull = git fetch + git merge. It downloads changes AND integrates them into your current branch in one step.

Default behavior: fetches from origin and merges the remote-tracking branch into your current branch. If your local and remote have diverged, this creates a merge commit.

git pull --rebase = fetch + rebase. This replays your local commits on top of the remote commits instead of creating a merge commit. The result is a cleaner linear history.

Pull conflicts: if your local changes conflict with remote changes, pull will pause and ask you to resolve conflicts before completing the merge or rebase.

Configure default behavior: git config --global pull.rebase true makes all future pulls use rebase instead of merge. This is the recommended setting for clean history.

# Standard pull (fetch + merge)
git pull origin main
# Creates a merge commit if histories diverged

# Pull with rebase (fetch + rebase) — RECOMMENDED
git pull --rebase origin main
# Replays your local commits on top of remote

# Set rebase as default for pull
git config --global pull.rebase true
# Now git pull always uses rebase

# Pull all remotes
git pull --all

# If pull fails due to conflict
git pull origin main
# CONFLICT! Resolve, add, then:
# If merge: git add . && git commit
# If rebase: git add . && git rebase --continue

05git push: Share Your Work

git push uploads your local commits to the remote repository. This is how you share your work with the team.

git push origin main pushes your local main branch to origin/main on the remote.

First push of a new branch requires the -u flag: git push -u origin feature. The -u (short for --set-upstream) tells Git to remember the relationship between your local branch and the remote branch. After setting upstream once, just git push works — Git knows where to push.

Push is REJECTED if the remote has commits you do not have. This protects you from overwriting someone else's work. You must pull first, resolve any conflicts, and then push.

git push --force overwrites remote history. DANGEROUS — only use on personal branches, never on shared branches. Use --force-with-lease instead if you must force push — it is safer because it checks that nobody else pushed in the meantime.

# Push to default remote
git push origin main

# First push of a new branch — set upstream
git checkout -b feature
git push -u origin feature
# Now the branch is tracked

# Subsequent pushes — just:
git push

# Push all branches
git push --all origin

# Push tags
git push origin v1.0.0
git push --tags  # push all tags

# Push rejected (remote has new commits)
git push origin main
# ! [rejected]        main -> main (non-fast-forward)
# Fix: pull first
git pull --rebase origin main
git push origin main

The golden remote workflow: fetch often, pull deliberately, push carefully. Always git fetch to see what is new before pulling. Use git pull --rebase to avoid unnecessary merge commits. And never force push to shared branches. This workflow keeps the team's history clean and prevents unexpected conflicts.

Lo kar liya — Key Points:

✅ git remote manages connections to remote repositories; origin is the default remote name
✅ git clone downloads the entire repository with full history and automatically sets up the origin remote
✅ git fetch downloads new data from remote without merging — safe to run anytime
✅ git pull fetches and merges remote changes into your current branch
✅ git pull --rebase fetches and rebases, creating a cleaner linear history without merge commits
✅ git push uploads local commits to the remote; use -u to set upstream tracking for new branches
✅ Push is rejected if remote has commits you lack; pull first, then push

Previous5.7 — Autosquash — fixup & squash automation 📋 All Chapters Next Chapter6.2 — SSH vs HTTPS Setup →