Fork and pull request workflow in Git - Mini Project: Build & Apply

Fork and Pull Request Workflow

📖 Scenario: You want to contribute a small fix to an open-source project on GitHub. You will use the fork and pull request workflow to safely make your changes and propose them to the original project.

🎯 Goal: Learn how to fork a repository, clone your fork locally, create a new branch, make a change, push it to your fork, and open a pull request to the original repository.

📋 What You'll Learn

Use the exact repository URL https://github.com/example/project.git

Create a fork on GitHub (simulated by a command)

Clone your fork using the URL https://github.com/yourusername/project.git

Create a branch called fix-typo

Make a change by creating a file fix.txt with content Fixed typo

Commit the change with message Fix typo in documentation

Push the branch fix-typo to your fork

Open a pull request from fix-typo branch of your fork to the main branch of the original repository

💡 Why This Matters

🌍 Real World

Open-source contributors use fork and pull request workflows to safely propose changes without affecting the original project directly.

💼 Career

Understanding this workflow is essential for collaborating on shared codebases in software development jobs and open-source projects.

1

Fork and clone the repository

Simulate forking the repository by creating a new remote called origin with URL https://github.com/yourusername/project.git. Then clone your fork locally using git clone https://github.com/yourusername/project.git.

Git

# Simulate fork by adding remote origin
# Then clone your fork
# Your code here

Hint

Use git remote add origin <url> to add your fork as a remote. Then use git clone <url> to copy it locally.

2

Create a new branch for your fix

Create a new branch called fix-typo using git checkout -b fix-typo.

Git

git remote add origin https://github.com/yourusername/project.git
git clone https://github.com/yourusername/project.git
# Create a new branch called fix-typo
# Your code here

Hint

Use git checkout -b fix-typo to create and switch to the new branch.

3

Make a change and commit it

Create a file named fix.txt with the content Fixed typo. Then stage the file using git add fix.txt and commit with the message Fix typo in documentation using git commit -m "Fix typo in documentation".

Git

git remote add origin https://github.com/yourusername/project.git
git clone https://github.com/yourusername/project.git
git checkout -b fix-typo
# Create fix.txt with content 'Fixed typo'
# Stage and commit the file
# Your code here

Hint

Use echo "Fixed typo" > fix.txt to create the file. Then add and commit it with the exact message.

4

Push your branch and open a pull request

Push the branch fix-typo to your fork using git push origin fix-typo. Then simulate opening a pull request from your fix-typo branch to the main branch of the original repository by printing Pull request opened from fix-typo to main.

Git

git remote add origin https://github.com/yourusername/project.git
git clone https://github.com/yourusername/project.git
git checkout -b fix-typo
echo "Fixed typo" > fix.txt
git add fix.txt
git commit -m "Fix typo in documentation"
# Push the fix-typo branch to origin
# Print 'Pull request opened from fix-typo to main'
# Your code here

Hint

Use git push origin fix-typo to upload your branch. Then print the message exactly as shown.

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