GitHub Pull Request Workflow – Fork, Clone, Branch, PR

Fork vs Clone

These two terms are often confused because they sound similar but serve different purposes:

The Complete Open-Source Contribution Workflow

Here's the full workflow from zero to merged PR:

Step 1: Fork the repository on GitHub

Go to the repo on GitHub and click the Fork button (top-right). GitHub creates a copy at github.com/YOUR-USERNAME/repo-name. This is now yours to push to.

Step 2: Clone YOUR fork to your local machine

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

# "origin" now points to YOUR fork
git remote -v
# origin  https://github.com/YOUR-USERNAME/repo-name.git (fetch)
# origin  https://github.com/YOUR-USERNAME/repo-name.git (push)

Step 3: Add the original repo as "upstream"

git remote add upstream https://github.com/ORIGINAL-AUTHOR/repo-name.git

git remote -v
# origin    https://github.com/YOUR-USERNAME/repo-name.git (fetch)
# origin    https://github.com/YOUR-USERNAME/repo-name.git (push)
# upstream  https://github.com/ORIGINAL-AUTHOR/repo-name.git (fetch)
# upstream  https://github.com/ORIGINAL-AUTHOR/repo-name.git (push)

Step 4: Create a feature branch

# Always branch off main (or the default branch)
git switch main
git switch -c fix/typo-in-readme

Step 5: Make your changes and commit

# Edit files, then stage and commit
git add README.md
git commit -m "fix: correct spelling of 'repository' in README"

Step 6: Push your branch to YOUR fork

git push -u origin fix/typo-in-readme
# Counting objects: 3, done.
# Branch 'fix/typo-in-readme' set up to track remote branch 'fix/typo-in-readme' from 'origin'.

Step 7: Open a Pull Request on GitHub

Go to GitHub. You'll see a yellow banner: "Your recently pushed branch: fix/typo-in-readme — Compare & pull request". Click it.

• Base repository: ORIGINAL-AUTHOR/repo-name, branch: main
• Head repository: YOUR-USERNAME/repo-name, branch: fix/typo-in-readme

Writing a Good PR Description

A clear PR description helps reviewers understand your change quickly:

## What does this PR do?
Fixes a typo in README.md: "repositry" → "repository".

## Why?
Incorrect spelling in the getting-started section.

## How to test?
1. Open README.md
2. Search for "repository" — should be spelled correctly throughout.

## Checklist
- [x] Typo fixed
- [x] No other changes in this PR

Handling Code Review

Reviewers may leave comments requesting changes. You don't need to close and reopen the PR — just push more commits to the same branch. The PR updates automatically.

# Make the requested change
git add README.md
git commit -m "fix: also correct spelling in contributing guide per review"
git push   # pushes to the same branch — PR updates automatically

# If asked to squash commits before merging, use interactive rebase:
git rebase -i main
# Squash to one clean commit, force-push your branch:
git push --force-with-lease

Keeping Your Fork in Sync with Upstream

While your PR is being reviewed, the original repo may get new commits. Keep your fork up to date:

# Fetch latest from the original repo
git fetch upstream

# Update your local main
git switch main
git merge upstream/main   # fast-forward if you haven't committed to main directly

# Push the updated main to YOUR fork on GitHub
git push origin main

# Update your feature branch if needed
git switch fix/typo-in-readme
git rebase main   # rebase onto updated main

The GitHub Workflow: From Local Commit to Merged PR

The standard team workflow ties your local Git to GitHub through a repeatable loop: branch, push, open a pull request (PR), review, merge. The PR is the heart of it — where code is reviewed before it reaches the main branch.

git switch -c feature/login      # 1. branch for the work
# ...commit changes...
git push -u origin feature/login # 2. push the branch to GitHub
# 3. open a Pull Request on GitHub
# 4. teammates review + CI runs tests
# 5. merge the PR → delete the branch
git switch main && git pull       # 6. sync your local main

The pull request is the key concept: instead of pushing straight to main, you push a branch and open a PR — a proposal to merge your changes. Teammates review the diff, leave comments, and approve; automated CI runs tests and linting. Only after both pass does the branch merge into main. This gate keeps the main branch stable and shares knowledge across the team. Fork vs branch: on a team repo you push branches directly; for open-source contributions you fork (make your own copy), push there, and open a PR from your fork to the original — the same review flow across accounts. Keep in sync: pull main regularly so your branch doesn't drift; resolve conflicts early in small pieces rather than one giant clash at merge time. Branch protection rules on GitHub enforce "no direct pushes to main, require review + green CI" — turning the workflow from convention into guarantee.

Interview Questions

• What is a Pull Request?
• What is the difference between a fork and a clone?
• What do "origin" and "upstream" mean in a fork workflow?
• How do Pull Requests support code review?
• How do you keep a fork up to date?

Related Topics