Chapter 6.6 — Stash Branch & Keep Index☕ 16 min read

Forking Workflow

Fork = apni copy. Clone = download. PR = dawat. Yeh open source ka ABC hai.

01Stash Branch Kya Hai

You cannot push to repositories you don't own or have write access to. This is fundamental — if everyone could push to any repo, chaos would ensue. Every repository has access controls.

A fork is your personal server-side copy of someone else's repository. It lives on GitHub under YOUR account. You have full push access to your fork, but zero push access to the original.

The original repository is called upstream. Your fork is called origin (when you clone it). You push to origin, and create Pull Requests to upstream.

The complete forking workflow:

Fork the original repo on GitHub (click the Fork button)
Clone YOUR fork to your machine (not the original)
Add the original as an "upstream" remote
Branch — create a feature branch for your contribution
Commit your changes
Push to your fork (origin)
PR — create a Pull Request from your fork to upstream

This model lets anyone contribute to any public project without needing direct push access. It is how the entire open source world operates.

# The Forking Workflow
# 1. Fork on GitHub (click the Fork button)
#    Creates: github.com/YOUR-USERNAME/project

# 2. Clone YOUR fork (not the original)
git clone https://github.com/YOUR-USERNAME/project.git
cd project

# 3. Add the original repo as "upstream"
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git

# 4. Verify remotes
git remote -v
# origin    https://github.com/YOUR-USERNAME/project.git (fetch)
# upstream  https://github.com/ORIGINAL-OWNER/project.git (fetch)

# origin = YOUR fork (you can push here)
# upstream = ORIGINAL repo (read-only for you)

Fork and Clone are different operations! Fork = server-side copy on GitHub (creates a new repo under your account). Clone = download to your local machine. For open source contributions, you do BOTH: first fork on GitHub, then clone YOUR fork to your machine.

02Create Branch from Stash

Let us walk through the entire forking workflow step by step — from fork to merged PR.

Step 1: Fork on GitHub. Navigate to the original repository and click the "Fork" button. This creates a copy under your account.

Step 2: Clone YOUR fork. Not the original. This is critical. If you clone the original, you cannot push to it.

Step 3: Add upstream remote. This lets you fetch changes from the original repository to keep your fork updated.

Step 4: Create a feature branch. Never commit directly to your fork's main. Always use a branch.

Step 5: Make changes and commit. Write your code, fix the bug, add the feature.

Step 6: Push to YOUR fork. git push -u origin fix/typo-readme pushes your branch to your fork on GitHub.

Step 7: Create a Pull Request. From your fork's branch to the upstream's main. Maintainers review and merge.

# Step 1: Fork on GitHub (UI)

# Step 2: Clone your fork
git clone git@github.com:YOUR-USERNAME/project.git
cd project

# Step 3: Add upstream
git remote add upstream git@github.com:ORIGINAL-OWNER/project.git

# Step 4: Create feature branch
git checkout -b fix/typo-readme

# Step 5: Make changes and commit
echo "Fixed typo" >> README.md
git add README.md
git commit -m "fix: correct typo in installation section"

# Step 6: Push to YOUR fork
git push -u origin fix/typo-readme

# Step 7: Create PR from your fork to upstream
gh pr create --repo ORIGINAL-OWNER/project \
  --title "fix: correct typo in installation section" \
  --body "Fixed a typo in the README installation instructions."

💡 Pro Tip: The #1 mistake: cloning the original repo instead of your fork. If you clone the original, you can't push to it (no write access). Always clone YOUR fork, and add the original as upstream. Verify with git remote -v — origin should point to YOUR username.

03Keep Index — Staged Files Ko Bachao

Your fork does NOT automatically update when the original repository gets new commits. This is a common surprise for beginners.

If the original repo has 100 new commits since you forked, your fork is 100 commits behind. If you create a PR from an outdated fork, you will face massive merge conflicts.

To update your fork:

git fetch upstream — download new commits from the original
git checkout main — switch to your local main
git merge upstream/main — integrate upstream changes into your local main
git push origin main — push the updated main to your fork on GitHub

Do this BEFORE creating a feature branch. Starting from an updated main means minimal conflicts.

Alternative with rebase: git rebase upstream/main instead of merge — gives a cleaner history but rewrites commits.

GitHub has a "Sync fork" button on your fork's page, but the CLI is more reliable when there are conflicts.

# Before starting any new work, sync your fork!

# Step 1: Fetch upstream changes
git fetch upstream

# Step 2: Switch to your local main
git checkout main

# Step 3: Merge upstream/main into your local main
git merge upstream/main
# Or use rebase for cleaner history:
# git rebase upstream/main

# Step 4: Push the updated main to YOUR fork
git push origin main

# Now your fork is up to date with the original repo
# Create a fresh feature branch from this updated main
git checkout -b feature/new-contribution

# GitHub "Sync fork" button does steps 1-4 for you
# But learning the CLI is essential for resolving conflicts

04Stash Workflow Scenarios

After pushing to your fork, GitHub usually shows a "Compare & pull request" button on your fork's page. Click it, or create the PR from the CLI.

Using the GitHub CLI: gh pr create --repo ORIGINAL-OWNER/project — this creates a PR from your fork's branch to the upstream's main branch.

What happens after you create a PR:

Maintainers receive a notification and review your code
They may request changes — this is normal, not a rejection
To update the PR: push new commits to the same branch on your fork. The PR updates automatically!
After merge: delete your feature branch and sync your fork's main

The PR is a living thing — it reflects the current state of your branch. Add commits, and the PR shows them. Force-push the branch, and the PR updates accordingly.

# Create PR via GitHub CLI
gh pr create --repo ORIGINAL-OWNER/project \
  --head YOUR-USERNAME:fix/typo-readme \
  --base main \
  --title "fix: correct typo" \
  --body "Fixed installation typo."

# Maintainer requests changes
# Make the requested changes
echo "addressed feedback" >> README.md
git add README.md
git commit -m "fix: address review feedback"
git push origin fix/typo-readme
# PR updates automatically with the new commit!

# After PR is merged:
# 1. Delete the feature branch
git push origin --delete fix/typo-readme
git branch -d fix/typo-readme

# 2. Sync your fork's main
git checkout main
git fetch upstream
git merge upstream/main
git push origin main

05Advanced Tips & Best Practices

Mistake 1: Committing on your fork's main branch. This causes your fork's main to diverge from upstream. Future syncs create conflicts. PRs from your main are messy and hard to review. Always use feature branches.

Mistake 2: Forgetting to sync before starting work. Working on a stale fork guarantees massive merge conflicts when you create your PR. Sync takes 30 seconds; resolving conflicts takes hours.

Mistake 3: Creating PR from your fork's main instead of a feature branch. Your PR history includes all commits on main, making it impossible for maintainers to review just your contribution.

Tip 1: Always create feature branches from an updated main. Sync first, branch second.

Tip 2: Squash WIP commits before creating a PR. Use git rebase -i to clean up your commit history. Maintainers appreciate focused, clean PRs.

Tip 3: Read the project's CONTRIBUTING.md before contributing. Many projects have specific conventions for commit messages, branch naming, and PR formats.

Tip 4: Check if the project uses a CLA (Contributor License Agreement). Some projects require you to sign one before your PR can be merged.

# BAD: Working directly on your fork's main
git clone git@github.com:YOUR-USERNAME/project.git
cd project
echo "my contribution" >> file.txt
git add . && git commit -m "my contribution"
git push origin main
# Now your main is ahead of upstream's main
# Future syncs will cause conflicts!
# PRs from your main are messy and hard to review.

# GOOD: Always use feature branches
git clone git@github.com:YOUR-USERNAME/project.git
cd project
git fetch upstream && git checkout main && git merge upstream/main
git checkout -b feat/my-contribution
echo "my contribution" >> file.txt
git add . && git commit -m "feat: add contribution"
git push -u origin feat/my-contribution
gh pr create --repo ORIGINAL-OWNER/project

# Before contributing, check for contribution guidelines
cat CONTRIBUTING.md  # or docs/CONTRIBUTING.md

The forking workflow is how the world's largest open source projects operate. Linux, React, VS Code — all use forks and PRs. Understanding this workflow means you can contribute to ANY public repository on GitHub. Your first open source contribution is just a fork away!

Lo kar liya — Key Points:

✅ Fork creates your personal server-side copy of a repository you don't own
✅ Clone YOUR fork (origin), not the original repository (upstream)
✅ Add the original repository as the upstream remote to fetch updates
✅ Create feature branches for contributions, never commit directly to your fork's main
✅ Push to your fork (origin) and create a Pull Request to the upstream repository
✅ Keep your fork updated by fetching upstream and merging into your local main, then pushing to origin
✅ The forking workflow is the standard for open source contributions on GitHub

Previous6.5 — Stash Untracked & Including All 📋 All Chapters Next Chapter6.7 — Git Worktrees →