Code review in pull requests in Git - Commands & Configuration

Introduction

Code review in pull requests helps teams check and improve code before adding it to the main project. It catches mistakes early and shares knowledge among team members.

When you want someone else to check your code changes before merging them.

When you want to discuss improvements or fixes with your team.

When you want to keep the main project stable by reviewing new code carefully.

When you want to track what changes are being added and why.

When you want to learn from feedback on your code.

Commands

Create and switch to a new branch named 'feature/add-login' to work on your code changes separately from the main branch.

Terminal

git checkout -b feature/add-login

Expected Output

No output (command runs silently)

Stage all your changed files to prepare them for committing.

Terminal

git add .

Expected Output

No output (command runs silently)

Save your staged changes with a clear message describing what you did.

Terminal

git commit -m "Add login feature with validation"

Expected Output

[feature/add-login abc1234] Add login feature with validation

 3 files changed, 45 insertions(+), 2 deletions(-)

Upload your branch and commits to the remote repository so others can see and review your changes.

Terminal

git push origin feature/add-login

Expected Output

Enumerating objects: 10, done.

Counting objects: 100% (10/10), done.

Delta compression using up to 8 threads

Compressing objects: 100% (7/7), done.

Writing objects: 100% (7/7), 1.2 KiB | 1.2 MiB/s, done.

Total 7 (delta 3), reused 0 (delta 0), pack-reused 0

remote: 

remote: Create a pull request for 'feature/add-login' on GitHub by visiting:

remote:      https://github.com/example/repo/pull/new/feature/add-login

remote: 

To https://github.com/example/repo.git

 * [new branch]      feature/add-login -> feature/add-login

Fetch the pull request number 42 from the remote repository and create a local branch 'pr-42' to review the code.

Terminal

git fetch origin pull/42/head:pr-42

Expected Output

From https://github.com/example/repo

 * [new ref]         refs/pull/42/head -> pr-42

Switch to the local branch 'pr-42' to inspect and test the pull request code.

Terminal

git checkout pr-42

Expected Output

Switched to branch 'pr-42'

Key Concept

If you remember nothing else from this pattern, remember: use branches and pull requests to safely share and review code before merging.

Common Mistakes

Committing directly to the main branch without creating a feature branch.

This can cause unstable code in the main project and makes it hard to review changes separately.

Always create a new branch for your changes before committing.

Pushing changes without a clear commit message.

It makes it hard for reviewers to understand what was changed and why.

Write clear, concise commit messages describing your changes.

Not fetching and checking out the pull request branch locally before reviewing.

You miss the chance to test and inspect the code properly before approving.

Fetch the pull request branch and check it out locally to review and test.

Summary

Create a new branch to work on your feature or fix.

Commit your changes with clear messages and push the branch to the remote repository.

Fetch and check out pull request branches locally to review and test code before merging.

Practice

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