How Pull Request Uplifting Works Between Brave Release Channels

Pull request uplifting is the process of cherry-picking commits from the Dev (Nightly) channel to the Beta or Release branches to propagate critical fixes without merging entire feature sets.

The brave/brave-browser repository manages three distinct release tracks to balance rapid innovation with production stability. Understanding how pull request uplifting operates between these channels is essential for contributors who need to ship bug fixes or security patches to users on Beta or Release builds without waiting for the next full development cycle.

Understanding Brave’s Three Release Channels

Brave browser maintains parallel development tracks mapped to specific Git branches and milestones:

• Dev (Nightly) – Built from the master branch, this channel receives every merged change and serves developers and early adopters.
• Beta – Tracked by the beta branch and associated with a beta milestone, this channel receives changes that have passed initial stabilization.
• Release – Tracked by the release branch and associated with a release milestone, this channel delivers fully tested builds to the general public.

When a change lands on Dev but must reach Beta or Release users, contributors initiate an uplift to promote the commit upstream.

What Is Pull Request Uplifting?

Pull request uplifting is the selective promotion of code changes from a lower stability channel to a higher one. Unlike merging entire branch histories, uplifting uses git cherry-pick to apply only specific commits, ensuring that experimental features remain in Dev while critical fixes propagate to Release.

This workflow is documented in the repository’s CONTRIBUTING.md and detailed further in the Uplifting Wiki (Uplifting-a-pull-request.md), which provides the canonical procedure for contributors.

The Uplifting Workflow Step-by-Step

The uplifting process follows a strict protocol defined in the .github/PULL_REQUEST_TEMPLATE.md and enforced by the @brave/uplift-approvers team specified in CODEOWNERS.

Identify the Original PR

Uplifting begins only after a pull request has been merged to master and its associated issue is closed with a milestone set to the Dev channel. The commit SHA from this merge serves as the source for cherry-picking.

Create the Uplift Pull Request

Authors create a new branch targeting the next higher channel branch (beta or release). If a fix must skip Beta entirely, the base branch can be set directly to release.

Cherry-Pick Commits to the Target Branch

The uplift PR contains the exact diff produced by cherry-picking the original Dev commit:

# Checkout the target channel branch (beta in this example)

git fetch origin
git checkout beta
git pull origin beta

# Cherry-pick the commit from the Dev PR

git cherry-pick <SHA>

# Resolve conflicts if necessary, then push

git checkout -b uplift/<issue-number>-to-beta
git push origin uplift/<issue-number>-to-beta

Apply Required Labels and Metadata

Every uplift PR must include specific labels defined in the issue templates (.github/ISSUE_TEMPLATE/*.yml) and enforced by the PR template:

• Channel label: beta or release
• QA status: QA/Yes or QA/No
• Release notes: release-notes/include or release-notes/exclude

The PR description must reference the original issue with Resolves #<issue-number> to maintain traceability.

Review, QA, and Merge

Reviewers execute the same test matrix as standard PRs: unit tests, lint checks, and gn build verification. The After-merge Checklist requires updating the issue milestone to reflect the channel that now contains the change (e.g., changing from Dev to Beta).

Once approved, the uplift PR merges into the target branch. The change propagates to users on the next build of that channel.

Automation and Ownership

The CODEOWNERS file designates the @brave/uplift-approvers team as owners of uplift-related templates and changelog files, ensuring the correct reviewers are automatically assigned. The .github/PULL_REQUEST_TEMPLATE.md enforces the uplift checklist, preventing merges that lack required labels or security review.

When Uplifting Does Not Apply

Not all changes qualify for uplifting:

• Security-critical fixes follow a separate back-porting process with dedicated security review rather than the standard uplift workflow.
• Dev-only changes marked as experimental or feature-flagged for Nightly remain confined to the master branch and are never uplifted to Beta or Release.

Summary

• Brave maintains three channels—Dev (master), Beta (beta), and Release (release)—each mapped to distinct milestones.
• Pull request uplifting promotes specific commits from lower channels to higher ones using git cherry-pick, avoiding full branch merges.
• Contributors create new uplift PRs targeting beta or release, apply mandatory labels (QA/Yes, release-notes/include, channel tags), and complete the checklist in .github/PULL_REQUEST_TEMPLATE.md.
• The @brave/uplift-approvers team owns the process via CODEOWNERS, while CONTRIBUTING.md and the Uplifting Wiki provide canonical guidance.

Frequently Asked Questions

What is the difference between uplifting and backporting?

Uplifting is Brave’s specific workflow for moving fixes from Dev to Beta or Release through standard pull requests with cherry-picked commits. Backporting typically refers to security-critical fixes that bypass the standard uplift process and follow a separate security review track to ensure immediate propagation without exposing vulnerabilities in public PRs.

Can I uplift a PR directly from Dev to Release without going through Beta?

Yes. While the standard flow moves changes sequentially from Dev to Beta to Release, you can create an uplift PR that targets the release branch directly if a fix is urgent enough to skip the Beta channel. The same labeling requirements and cherry-pick procedure apply regardless of whether you target beta or release.

Who approves uplift requests in the brave/brave-browser repository?

The @brave/uplift-approvers team, defined in the CODEOWNERS file, owns all uplift-related templates and changelog files. These approvers ensure that uplift PRs meet the required checklist items, including proper labels (QA/Yes, release-notes/include), security review status, and milestone updates before merging into beta or release branches.

What happens if a cherry-pick conflicts during the uplifting process?

If git cherry-pick produces conflicts, the contributor must resolve them manually before pushing the uplift branch. The resolution should maintain the original fix’s intent while adapting to any code differences between the Dev and target channel branches. After resolving, the contributor completes the push and opens the uplift PR, noting any non-trivial merge conflicts in the description for reviewers.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}