Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Git Connection Settings Block for React

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.

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

Let people see which branch goes where before they push, with this Git connection 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 choices ("builds ferncroft/app-ios from GitHub: main goes to Production, and 2 other rules decide the rest, first match wins"). A band picks the provider in a Segment Group, GitHub, GitLab or Bitbucket named in text beside a two-letter tile, and the repository in a Native Select; a card beside it shows the connection, its fictional webhook and a read-only deploy key marked as a sample, not a real token, and Disconnect opens an Alert Dialog with focus on Keep connected and a destructive Disconnect. Under it a native table sends branch patterns to Production, Staging or Preview, each row with an auto-deploy Switch, Move up, Move down and Remove, and a note when an earlier pattern already catches everything the row would; Undo brings back the last removed rule. A new pattern is checked before it is added, and Try a branch names the rule a branch name would take. An action foot counts unsaved changes beside a Shine Button that saves them in the page. It's built from Segment Group, Native Select, Alert Dialog, Switch, Input, Button, Shine Button and Guides, with a CSS entrance only. For a CI or hosting dashboard, a mobile build service or any product that deploys from a repository.

FAQ

How do I change the providers, repositories and rules?

Edit PROVIDERS (each has an id, a two-letter mark and its name), REPOS (the repository names under ORG), ENVS and SAVED, which holds the connection and the rules when the page opens. The lead sentence, the table's counts, the tester and the unsaved count all read from the rules, so a new environment or rule appears everywhere at once.

How are branch patterns matched, and what does Never reached mean?

A star stands for any characters, so feature/* takes feature/login-copy and * takes everything; the rules are read from the top and the first match decides. A row says Never reached when an earlier pattern catches everything it would, which the block tests by trying two names the stars could stand for. Moving a rule up or down updates the notes at once. A new pattern may use letters, digits and / . _ - * only, and an identical pattern is refused with the rule that already has it.

What happens when I disconnect, and can I undo it?

Disconnect opens an alert dialog that can't be dismissed by clicking outside it and starts on Keep connected. Confirming marks the connection as not connected, keeps the rules as they are, dims the rule table and the tester (they stop taking focus) and replaces the button with Connect, which takes focus. Connect brings it back in this demo; nothing is contacted either way. Removing a rule has its own Undo, which restores the last removed rule at its old place.

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

Everything. Nothing contacts GitHub, GitLab or Bitbucket: the repositories, the webhook host and the deploy key are fictional sample values, and Save keeps the choices in this page's state. To make it real, connect through the provider's OAuth or app installation, list the account's repositories into the select, register a webhook and a read-only key, store the rules on your server and match each push against them in the same order. Never put a real token in the page.

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

The provider chips stack on the narrowest screens, and each rule becomes a card with its pattern and three buttons on the first line, the environment under them and the switch with a line that says what it does. Every control names its rule ("Rule 2: deploys to"), the move buttons stay focusable at the ends and answer in words, and focus follows a rule that moved or was removed. The status line says what changed, and says which rule a branch would take once typing rests.

  • Pro

    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.

  • 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 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.

  • Pro

    Environment Variables Settings

    Domains and delivery

    An environment variables settings panel that shows where each variable is set across Production, Preview and Development, counts what is missing, fills a missing value with Copy from, and previews a pasted .env file before it imports.

  • Pro

    A connected apps settings panel with a permission review sheet: each app asks for permissions shown as switches with what they allow, a pause, and a disconnect that confirms first.

  • 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.