Code review in pull requests in Git - Step-by-Step Execution

Process Flow - Code review in pull requests

Developer creates feature branch

↓

Developer makes code changes

↓

Developer pushes branch to remote

↓

Developer opens Pull Request (PR)

↓

Reviewers get notified

↓

Reviewers read code, add comments

↓

Developer addresses comments

↓

Reviewers approve changes?

No→More changes needed

Yes↓

PR merged into main branch

↓

Feature integrated and deployed

This flow shows how a developer creates a pull request, reviewers check the code, request changes if needed, and finally merge the approved code.

Execution Sample

Git

git checkout -b feature-branch
# make code changes
git add .
git commit -m "Add new feature"
git push origin feature-branch
# open PR on GitHub
# reviewers comment and approve
# merge PR

This sequence shows the main git commands and steps to create a pull request and get it reviewed.

Process Table

Step	Action	Result	Next Step
1	Create feature branch	New branch 'feature-branch' created	Make code changes
2	Make code changes	Files modified locally	Stage changes
3	Stage changes (git add .)	Changes staged for commit	Commit changes
4	Commit changes	Commit created with message	Push branch to remote
5	Push branch	Branch pushed to remote repository	Open Pull Request
6	Open Pull Request	PR created and reviewers notified	Reviewers review code
7	Reviewers comment	Comments added to PR	Developer addresses comments
8	Developer updates code	New commits pushed to PR branch	Reviewers re-review
9	Reviewers approve?	If no, back to step 7; if yes, proceed	Merge PR
10	Merge PR	Code merged into main branch	Deploy or continue development
11	End	Feature integrated	Process complete

💡 PR merged after reviewers approve changes, ending the review cycle

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 8	Final
feature-branch	does not exist	created locally	commit added	pushed to remote	updated with new commits	merged into main

Key Moments - 3 Insights

Why do reviewers sometimes ask for changes after the PR is opened?

Reviewers check the code for quality and correctness. If they find issues or improvements, they add comments (see execution_table step 7). The developer then updates the code (step 8) before approval.

What happens if the developer pushes new commits after reviewers comment?

The PR updates with new commits (step 8). Reviewers re-check the changes to ensure all comments are addressed before approving (step 9).

Can the PR be merged without reviewer approval?

Usually no. The flow requires reviewers to approve (step 9) before merging (step 10) to maintain code quality and team agreement.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the developer push the branch to the remote repository?

A Step 5

B Step 4

C Step 6

D Step 7

💡 Hint

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

According to the variable tracker, what is the state of 'feature-branch' after step 8?

A Does not exist

B Created locally

C Updated with new commits

D Pushed to remote

💡 Hint

Look at the 'After Step 8' column for 'feature-branch' in variable_tracker.

If reviewers do not approve the PR at step 9, what is the next step?

A Open a new PR

B Developer addresses comments and updates code

C Merge PR anyway

D Delete the feature branch

💡 Hint

See the 'Next Step' column for step 9 in execution_table.

Concept Snapshot

Code review in pull requests:
- Developer creates and pushes a feature branch
- Opens a PR to propose changes
- Reviewers comment and request changes if needed
- Developer updates code until approval
- PR merged into main branch after approval
- Ensures code quality and team collaboration

Full Transcript

Code review in pull requests is a process where a developer creates a separate branch to work on a feature, then pushes it to a remote repository. They open a pull request (PR) to ask teammates to review their code. Reviewers read the changes and add comments if improvements are needed. The developer updates the code accordingly and pushes new commits. Once reviewers approve, the PR is merged into the main branch, integrating the new feature. This process helps keep code quality high and encourages team collaboration.

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