# How Pull Request Uplifting Works Between Brave Release Channels > Learn how pull request uplifting moves critical fixes between Brave release channels. Understand cherry-picking commits from Dev to Beta or Release branches. - Repository: [Brave Software/brave-browser](https://github.com/brave/brave-browser) - Tags: internals - Published: 2026-02-16 --- **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`](https://github.com/brave/brave-browser/blob/main/CONTRIBUTING.md) and detailed further in the **Uplifting Wiki** ([`Uplifting-a-pull-request.md`](https://github.com/brave/brave-browser/blob/main/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`](https://github.com/brave/brave-browser/blob/main/.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: ```bash # 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 # Resolve conflicts if necessary, then push git checkout -b uplift/-to-beta git push origin uplift/-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 #` 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`](https://github.com/brave/brave-browser/blob/main/.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`](https://github.com/brave/brave-browser/blob/main/.github/PULL_REQUEST_TEMPLATE.md). - The `@brave/uplift-approvers` team owns the process via `CODEOWNERS`, while [`CONTRIBUTING.md`](https://github.com/brave/brave-browser/blob/main/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.