Reviewing Pull Request

This page explains how reviewers can evaluate pull requests, request changes, approve them, and handle conflicts before merging.

After creating a pull request (PR), the next step is to review changes before merging. Reviews ensure code quality, detect conflicts early, and enforce team approval workflows.

If no reviewers are added, you can still act as the reviewer yourself and proceed with the review process.

Pull Request Overview Panels

When you open a pull request, the Overview page displays two key panels:

Left Panel – Pull Request Details

This section summarizes the core PR information:

• Status – current state (Created, Review Requested, Changes Requested, Approved).

• Target branch – the branch where changes will be merged.

• Source branch – the branch where changes originate.

• Created by – user who opened the PR.

• Created date – when the PR was first opened.

• Updated date – last activity or change on the PR.

• Description – summary of the changes provided by the PR creator.

This panel gives reviewers and contributors immediate context about the pull request.

Right Panel – Reviewers

This section tracks reviewer assignments and actions:

• Assigned reviewers – list of users added as reviewers.

• Reviewer status – shows if a reviewer is pending, has requested changes, or approved.

• ✏️ Pencil icon – lets you add or update reviewers.

• If no reviewers are assigned, the panel displays “No reviewers.”

This panel is essential for managing and monitoring the review workflow.

Adding Reviewers

1. Open the pull request overview page.

2. Locate the Reviewers panel on the right.

3. Click the ✏️ pencil icon to manage reviewers.

4. In the Reviewers modal, search for users and click Add.

   • Selected reviewers appear at the top.

   • Use the black Add button at the bottom to confirm.

5. Reviewers will now see the PR in their queue.

Reviewing Without Assigned Reviewers

• If no reviewers are added, you as the PR creator (or another user with access) can still review the request.

• Once you review the PR, the status updates to “Review Requested.”

• This allows the workflow to continue even when formal reviewers are not assigned.

Handling Conflicts

When a PR contains conflicting changes with the target branch:

• A banner appears at the top of the Overview page showing the number of files with conflicts.

• The Merge button is disabled until conflicts are resolved.

• Click Resolve conflicts to start fixing them.

⚠️ Conflicts must be resolved before the PR can proceed.

Requesting Changes

Reviewers can request modifications to the PR if they find issues.

1. Go to the Components changed tab.

2. Review the listed components and code changes.

3. Click Request changes.

4. The PR status updates to Changes Requested.

This signals the PR author to update the source branch with required fixes.

Approving a Pull Request

If the changes meet quality standards:

1. Open the PR and review the Overview and Components changed tabs.

2. Click Approve.

3. The PR status updates to Approved, and the PR is ready for merge.

Merging a Pull Request

Once a PR has been reviewed and validated:

1. Go to the pull request overview page.

2. Confirm that the branch is able to merge (green status message).

3. Click the Merge button in the top-right corner.

4. The changes from the source branch are merged into the target branch.

Example

• A developer creates a pull request from FeatureBranch → ReleaseBranch.

• No reviewers are assigned.

• The developer clicks the pencil icon, but skips adding reviewers.

• The developer reviews the changes directly, changing the status to Review Requested.

• The PR shows a conflict banner, so conflicts are resolved.

• A reviewer clicks Request changes, updating the status to Changes Requested.

• After fixes, the reviewer clicks Approve.

• Finally, the developer clicks Merge, integrating the changes into ReleaseBranch.

Best Practices

• Always add at least one reviewer for accountability.

• Use the description field to summarize key changes for reviewers.

• Only merge when all conflicts are resolved and tests have passed.

• Use Request changes instead of blocking silently — it keeps the workflow clear.

• Avoid self-merging without a review unless it’s a critical fix.