Fork and pull request workflow in Git - Step-by-Step Execution

Process Flow - Fork and pull request workflow

Fork repository

↓

Clone fork locally

↓

Create new branch

↓

Make changes & commit

↓

Push branch to fork

↓

Open pull request

↓

Review & merge by original repo

↓

Pull updates to local repo

This flow shows how you copy a repo (fork), work on your copy, then ask the original repo to add your changes via a pull request.

Execution Sample

Git

# Fork repository on GitHub UI
git clone https://github.com/yourname/repo.git
git remote add upstream https://github.com/original/repo.git
git checkout -b feature-branch
# edit files
git commit -am "Add feature"
git push origin feature-branch
# open pull request on GitHub

Commands to fork a repo, clone it, create a branch, commit changes, push, and open a pull request.

Process Table

Step	Action	Command/Description	Result/State Change
1	Fork repository	Fork on GitHub UI	Your GitHub account has a copy of the original repo
2	Clone fork locally	git clone https://github.com/yourname/repo.git git remote add upstream https://github.com/original/repo.git	Local copy of your forked repo created, upstream remote added
3	Create new branch	git checkout -b feature-branch	New branch 'feature-branch' created and checked out
4	Make changes & commit	Edit files + git commit -am "Add feature"	Changes saved in local branch with commit
5	Push branch to fork	git push origin feature-branch	Branch and commits uploaded to your GitHub fork
6	Open pull request	Open PR on GitHub from feature-branch to original repo	Pull request created for review
7	Review & merge	Original repo maintainer reviews and merges PR	Changes merged into original repo
8	Pull updates locally	git checkout main git pull upstream main	Local repo updated with merged changes
9	Exit	Workflow complete	Your changes are now part of the original repo

💡 Pull request merged and local repo updated, workflow ends

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 7	Final
Repository	Original repo only	Forked repo cloned locally	Branch 'feature-branch' with changes	Branch pushed to fork on GitHub	PR merged in original repo	Local repo updated with merged changes
Branch	main	feature-branch created	feature-branch with commit	feature-branch on fork remote	feature-branch merged to main	main updated locally

Key Moments - 3 Insights

Why do we create a new branch instead of committing directly to main?

Creating a new branch isolates your changes so the main branch stays stable. See execution_table step 3 and 4 where the branch is created and commits happen there.

What happens if you push changes directly to the original repo?

You usually can't push directly unless you have permission. Forking lets you work independently. Step 5 shows pushing to your fork, not original repo.

Why do we pull updates from the original repo after merging?

To keep your local copy up to date with the original repo's latest changes. Step 8 shows pulling updates after PR merge.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the new branch created?

A Step 2

B Step 5

C Step 3

D Step 6

💡 Hint

Check the 'Action' column for branch creation in the execution_table.

At which step does the pull request get merged into the original repo?

A Step 4

B Step 7

C Step 5

D Step 8

💡 Hint

Look for 'Review & merge' action in the execution_table.

If you skip pushing your branch to your fork, what will happen when opening a pull request?

A Pull request will fail to open

B Pull request will show no changes

C Pull request will merge automatically

D Pull request will open but be empty

💡 Hint

Refer to step 5 and 6 in execution_table about pushing branch before opening PR.

Concept Snapshot

Fork and pull request workflow:
1. Fork repo on GitHub to create your copy.
2. Clone your fork locally.
3. Create a new branch for your changes.
4. Commit and push changes to your fork.
5. Open a pull request to original repo.
6. Original repo reviews and merges your changes.

Full Transcript

The fork and pull request workflow starts by copying a repository on GitHub (fork). Then you clone your fork to your computer. Next, create a new branch to keep your work separate from the main code. Make your changes and commit them locally. Push this branch to your fork on GitHub. Open a pull request from your branch to the original repository to ask for your changes to be added. The original repo maintainer reviews and merges your changes. Finally, pull the latest changes to keep your local repo updated. This workflow helps keep the original project stable while allowing many people to contribute safely.

Practice

1. What is the main purpose of forking a repository in the fork and pull request workflow?

easy

A. To clone the repository locally without any changes

B. To delete the original project

C. To create a personal copy of the project to work on independently

D. To merge changes directly into the original repository

Solution

1. Step 1: Understand the concept of forking

   Forking creates a personal copy of the original project on your GitHub account, allowing you to work independently without affecting the original.

2. Step 2: Identify the purpose in the workflow

   This personal copy lets you safely make changes and experiment before proposing them back to the original project.

3. Final Answer:

   To create a personal copy of the project to work on independently -> Option C

4. Quick Check:

   Fork = personal copy for safe work [OK]

Hint: Fork means copy project to your account for safe changes [OK]

Common Mistakes:

• Confusing fork with clone
• Thinking fork deletes original
• Assuming fork merges changes automatically

2. Which command correctly pushes a new branch named feature1 to your forked repository?

easy

A. git push origin main

B. git push upstream feature1

C. git push fork feature1

D. git push origin feature1

Solution

1. Step 1: Identify the remote name for your fork

   By default, your fork is set as the remote named origin. The original repository is usually upstream.

2. Step 2: Use the correct push syntax

   To push a branch named feature1 to your fork, use git push origin feature1.

3. Final Answer:

   git push origin feature1 -> Option D

4. Quick Check:

   Push branch to origin (your fork) = git push origin branch [OK]

Hint: Push new branch to origin, not upstream [OK]

Common Mistakes:

• Using upstream instead of origin for push
• Pushing main branch instead of feature branch
• Using incorrect remote name like fork

3. After forking a repo and pushing a branch fix-bug to your fork, what is the next step to propose your changes to the original project?

medium

A. Directly push fix-bug branch to the original repository

B. Create a pull request from your fork's fix-bug branch to the original repo

C. Merge fix-bug branch locally without pushing

D. Delete your fork and clone the original repo again

Solution

1. Step 1: Understand the pull request purpose

   A pull request asks the original project to review and merge your changes from your fork's branch.

2. Step 2: Identify the correct action after pushing

   After pushing your branch to your fork, you create a pull request targeting the original repository's branch.

3. Final Answer:

   Create a pull request from your fork's fix-bug branch to the original repo -> Option B

4. Quick Check:

   Push branch then create pull request [OK]

Hint: Push branch, then open pull request to original repo [OK]

Common Mistakes:

• Trying to push directly to original repo without permission
• Merging locally without sharing changes
• Deleting fork before proposing changes

4. You forked a repo and created a branch update-docs. You pushed it but forgot to sync your fork with the original repo first. What problem might occur when creating a pull request?

medium

A. Merge conflicts due to outdated fork base

B. Your pull request will be automatically merged

C. Your branch will be deleted automatically

D. No changes will be visible in the pull request

Solution

1. Step 1: Understand syncing forks

   If your fork is behind the original repo, your branch may not include recent changes from the original.

2. Step 2: Identify the pull request impact

   This can cause merge conflicts when the original repo tries to merge your changes because the base is outdated.

3. Final Answer:

   Merge conflicts due to outdated fork base -> Option A

4. Quick Check:

   Outdated fork causes merge conflicts [OK]

Hint: Always sync fork before starting new branch [OK]

Common Mistakes:

• Assuming pull request merges automatically
• Thinking branch deletes itself
• Believing changes won't show without sync

5. You forked a project and created two branches: featureA and featureB. You pushed both branches to your fork. How do you create pull requests so the original repo can review and merge these features independently?

hard

A. Create separate pull requests for each branch targeting the original repo's main branch

B. Create one pull request combining both branches

C. Push both branches to upstream and wait for automatic merge

D. Merge featureB into featureA locally, then create a single pull request

Solution

1. Step 1: Understand pull request scope

   Each pull request represents changes from one branch to the original repo, allowing independent review.

2. Step 2: Apply to multiple branches

   To keep features separate, create one pull request per branch targeting the original repo's main branch.

3. Final Answer:

   Create separate pull requests for each branch targeting the original repo's main branch -> Option A

4. Quick Check:

   One pull request per branch for independent review [OK]

Hint: Make one pull request per branch for clear reviews [OK]

Common Mistakes:

• Combining branches in one pull request
• Pushing branches directly to upstream without PR
• Merging branches locally before PR