Pull request process in Git - Commands & Configuration

Introduction

When multiple people work on the same code, changes need to be reviewed before joining the main project. The pull request process helps teams review, discuss, and approve code changes safely before adding them to the main codebase.

When you finish a new feature and want your team to review it before adding it to the main project.

When you fix a bug and want to make sure the fix is correct and does not break anything.

When you want to ask for feedback on your code changes from teammates.

When you want to keep the main project stable by reviewing all changes before merging.

When you want to track the history and discussion of a specific change in the project.

Commands

Create and switch to a new branch named 'feature-login' to work on a new feature without affecting the main code.

Terminal

git checkout -b feature-login

Expected Output

Switched to a new branch 'feature-login'

Stage all changed files to prepare them for committing.

Terminal

git add .

Expected Output

No output (command runs silently)

Save the staged changes with a clear message describing the new login feature.

Terminal

git commit -m "Add login feature with validation"

Expected Output

[feature-login abc1234] Add login feature with validation

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

→

-m - Add a commit message inline

Upload the 'feature-login' branch to the remote repository so others can see and review your changes.

Terminal

git push origin feature-login

Expected Output

Enumerating objects: 10, done.

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

Delta compression using up to 4 threads

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

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

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

remote: 

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

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

remote: 

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

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

Switch back to the main branch to prepare for merging the approved changes.

Terminal

git checkout main

Expected Output

Switched to branch 'main'

Your branch is up to date with 'origin/main'.

Update your local main branch with the latest changes from the remote repository to avoid conflicts.

Terminal

git pull origin main

Expected Output

Already up to date.

Merge the reviewed feature branch into the main branch to include the new login feature.

Terminal

git merge feature-login

Expected Output

Updating abc1234..def5678

Fast-forward

 login.py | 20 ++++++++++++++++++++

 1 file changed, 20 insertions(+)

Push the updated main branch with the new feature to the remote repository so everyone can use it.

Terminal

git push origin main

Expected Output

Enumerating objects: 5, done.

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

Delta compression using up to 4 threads

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

Writing objects: 100% (3/3), 350 bytes | 350.00 KiB/s, done.

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

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

   abc1234..def5678  main -> main

Key Concept

If you remember nothing else from this pattern, remember: use a separate branch for your changes, push it, create a pull request for review, then merge only after approval.

Common Mistakes

Committing changes directly to the main branch without using a feature branch.

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

Always create a new branch for your work before making changes.

Not pulling the latest changes from main before merging your feature branch.

This can cause merge conflicts or overwrite others' work.

Run 'git pull origin main' to update your local main branch before merging.

Pushing changes without a clear commit message.

It makes it hard for others to understand what your changes do during review.

Write clear, descriptive commit messages explaining your changes.

Summary

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

Commit and push your changes to the remote repository.

Open a pull request for your team to review the changes.

After approval, merge the feature branch into the main branch.

Keep your main branch updated by pulling latest changes before merging.

Practice

1. What is the main purpose of a pull request in Git?

easy

A. To ask your team to review and merge your code changes

B. To delete a branch from the repository

C. To create a new branch locally

D. To clone a repository to your computer

Solution

1. Step 1: Understand the role of a pull request

   A pull request is a request to merge code changes and get feedback from the team.

2. Step 2: Identify the correct purpose

   Options B, C, and D describe other Git actions unrelated to pull requests.

3. Final Answer:

   To ask your team to review and merge your code changes -> Option A

4. Quick Check:

   Pull request = code review request [OK]

Hint: Pull request means asking for code review and merge [OK]

Common Mistakes:

• Confusing pull request with branch creation
• Thinking pull request deletes branches
• Mixing pull request with cloning repositories

2. Which Git command is used to upload your local branch to the remote repository before creating a pull request?

easy

A. git clone origin branch-name

B. git pull origin branch-name

C. git push origin branch-name

D. git fetch origin branch-name

Solution

1. Step 1: Identify the command to upload local changes

   The git push command sends local commits to the remote repository.

2. Step 2: Match the correct syntax

   git push origin branch-name uploads the specified branch to the remote named origin.

3. Final Answer:

   git push origin branch-name -> Option C

4. Quick Check:

   Push = upload branch to remote [OK]

Hint: Push uploads your branch to remote before pull request [OK]

Common Mistakes:

• Using git clone instead of git push
• Confusing git pull with git push
• Using git fetch which only downloads data

3. After pushing your branch and creating a pull request, what is the expected output when you run git status on your local branch?

medium

A. On branch feature-xyz
nothing to commit, working tree clean

B. On branch feature-xyz
your branch is ahead of 'origin/feature-xyz' by 1 commit

C. On branch main
nothing to commit, working tree clean

D. On branch feature-xyz
You have unmerged paths.

Solution

1. Step 1: Understand the state after pushing and creating pull request

   After pushing, local and remote branches are synced, so no new commits locally.

2. Step 2: Interpret git status output

   "nothing to commit, working tree clean" means no changes locally; branch is up to date.

3. Final Answer:

   On branch feature-xyz nothing to commit, working tree clean -> Option A

4. Quick Check:

   Clean status means local branch matches remote [OK]

Hint: Clean git status means branch is synced after push [OK]

Common Mistakes:

• Thinking branch is ahead after push
• Confusing branch names
• Expecting unmerged paths without conflicts

4. You created a pull request but forgot to push your latest commit. What error will you most likely see when trying to create the pull request?

medium

A. Pull request created successfully with all commits

B. Error: No commits found on branch to compare

C. Merge conflict detected automatically

D. Remote branch does not exist

Solution

1. Step 1: Understand the pull request creation process

   A pull request compares your remote branch with the base branch.

2. Step 2: Identify the error when branch is not pushed

   If you forget to push, the remote branch does not exist, causing an error.

3. Final Answer:

   Remote branch does not exist -> Option D

4. Quick Check:

   Pull request needs remote branch [OK]

Hint: Push branch first or remote branch won't exist [OK]

Common Mistakes:

• Assuming pull request works without pushing
• Expecting merge conflict before push
• Ignoring remote branch creation step

5. You want to ensure your pull request is merged only after at least two team members approve it. Which GitHub feature should you configure?

hard

A. Enable auto-merge without reviews

B. Branch protection rules with required reviews set to 2

C. Use git rebase to combine commits

D. Create a new branch for each reviewer

Solution

1. Step 1: Identify how to enforce review requirements

   GitHub branch protection rules allow setting required number of reviewers before merge.

2. Step 2: Match the feature to the requirement

   Setting required reviews to 2 ensures at least two approvals before merging.

3. Final Answer:

   Branch protection rules with required reviews set to 2 -> Option B

4. Quick Check:

   Branch protection = enforce review count [OK]

Hint: Use branch protection rules to require reviews [OK]

Common Mistakes:

• Confusing auto-merge with review enforcement
• Thinking git rebase controls reviews
• Creating branches per reviewer is unnecessary