What is a Pull Request (PR)?

A Pull Request (PR) is a request to merge changes from one branch into another branch. It provides a structured way for team members to review, discuss, test, and approve code before it is merged into the target branch.

Pull Requests are a key collaboration feature in platforms such as:

  • GitHub
  • GitLab
  • Bitbucket

They help improve code quality by ensuring that every change is reviewed and validated before becoming part of the shared codebase.

Advertisement

Interview Answer

"A Pull Request (PR) is a request to merge changes from one branch into another. It allows team members to review the code, discuss improvements, run automated tests through CI/CD pipelines, and approve the changes before merging. In my projects, every feature or bug fix is submitted through a Pull Request to ensure code quality and collaboration."

Why Use Pull Requests?

Pull Requests provide several benefits:

  • Peer code reviews
  • Better collaboration
  • Automated testing
  • Improved code quality
  • Knowledge sharing
  • Controlled code integration

Typical Pull Request Workflow

 
Feature Branch
       │
       ▼
Create Pull Request
       │
       ▼
Code Review
       │
       ▼
CI/CD Builds & Tests
       │
       ▼
Address Review Comments
       │
       ▼
Approval
       │
       ▼
Merge into Main
 

Pull Request Process

1. Create a Feature Branch

Develop your feature or bug fix in a separate branch.

2. Push the Branch

 
git push origin feature/login-page
 

3. Raise a Pull Request

Select:

  • Source Branch
  • Target Branch

Provide:

  • Title
  • Description
  • Related Jira ticket (if applicable)

4. Code Review

Team members:

  • Review the code
  • Suggest improvements
  • Request changes if necessary

5. Automated Testing

CI/CD pipelines execute:

  • Build
  • Unit Tests
  • Integration Tests
  • Static Code Analysis

6. Approval

Once reviewers approve and all checks pass, the Pull Request is ready to merge.

7. Merge

The approved Pull Request is merged into the target branch.

Best Practices

  • Keep Pull Requests small and focused.
  • Write clear PR titles and descriptions.
  • Link related Jira or issue tracker IDs.
  • Resolve review comments promptly.
  • Ensure all CI/CD checks pass before merging.

Real-Time Example

In my project, every feature was developed in its own feature branch. After completing development, I raised a Pull Request to the develop branch. Jenkins automatically executed the build and API automation suite. Team members reviewed the code, suggested minor improvements, and after approval, the Pull Request was merged.

Pull Request vs Merge Request

Although the names differ, Pull Request and Merge Request perform the same function.

Comparison

Platform Terminology
GitHub Pull Request (PR)
Bitbucket Pull Request (PR)
GitLab Merge Request (MR)

Purpose

Both are used to:

  • Submit code changes
  • Review code
  • Discuss improvements
  • Run automated tests
  • Merge changes into another branch

Interview Answer

"There is no functional difference between a Pull Request and a Merge Request. GitHub and Bitbucket use the term Pull Request, while GitLab calls it a Merge Request. Both represent the same code review and merge process."

What Happens After You Raise a Pull Request?

Creating a Pull Request starts a collaborative workflow involving developers and CI/CD systems.

Typical Workflow

1. Notification

Reviewers receive notifications about the new Pull Request.

2. Automated Checks

CI/CD pipelines automatically execute:

  • Build
  • Unit Tests
  • Integration Tests
  • Static Code Analysis
  • Security Scans (if configured)

3. Code Review

Reviewers verify:

  • Logic
  • Coding standards
  • Performance
  • Security
  • Readability

4. Address Feedback

The author updates the code by pushing additional commits to the same Pull Request.

5. Approval

Once reviewers approve and all checks succeed, the Pull Request is approved.

6. Merge

The Pull Request is merged into the target branch.

Pull Request Lifecycle

 
Create PR
     │
     ▼
Notification
     │
     ▼
CI/CD Builds
     │
     ▼
Code Review
     │
     ▼
Address Comments
     │
     ▼
Approval
     │
     ▼
Merge
 

Real-Time Example

In our project, after a Pull Request was created, Jenkins automatically triggered the API automation suite. Team members reviewed the implementation, requested a few improvements, and once all checks passed, the Pull Request was merged into the develop branch.

How to Review and Approve a Pull Request

Reviewing a Pull Request ensures that only high-quality code enters the shared repository.

Interview Answer

"While reviewing a Pull Request, I first understand the business requirement, then review the code changes line by line, verify coding standards, ensure sufficient testing has been performed, and finally approve the Pull Request if it meets the project's quality standards."

Review Process

Read the Description

Understand:

  • Business requirement
  • Jira ticket
  • Scope of changes

Review the Code

Check for:

  • Logic errors
  • Coding standards
  • Performance
  • Security
  • Readability

Verify Testing

Ensure:

  • Unit tests
  • API tests
  • UI tests (if applicable)

have been added or updated.

Verify Documentation

Confirm documentation has been updated where necessary.

Comment

Suggest improvements or request modifications.

Approve

Approve the Pull Request after verifying:

  • Code quality
  • Test coverage
  • Successful CI/CD execution

Review Workflow

 
Read PR
     │
     ▼
Review Code
     │
     ▼
Verify Tests
     │
     ▼
Comment
     │
     ▼
Approve
 

Best Practices

  • Review small Pull Requests.
  • Focus on readability.
  • Verify business logic.
  • Check test coverage.
  • Give constructive feedback.

CI/CD Integration (Jenkins & GitHub Actions)

Git integrates with Continuous Integration tools to automate builds and testing.

Whenever code is pushed or a Pull Request is created, the CI tool automatically executes predefined workflows.

Interview Answer

"In my projects, Git integrates with Jenkins and GitHub Actions to automatically build the application, execute automated tests, and report the build status whenever code is pushed or a Pull Request is created."

CI Workflow

 
Push Code
      │
      ▼
Pull Request
      │
      ▼
CI Trigger
      │
      ▼
Build
      │
      ▼
Run Tests
      │
      ▼
Report Status
 

Jenkins

Jenkins can trigger builds by:

  • Webhooks
  • Repository polling

It performs:

  • Code checkout
  • Build
  • Test execution
  • Deployment

GitHub Actions

GitHub Actions stores workflow files inside:

 
.github/workflows/
 

Workflows automatically execute when events occur such as:

  • Push
  • Pull Request
  • Merge

Benefits

  • Automated builds
  • Early bug detection
  • Continuous testing
  • Faster feedback
  • Stable main branch

Branch Protection Rules

Branch Protection Rules prevent accidental or unauthorized changes to important branches.

Commonly protected branches include:

  • main
  • master
  • develop

Interview Answer

"I configure branch protection rules to require Pull Request reviews, successful CI/CD status checks, signed commits where applicable, and to prevent direct pushes to the main branch."

Configure Branch Protection

Navigate to:

 
Repository

Settings

Branches

Branch Protection Rules
 

Common Protection Rules

  • Require Pull Request reviews
  • Require status checks to pass
  • Require signed commits
  • Enforce linear history
  • Restrict direct pushes
  • Restrict force pushes

Branch Protection Workflow

 
Developer
      │
      ▼
Create PR
      │
      ▼
Review Required
      │
      ▼
CI/CD Pass
      │
      ▼
Approval
      │
      ▼
Merge Allowed
 

Benefits

  • Protects important branches
  • Prevents accidental commits
  • Improves code quality
  • Enforces team standards
  • Supports CI/CD

The .gitignore File

A .gitignore file specifies which files and directories Git should ignore and not track.

It prevents unnecessary or sensitive files from being committed to the repository.

Interview Answer

"A .gitignore file tells Git which files or folders should not be tracked. It is commonly used to exclude build outputs, log files, temporary files, dependency folders, and environment configuration files from version control."

Common Files Ignored

  • Build directories
  • Log files
  • Temporary files
  • Environment files
  • IDE configuration
  • Dependency folders

Example

 
target/
node_modules/
logs/
*.log
.env
.idea/
*.class
 

Why Use .gitignore?

It helps:

  • Keep repositories clean
  • Prevent accidental commits
  • Exclude generated files
  • Protect sensitive configuration
  • Reduce repository size

Real-Time Example

In our Java automation framework, the .gitignore file excluded the target directory, log files, IDE configuration folders, and environment-specific configuration files. This ensured that only source code and project configuration were committed to Git.

Frequently Asked Questions (FAQs)

1. What is a Pull Request (PR)?

A Pull Request is a request to merge changes from one branch into another.

It enables:

  • Code review
  • Team discussion
  • Automated testing
  • Approval
  • Controlled merging

before changes become part of the target branch.

2. What is the difference between a Pull Request and a Merge Request?

There is no functional difference.

The terminology depends on the platform:

  • GitHub → Pull Request (PR)
  • Bitbucket → Pull Request (PR)
  • GitLab → Merge Request (MR)

Both provide the same code review and merge workflow.

3. What happens after you raise a Pull Request?

After creating a Pull Request:

  1. Team members receive notifications.
  2. CI/CD pipelines execute builds and tests.
  3. Reviewers examine the code.
  4. The author addresses feedback.
  5. Required approvals are obtained.
  6. The Pull Request is merged into the target branch.

4. How do you review and approve a Pull Request?

A proper Pull Request review includes:

  • Reading the PR description
  • Reviewing code changes
  • Verifying coding standards
  • Checking test coverage
  • Confirming documentation updates
  • Providing comments or requesting changes
  • Approving the Pull Request once it satisfies project quality standards

5. How does Git integrate with Jenkins and GitHub Actions?

Whenever code is pushed or a Pull Request is created:

  • The CI tool detects the event.
  • The latest code is checked out.
  • The project is built.
  • Automated tests are executed.
  • Build results are reported back to the Pull Request.

Jenkins typically uses webhooks or polling, while GitHub Actions uses workflow files stored under .github/workflows.

6. How do you configure Branch Protection Rules?

In GitHub:

  1. Open the repository.
  2. Navigate to Settings → Branches.
  3. Create or edit a Branch Protection Rule.
  4. Configure options such as:
    • Require Pull Request reviews
    • Require successful status checks
    • Require signed commits
    • Enforce linear history
    • Restrict direct pushes

These rules protect important branches from accidental or unauthorized changes.

7. What is a .gitignore file?

A .gitignore file specifies which files and folders Git should ignore.

Common examples include:

  • Build output directories
  • Log files
  • Temporary files
  • Environment configuration files
  • IDE configuration folders
  • Dependency folders such as node_modules

Using a .gitignore file keeps the repository clean, prevents unnecessary files from being committed, and protects generated or sensitive content from version control.