Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Version Control Settings Block for React

A branch protection settings panel with a branch picker, approval and check rules, merge methods and a tester that says whether a pull request would merge and every reason it would not.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show the rules a pull request has to meet and try one against them, with this branch protection settings panel for React with Base UI. A hairline frame with a plus mark on each corner leads with a sentence worked out from the chosen branch ("main needs 2 approvals, passing checks and signed commits. Squash and rebase are allowed. New commits dismiss the approvals."). A Toggle Group picks the branch (main, release/*, develop); its rules are a Switch that protects it (turning it off asks first, in an Alert Dialog that opens on Keep protection), a Segment Group for the required approvals, switches for passing checks, signed commits and dismissing stale approvals, and Checkboxes for the merge methods allowed. Beside them, Would this pull request merge asks for the approvals it has, two toggles (checks passing, commits signed), whether new commits came after the approvals and the method wanted, and answers with a verdict ("Blocked: needs 1 more approval") and every reason under it. Save refuses a protected branch with no merge method; an action foot counts unsaved changes beside a Shine Button. It's built from Toggle Group, Switch, Segment Group, Alert Dialog, Checkbox, Toggle, Button, Shine Button and Guides, with a CSS entrance only. For a code review tool, a Git host's settings or any product that guards a branch.

FAQ

How do I change the branches and their starting rules?

Edit SAVED: each branch has an id, a label, whether it is protected, the approvals it needs, the three switches and the merge methods it allows. METHODS lists the methods and COUNTS the approval choices. The sentence on top, the verdict and the unsaved count are all worked out from those, so a new branch or method shows up in every part.

How is the verdict decided?

It is a pure function of the branch's rule and the pull request, and nothing merges. A protected branch lists every reason a pull request is blocked: too few approvals (counted as none when stale approvals are dismissed and new commits came after them), checks that haven't passed, unsigned commits and a merge method the rule doesn't allow. The first reason is the headline and all of them are listed under it; with none left it says it can merge by the method wanted. An unprotected branch says anyone can merge.

Why does turning protection off ask first?

It lets anyone with write access merge whatever the approvals and checks say, so it asks in an alert dialog that opens with focus on Keep protection and can't be dismissed by clicking outside it. The rules are kept and dimmed while protection is off, and turning it back on needs no question. Focus returns to the switch when the dialog closes.

What stays local, and how do I make it real?

Everything. Save keeps the rules in this page's state and a reload brings back the starting ones; the tester asks no server. To make it real, store the rules per branch pattern on your server, enforce them where merges happen (the host's branch protection API or your own merge queue), and use the same function to preview a pull request's status from its real approvals, checks and signatures.

What does Save refuse?

A protected branch with no merge method allowed, because nothing could merge into it. Save names the branch, switches to it, marks the methods and moves focus to the first checkbox. The sentence on top says the same thing as soon as the last method is unticked: no merge method is allowed, so nothing can merge.

How does it look on a phone, and is it accessible?

The rules come first and the tester under them, each control with a visible label and a hint, the three toggles in a column and the verdict in a card whose list reserves room for every reason, so the page doesn't move when the answer changes. The branch picker and the segment groups are real groups with labels, the box and the name of each merge method are one hit area, and a new verdict is read out once you stop changing the pull request, not on every press.

  • Pro

    A Git connection settings panel: a provider and repository, a connection that disconnects through an alert dialog, and a branch table that sends patterns to environments, first match wins, with a tester.

  • Pro

    A pipeline settings window that draws its stages as cards on a canvas, redraws the lines when a stage runs in parallel, and recomputes the total time, with an inspector for each stage.

  • Pro

    A feature flag settings panel with ordered targeting rules, a kill switch that asks first, and an Evaluate for a user pane that reads what the flag serves and which rule decided.

  • Pro

    Six collaboration rules beside a live preview: pick Member, Editor or Guest and a drawn document with a comment thread plus five rows say what that person can view, comment on, reply to, resolve and mention, and why.

  • Pro

    Pull Request Merged Success

    Builds and deploys

    A confirmation panel for a merged pull request: a commit graph drawn in SVG beside the same history as a list, a group of buttons that dims one lane, the twelve checks as one count, the deploy in three timed steps and the merge hash with a copy button.

  • Pro

    A build settings panel for a static-site host: a preset fills the folder and commands, and a dark terminal writes the build log from the fields, or stops at the error a real runner would give.