Azure Repos – Pull Request (PR) and Code Review Workflow

1. What is a Pull Request?

A Pull Request (PR) is a request to review and merge code changes from one Git branch into another.

In Azure Repos, developers use Pull Requests to ensure that code changes are reviewed, validated, and approved before merging into important branches such as develop or main.

Simple example

Suppose you are developing an ASP.NET Core Web API application.

You have two branches:

• main – Contains production-ready code.

• feature/customer-api – Contains new Customer API functionality.

After completing the Customer API, you want to merge your changes into main.

Instead of merging directly, you create a Pull Request.

The team reviews your code, suggests improvements, and approves it. Once all required policies are satisfied, the changes can be merged.

Important: A Pull Request does not automatically merge code. It starts the review and approval process.

2. Why do we need Pull Requests?

Real-time scenario

Consider a banking application where a developer modifies the fund transfer calculation.

Without a Pull Request, incorrect logic might be merged directly into the production branch.

With a Pull Request, the reviewer can check:

• Whether the business logic is correct.

• Whether authentication and authorization are implemented.

• Whether proper exception handling is available.

• Whether SQL queries are optimized.

• Whether unit tests cover the changes.

This helps identify issues before code reaches production.

3. Typical Azure Repos Pull Request Workflow

Let's understand each step using a practical example.

4. Step-by-Step Pull Request Workflow

Step 1: Create a feature branch

First, the developer creates a separate branch from develop.

git switch develop

git pull origin develop

git switch -c feature/customer-api

Explanation:

• git switch develop – Switches to the development branch.

• git pull origin develop – Updates the local development branch.

• git switch -c – Creates and switches to a new feature branch.

The developer can now work independently without directly modifying develop.

Step 2: Develop and commit changes

The developer implements the Customer API.

Example:

[HttpGet("{id}")]
public async Task<IActionResult> GetCustomer(int id)
{
    var customer = await _customerService.GetByIdAsync(id);

    if (customer == null)
        return NotFound();

    return Ok(customer);
}

After completing development:

git add .

git commit -m "Implemented Customer GET API"

The changes are now committed to the local feature branch.

Step 3: Push the feature branch to Azure Repos

git push -u origin feature/customer-api

This uploads the branch and its commits to Azure Repos and configures the upstream tracking branch.

Other team members can now access the branch according to their repository permissions.

Step 4: Create a Pull Request in Azure DevOps

Open Azure DevOps and navigate to:

Project → Repos → Pull requests → New pull request

Configure the following information:

Click Create.

Azure Repos creates the Pull Request, allowing reviewers to inspect the proposed changes.

Step 5: Code review

Assigned reviewers examine the code changes.

They may check:

1. Code quality: Naming conventions, SOLID principles, and maintainability.

2. Business logic: Whether the implementation satisfies requirements.

3. Security: Authentication, authorization, input validation, and sensitive data handling.

4. Performance: Database queries, unnecessary loops, and resource usage.

5. Error handling: Appropriate exceptions, logging, and HTTP responses.

6. Testing: Unit tests and integration tests.

Example review comment

Suppose the developer writes:

var customer = await _db.Customers
    .FirstOrDefaultAsync(x => x.Id == id);

The reviewer may suggest:

Since this is a read-only operation, consider using AsNoTracking() to avoid unnecessary EF Core change tracking.

The developer updates the code:

var customer = await _db.Customers
    .AsNoTracking()
    .FirstOrDefaultAsync(x => x.Id == id);

Then commits and pushes the changes:

git add .

git commit -m "Improved Customer query performance"

git push

The new commit automatically appears in the existing Pull Request. The developer does not need to create another PR.

5. Pull Request Review Decisions

Azure Repos allows reviewers to provide different review votes.

Important: A review vote is different from completing a Pull Request. A PR can be merged only when required policies and permissions allow completion.

For example, if the branch policy requires two approvals, a single approval is insufficient.

6. Build Validation During Pull Requests

Azure Repos can integrate with Azure Pipelines to validate proposed code changes automatically.

How it works

Developer Creates PR
        ↓
Azure Pipeline Runs
        ↓
Restore NuGet Packages
        ↓
Build Application
        ↓
Run Unit Tests
        ↓
Publish Validation Result
        ↓
PR Can Proceed if Policies Pass

For example, suppose the developer introduces a compilation error.

var customer = await _customerService.GetByIdAsync(id)

The missing semicolon causes the build to fail.

If a required build validation policy is configured, Azure Repos prevents normal PR completion until the validation succeeds.

Key point

For Azure Repos Git repositories, PR build validation is typically configured through Branch Policies → Build Validation. It is not automatically enabled merely because a YAML pipeline exists.

7. Branch Policies in Pull Requests

Branch policies define the conditions that must be satisfied before a Pull Request can be completed.

For example, a company may configure the following policies for main:

Example

Pull Request Created
         ↓
Two Reviewers Approved?
         ↓ Yes
Build Validation Passed?
         ↓ Yes
Required Comments Resolved?
         ↓ Yes
Linked Work Item Available?
         ↓ Yes
Merge Allowed

If a required condition is not satisfied, the PR cannot be completed through the normal policy-enforced workflow.

Users with appropriate bypass permissions may be able to override policies, depending on the organization's configuration.

8. Completing and Merging a Pull Request

After reviewers approve the changes and required validation passes, the developer or authorized team member can complete the Pull Request.

Azure Repos supports several merge strategies.

Example: Squash merge

Suppose the feature branch contains:

Commit 1: Added Customer Controller
Commit 2: Added Customer Service
Commit 3: Fixed Validation
Commit 4: Fixed Code Review Comments

With squash merge, these changes appear as one new commit on the target branch:

Commit: Implemented Customer API

This keeps the target branch history concise.

Other completion options

Azure Repos also supports options such as:

• Delete source branch: Remove the remote feature branch after merging.

• Complete associated work items: Update linked Azure Boards work items when the PR completes.

• Auto-complete: Complete the PR automatically after required conditions are satisfied.

9. What happens if a merge conflict occurs?

Suppose two developers modify the same method.

Developer A changes:

return Ok(customer);

Developer B changes:

return Ok(new { Data = customer });

When Git cannot automatically reconcile the changes, a merge conflict occurs.

One common resolution approach is to update the feature branch locally:

git switch feature/customer-api

git fetch origin

git merge origin/develop

Resolve the conflicting files in Visual Studio 2026, then execute:

git add .

git commit

git push

The updated feature branch is reflected in the existing Pull Request.

Important: Resolve the conflict based on the required business logic rather than automatically accepting one side.

10. Pull Request vs Git Merge

Interview point: A Pull Request is a controlled process for proposing and reviewing changes. Git merge is one of the underlying mechanisms used to integrate code.

11. Advantages and Disadvantages

Advantages

• Improves code quality through peer review.

• Reduces the risk of unreviewed changes reaching production.

• Supports automated build and test validation.

• Encourages knowledge sharing between developers.

• Provides traceability between code changes and work items.

• Helps enforce development standards.

Disadvantages

• Reviews may delay development if reviewers are unavailable.

• Large Pull Requests can be difficult to review.

• Merge conflicts may require additional effort.

• Excessive approval requirements can slow delivery.

Best practice: Keep Pull Requests focused, reasonably small, and easy to review.

12. Important Interview Questions and Answers

Q1. What is a Pull Request in Azure Repos?

A Pull Request is a request to review and merge changes from one Git branch into another. It supports code review, approvals, branch policies, and build validation.

Q2. Who creates a Pull Request?

Usually, the developer who implements the feature or bug fix creates the Pull Request after pushing their changes to Azure Repos.

Q3. Can we create a Pull Request without committing code?

A PR needs source and target branches with changes to propose. Normally, developers commit and push changes to a remote feature branch before creating the PR.

Q4. What happens if a reviewer rejects the PR?

The developer addresses the concerns, commits the required changes, and pushes them to the same branch. The reviewer can then review the updated PR.

Q5. What happens if build validation fails?

If build validation is required by branch policy, normal PR completion is blocked until the build succeeds or an authorized bypass is used.

Q6. What is the difference between Approve and Complete?

Approve is a reviewer's vote accepting the proposed changes. Complete is the action that integrates the changes into the target branch.

Q7. Can we automatically merge a PR after approval?

Yes. Azure Repos supports Auto-complete, which completes the PR when all required conditions are satisfied.

Q8. Can we delete the feature branch after merging?

Yes. Azure Repos provides an option to delete the remote source branch when completing the Pull Request.

Q9. What happens if the target branch changes while a PR is under review?

Azure Repos reevaluates the PR against the updated target branch. Additional validation may run, and merge conflicts may need to be resolved.

Q10. Is a Pull Request mandatory in Azure Repos?

No. Developers with sufficient permissions may push or merge directly. However, organizations commonly enforce Pull Requests through branch policies and permissions for important branches.

13. Real-Time Interview Scenario

Question: Explain how you manage Pull Requests and code reviews in your ASP.NET Core project using Azure Repos.

Sample answer:

In our project, we use Azure Repos with Git for source control. Developers create separate feature branches from the develop branch.

Once development and local testing are completed, developers commit and push their changes to Azure Repos and create a Pull Request targeting develop.

We follow a code-review process where senior developers or technical leads review the implementation, business logic, security, performance, and coding standards.

We configure branch policies requiring reviewer approvals, successful build validation, and resolution of review comments.

If reviewers suggest changes, the developer updates the same feature branch, commits the corrections, and pushes them. The existing Pull Request is automatically updated.

After the required approvals and validations are completed, the Pull Request is merged into develop. Azure Pipelines then runs the configured CI process to build and test the application.

This approach helps us maintain code quality, enforce development standards, and protect shared branches.

14. Key Points to Remember

• Pull Request: Request to review and merge changes.

• Source branch: Branch containing the proposed changes.

• Target branch: Branch receiving the changes.

• Reviewer: Developer responsible for reviewing the code.

• Approval: Reviewer's acceptance of the changes.

• Branch policy: Rules controlling PR completion.

• Build validation: Automated verification of the proposed code.

• Merge conflict: Changes that Git cannot automatically reconcile.

• Auto-complete: Automatically completes the PR after required conditions pass.

• Squash merge: Combines feature changes into one commit on the target branch.

One-line interview answer: A Pull Request in Azure Repos is a controlled code-review and merge process where developers propose changes from a feature branch, reviewers validate the code, automated builds verify quality, and approved changes are merged into the target branch according to configured branch policies.