Bird
Raised Fist0
Gitdevops~20 mins

Code review in pull requests in Git - Mini Project: Build & Apply

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Code Review in Pull Requests
📖 Scenario: You are working on a team project using Git and GitHub. Your team uses pull requests to review code changes before merging them into the main branch. This helps catch mistakes early and keeps the project quality high.
🎯 Goal: You will create a new branch, make a simple code change, push it to GitHub, open a pull request, and simulate a code review comment. This will teach you the basic workflow of code review in pull requests.
📋 What You'll Learn
Create a new branch called feature/update-readme
Make a change to the README.md file by adding the line Updated project description.
Commit the change with the message Update README with new description
Push the branch feature/update-readme to the remote repository
Simulate opening a pull request from feature/update-readme to main
Simulate adding a code review comment on the pull request
💡 Why This Matters
🌍 Real World
Teams use pull requests to review code changes before merging, which helps catch errors and improve code quality.
💼 Career
Understanding pull requests and code reviews is essential for collaboration in software development jobs.
Progress0 / 5 steps
1
Create a new branch called feature/update-readme
Use the command git checkout -b feature/update-readme to create and switch to the new branch.
Git
Hint

Think of a branch as a separate workspace. The command git checkout -b creates and switches to it in one step.

2
Add a line to README.md file
Add the exact line Updated project description. to the README.md file using a command like echo or by editing the file.
Git
Hint

You can add text to a file by using echo 'text' >> filename. The double greater-than sign appends the text.

3
Commit the change with message Update README with new description
Use git add README.md to stage the file, then commit with git commit -m "Update README with new description".
Git
Hint

First stage your changes with git add, then save them with git commit -m "message".

4
Push the branch and simulate opening a pull request
Push the branch with git push origin feature/update-readme. Then simulate opening a pull request by writing a comment: Open pull request from feature/update-readme to main.
Git
Hint

Use git push origin branch-name to send your branch to GitHub. Opening a pull request is usually done on GitHub website, but here you simulate it by writing a comment.

5
Simulate adding a code review comment on the pull request
Write a comment simulating a code review: Review comment: Please add more details to the README update.
Git
Hint

Code reviews help improve code quality. Here you practice by writing a review comment as a line starting with # Review comment:.

Practice

(1/5)
1. What is the main purpose of a pull request in Git?
easy
A. To review and discuss code changes before merging
B. To delete a branch from the repository
C. To create a new repository
D. To reset the main branch to a previous commit

Solution

  1. Step 1: Understand what a pull request does

    A pull request is used to propose code changes and get feedback before merging.

  2. Step 2: Identify the main purpose

    It allows team members to review, discuss, and approve changes to keep code quality high.

  3. Final Answer:

    To review and discuss code changes before merging -> Option A

  4. Quick Check:

    Pull request = code review and discussion [OK]
Hint: Pull requests are for reviewing code before merging [OK]
Common Mistakes:
  • Confusing pull requests with branch deletion
  • Thinking pull requests create repositories
  • Believing pull requests reset branches
2. Which Git command is used to push a new branch to the remote repository to start a pull request?
easy
A. git push origin main
B. git merge feature-branch
C. git pull origin feature-branch
D. git push origin feature-branch

Solution

  1. Step 1: Identify the command to push a branch

    To push a new branch named 'feature-branch' to remote, use 'git push origin feature-branch'.

  2. Step 2: Understand other options

    'git push origin main' pushes the main branch, 'git pull' fetches changes, and 'git merge' combines branches locally.

  3. Final Answer:

    git push origin feature-branch -> Option D

  4. Quick Check:

    Push new branch = git push origin branch-name [OK]
Hint: Push your feature branch with git push origin branch-name [OK]
Common Mistakes:
  • Using git push origin main instead of feature branch
  • Confusing git pull with git push
  • Trying to merge before pushing the branch
3. Given this sequence of commands, what is the output of git status after step 4? 
1. git checkout -b feature
2. touch newfile.txt
3. git add newfile.txt
4. git status
medium
A. On branch feature Changes to be committed: (new file: newfile.txt)
B. On branch feature nothing to commit, working tree clean
C. On branch main Changes to be committed: (new file: newfile.txt)
D. fatal: not a git repository

Solution

  1. Step 1: Analyze branch and file status

    After 'git checkout -b feature', you are on 'feature' branch. 'touch newfile.txt' creates a new file. 'git add newfile.txt' stages it.

  2. Step 2: Understand git status output

    'git status' shows staged changes. Since newfile.txt is added, it appears under 'Changes to be committed' on branch 'feature'.

  3. Final Answer:

    On branch feature Changes to be committed: (new file: newfile.txt) -> Option A

  4. Quick Check:

    Added file staged = git status shows it [OK]
Hint: Staged files show under 'Changes to be committed' in git status [OK]
Common Mistakes:
  • Assuming branch is still main
  • Thinking staging clears changes
  • Confusing untracked with staged files
4. You created a pull request but reviewers say your branch is behind main and has conflicts. What should you do to fix this?
medium
A. Delete your branch and create a new one
B. Force push your branch without updating
C. Merge main into your branch locally and resolve conflicts
D. Close the pull request and push directly to main

Solution

  1. Step 1: Understand the conflict cause

    Your branch is behind main, so changes in main conflict with your branch.

  2. Step 2: Fix conflicts by merging main

    Merge main into your branch locally using 'git merge main', resolve conflicts, then push updates to update the pull request.

  3. Final Answer:

    Merge main into your branch locally and resolve conflicts -> Option C

  4. Quick Check:

    Fix conflicts = merge main and resolve [OK]
Hint: Merge main into your branch to fix conflicts before pushing [OK]
Common Mistakes:
  • Force pushing without resolving conflicts
  • Deleting branch unnecessarily
  • Pushing directly to main ignoring review
5. You want to ensure that every pull request is reviewed by at least two team members before merging. Which GitHub feature should you configure?
hard
A. Enable auto-merge on pull requests
B. Branch protection rules with required reviews
C. Set default branch to feature branch
D. Use git stash before pushing

Solution

  1. Step 1: Identify the feature for enforcing reviews

    GitHub branch protection rules allow setting requirements like minimum number of reviewers before merging.

  2. Step 2: Understand other options

    Auto-merge merges without review, changing default branch doesn't enforce reviews, and git stash is unrelated to pull requests.

  3. Final Answer:

    Branch protection rules with required reviews -> Option B

  4. Quick Check:

    Require reviews = branch protection rules [OK]
Hint: Use branch protection rules to require reviews before merge [OK]
Common Mistakes:
  • Confusing auto-merge with review enforcement
  • Changing default branch instead of protection rules
  • Using git stash unrelated to reviews