Fork and pull request workflow in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of a fork in GitHub workflow?

In the fork and pull request workflow, why do developers create a fork of a repository?

A To create a personal copy of the repository where they can freely make changes without affecting the original project

B To directly push changes to the original repository without review

C To delete the original repository and replace it with their own version

D To merge the original repository into their local machine automatically

💡 Hint

Think about why you might want your own space to work on a project without changing the original code immediately.

A fork creates a personal copy of the repository on your GitHub account. This allows you to experiment and make changes safely. You can later propose your changes to the original project via a pull request.

💻 Command Output

intermediate

What is the output of this git command sequence?

Assume you have forked a repository and cloned your fork locally. You run these commands:

git remote -v
git fetch upstream
git merge upstream/main

What does the git remote -v command output show?

Git

git remote -v

A No remotes configured

B

origin  https://github.com/originalowner/repo.git (fetch)
origin  https://github.com/originalowner/repo.git (push)

C

upstream  https://github.com/yourusername/repo.git (fetch)
upstream  https://github.com/yourusername/repo.git (push)

D

origin  https://github.com/yourusername/repo.git (fetch)
origin  https://github.com/yourusername/repo.git (push)
upstream  https://github.com/originalowner/repo.git (fetch)
upstream  https://github.com/originalowner/repo.git (push)

💡 Hint

Remember that origin points to your fork and upstream points to the original repository.

After cloning your fork, origin points to your fork URL. Adding upstream remote points to the original repository. The git remote -v command lists both remotes with their URLs.

🔀 Workflow

advanced

Correct order of steps to contribute using fork and pull request

Arrange these steps in the correct order to contribute a fix to a project using the fork and pull request workflow.

A 3,2,4,1

B 2,4,3,1

C 2,3,4,1

D 4,3,2,1

💡 Hint

Think about starting from GitHub, then working locally, then proposing changes.

First, fork the repo on GitHub. Then clone your fork locally. Next, make and commit changes. Finally, create a pull request to propose your changes.

❓ Troubleshoot

advanced

Why does this pull request show no changes?

You forked a repository, cloned it, made changes, committed, and pushed to your fork. But when you open a pull request, it shows no changes. What is the most likely cause?

A You forgot to fork the repository before cloning

B You pushed your changes to a different branch than the one used in the pull request

C You merged the upstream branch into your fork before pushing

D You deleted your fork after pushing changes

💡 Hint

Check if the branch you pushed matches the branch selected in the pull request.

If you push changes to a branch different from the one used in the pull request, GitHub shows no changes because the pull request compares the wrong branches.

✅ Best Practice

expert

What is the best practice to keep your fork updated with the original repository?

You have a fork of a repository and want to keep it updated with the latest changes from the original project. Which command sequence is best practice?

A

git fetch upstream
 git checkout main
 git merge upstream/main
 git push origin main

B

git checkout main
 git push origin main
 git fetch upstream

C

git clone upstream
 git push origin main

D

git pull origin main
 git push upstream main

💡 Hint

Think about fetching changes from the original repo, merging locally, then pushing to your fork.

Fetching from upstream gets the latest changes. Merging them into your local main updates your fork. Pushing to origin updates your fork on GitHub.