GitHub Pull Request (PR) and PR Workflow

What is a Pull Request?

A Pull Request (PR) is a GitHub feature used to propose changes from one branch and request that those changes be reviewed and merged into another branch.

For example, you develop a login feature in:

feature/login

and want to merge it into:

main

Instead of directly merging:

git switch main
git merge feature/login

in a team environment, you typically push the feature branch and create a Pull Request:

feature/login
      ↓
Pull Request
      ↓
Code Review
      ↓
Approval
      ↓
Merge
      ↓
main

A PR does not itself mean the code has already been merged. It is a proposal and collaboration/review point before merging.

Why is a Pull Request Used?

Pull Requests provide a controlled process for integrating code into important branches such as main.

1. Code Review

Other developers can review your changes before they are merged.

For example:

Developer A
    ↓
Creates PR
    ↓
Developer B reviews
    ↓
Comments / Suggestions

The reviewer may identify:

• Bugs
• Security problems
• Performance issues
• Coding-standard problems
• Missing tests
• Better implementation approaches

2. Team Discussion

Reviewers can comment on specific lines of code.

For example:

public async Task<User> GetUser(int id)
{
    // Reviewer may suggest handling the not-found case
}

The developer can update the branch based on the feedback.

3. Automated CI Validation

A Pull Request can trigger GitHub Actions.

For example:

Create PR
   ↓
GitHub Actions
   ↓
Build
   ↓
Unit Tests
   ↓
Security / Quality Checks
   ↓
Pass / Fail

This helps prevent broken code from being merged.

4. Approval Process

Organizations can configure branch protection/rules so that main cannot be modified without required checks or reviews.

For example:

Pull Request
     ↓
Build passed?
     ↓
Tests passed?
     ↓
Reviewer approved?
     ↓
Merge allowed

5. Traceability

A PR records useful information such as:

• Who made the changes
• What changed
• Why it changed
• Review comments
• Approvals
• Related issues
• CI results

This is valuable in enterprise development.

Typical Pull Request Workflow

Suppose you need to implement a login feature.

Step 1: Update main

Start with the latest code:

git switch main
git pull

Step 2: Create a Feature Branch

git switch -c feature/login

Now:

main
 |
 A --- B
       \
        feature/login

Step 3: Develop the Feature

Modify your files.

Check:

git status

Stage the changes:

git add .

Commit:

git commit -m "Add login functionality"

You may make multiple commits:

main
A --- B
      \
       C --- D --- E
            feature/login

Step 4: Push the Feature Branch

git push -u origin feature/login

Now:

Local
feature/login
      |
      | git push
      ↓
GitHub
feature/login

Step 5: Create a Pull Request

On GitHub, create a PR:

Base branch:
main

Compare branch:
feature/login

This means:

Merge the changes from feature/login into main.

You normally provide:

Title:
Add user login functionality

Description:
- Added login endpoint
- Added validation
- Added unit tests

Step 6: CI Pipeline Runs

The PR may automatically trigger GitHub Actions:

PR Created
    ↓
Restore
    ↓
Build
    ↓
Test
    ↓
Code/quality checks

If something fails:

Test Failed
    ↓
Fix code
    ↓
Commit
    ↓
Push
    ↓
PR automatically updates
    ↓
CI runs again

You generally don't need to create a new PR for every correction.

Step 7: Code Review

Reviewer checks the changes:

PR
 ↓
Reviewer
 ↓
Review code

The reviewer may:

Approve

or

Comment

or

Request changes

If changes are requested, update your same feature branch:

git add .
git commit -m "Address PR review comments"
git push

GitHub automatically updates the existing Pull Request.

Step 8: Approval

Once:

Code looks correct
        +
CI checks passed
        +
Required approvals received

the PR becomes eligible for merging, subject to the repository's rules.

Step 9: Merge the Pull Request

The PR is merged into main.

Conceptually:

feature/login
      ↓
     PR
      ↓
Review + CI
      ↓
    Merge
      ↓
     main

GitHub commonly supports merge strategies such as:

Merge commit
Squash and merge
Rebase and merge

Which one is used depends on the team's Git strategy.

Step 10: Delete the Feature Branch

After the PR is successfully merged, the feature branch is usually no longer required.

The remote branch can be deleted through GitHub.

Locally:

git switch main
git pull
git branch -d feature/login

Now your local main contains the merged feature.

Complete PR Workflow

Requirement / Issue
        ↓
Update main
        ↓
Create Feature Branch
        ↓
Develop
        ↓
Commit
        ↓
Push Feature Branch
        ↓
Create Pull Request
        ↓
Automated CI Checks
        ↓
Code Review
        ↓
Changes requested?
    ↓           ↓
   Yes          No
    ↓            ↓
Fix + Push    Approval
    ↓            ↓
PR Updated ←─────┘
        ↓
Merge PR
        ↓
main
        ↓
Delete Feature Branch

Simple Command Flow

# Get latest main
git switch main
git pull

# Create feature branch
git switch -c feature/login

# Develop and commit
git add .
git commit -m "Add login functionality"

# Push branch
git push -u origin feature/login

Then on GitHub:

Create PR
   ↓
Review
   ↓
CI checks
   ↓
Approval
   ↓
Merge

Finally:

git switch main
git pull
git branch -d feature/login

Key Points

• PR = Pull Request.
• A PR proposes merging changes from one branch into another.
• PRs are commonly used to protect important branches such as main.
• PRs enable code review and team discussion.
• CI/CD checks can run automatically against a PR.
• Reviewers can approve, comment, or request changes.
• Additional commits pushed to the source branch automatically update the existing PR.
• After approval and successful required checks, the PR can be merged.
• The feature branch is commonly deleted after successful merge.
• Pull Requests are a GitHub collaboration feature, not a core git command.

Interview Answer

A Pull Request is a GitHub feature used to propose changes from one branch to another, usually from a feature branch into main. It allows the team to review the code, discuss changes, run automated CI checks, and approve the changes before merging. A typical workflow is: create a feature branch, develop and commit, push the branch, create a PR, run CI checks, perform code review, address comments, get approval, merge the PR, and then delete the feature branch.