Brnch

Brnch

Vigilbase · 程式設計

Brnch 是給人與 AI 代理程式共用儲存庫的 Git 代管服務,每次合併都會產生簽章憑證,記錄誰寫、誰核准、誰驗證了這次變更。

Brnch 的介面預覽

關於 Brnch

About

Brnch 是什麼

Brnch 是 Vigilbase 推出的 Git 代管服務,對象是讓 AI 代理程式直接提交程式碼的團隊。它具備一般代管平台該有的東西:HTTPS 或 SSH 存取儲存庫、類似 pull request 的變更流程、議題追蹤,以及名為 Actions 的持續整合系統。額外賣點是它會留下每個變更進入受保護分支的完整記錄。

這份記錄就是產品存在的理由。每次合併都會產生一份簽章憑證,裡頭寫明作者(人,或帶有真人贊助者的代理程式工作階段)、綁定在特定修訂版本的核准、執行過的檢查、每項檢查的來源,以及當下生效的政策版本。你可以用命令列工具搭配公開金鑰離線驗證這個檔案,不需要帳號。

Vigilbase 把 Brnch 稱作給代理程式用的程式碼代管,這個說法點出了重點:代理程式是儲存庫的正規使用者,不是掛在某人筆電上的腳本。如果你要的是成熟的 AI 程式碼代管平台,還附帶龐大的應用程式市集,它現在還不是。

產品本身不依賴任何 AI。儲存庫、審查、合併、議題與 CI 在沒有模型供應商、沒有金鑰的情況下都能運作。AI 功能屬於選配,例如自動草擬變更說明,由組織管理員決定是否開啟。

開始使用

  1. 用電子郵件在 brnch.io 註冊帳號。代理程式也能幫你啟動同樣流程:命令列工具會印出連結與八位字母代碼,你在瀏覽器按下核准即可。
  2. 執行 npm install -g brnch-cli 安裝命令列工具,需要 Node.js 20 以上與 git 2.31 以上。不想用 npm 的話,官方也提供獨立腳本。
  3. 在專案目錄執行 brnch setup --yes。它會在個人命名空間建立私有儲存庫,把現有內容提交,並將第一個提交推到受保護的 main 分支。
  4. 程式碼原本放在 GitHub 的話,可以匯入既有儲存庫。提交歷史會保留,runner 與 secret 則要在 Brnch 這邊重新設定。
  5. 開一個變更、審查修訂版本,政策通過後即可合併。合併會產生憑證,你可以歸檔,也可以日後再驗。

產品資訊

快速了解 Brnch 的定價、支援平台與效能。

免費方案是
付費方案Free - $10/member/mo
平台Web, CLI, REST API, MCP
開發者Vigilbase
類別程式設計
發布日期Oct 2026
最近更新Nov 2026
網站訪問量N/A
網站全球排名N/A
API 提供狀態是

適合對象

這項工具最適合的使用者、任務與情境。

使用者

  • 已經讓 Claude Code、Codex 或 Cursor 對共用儲存庫動手的團隊:每個代理程式有獨立身分與具名贊助者,提交會進入審查,而不是繞過審查。
  • 需要回答稽核問題的技術主管:憑證會指出被核准的修訂版本,以及實際在合併樹上跑過的檢查,一般合併紀錄看不到這些。
  • 因為成本或流程而離開 GitHub 的小型產品團隊:私有儲存庫、審查與 CI 都能免費起步,Team 方案每人每月 10 美元。

任務

  • 審查代理程式半夜寫好的程式碼:核准綁在特定修訂版本上,核准後又出現新提交,就得重新審查,不能沿用舊的簽核。
  • 幾個月後回查某次合併:`brnch verify receipt.json` 會用公開金鑰離線執行,確認文件沒有被改過。
  • 找出會弄壞正式環境的變更:唯讀連接器會拿 diff 跟實際系統比對,回報問題時必須指出肇事的 diff 行與對應的正式環境事實。

情境

  • 代理程式凌晨兩點開了變更,工程師喝完咖啡才合併:憑證會顯示代理程式工作階段、贊助者與檢查結果,不必再從聊天紀錄拼湊事發經過。
  • 受監管的客戶問版本 4.2 是誰核准的:你交出簽章文件,而不是網頁介面的截圖。
  • 三個代理程式在同一份儲存庫處理不同功能:每個工作階段拿到受限憑證與獨立工作區,Brnch 會在合併前預測未關閉變更之間的衝突。

主要功能

合併憑證

每次合併到受保護分支,Brnch 的晉升服務都會簽署一份 in-toto 陳述,把作者、核准、必要檢查與政策版本綁在單一修訂版本上。brnch verify 可離線檢查簽章,客戶或稽核人員不必有帳號就能確認紀錄。

負責任的代理程式工作階段

代理程式工作階段使用短期、受限的憑證,並掛在真人贊助者名下。代理程式能做的事不會超過啟動工作階段的那個人。介面把三件事分開呈現:代理程式自己宣稱的內容、平台觀察到的紀錄,以及獨立檢查驗證的結果。三者不會混成一個分數。這種區隔就是代理程式問責的實際樣貌:宣稱、觀察、驗證是三件不同的事。

修訂版本、堆疊與改寫

變更的身分能撐過 amend、rebase 與 split,也支援 jj 與 GitButler 的 change-id 及 Gerrit 的 Change-Id。每次 ref 更新都會留下日誌,而且可以復原。Brnch 也會預測未關閉變更之間的衝突,多個代理程式動到同一批檔案時特別有用。

影響範圍審查

唯讀連接器讓審查者拿變更跟正式環境對照。只有當問題能指出是哪一行 diff 造成、以及哪個正式環境事實讓它變成危害時,才會回報,這能濾掉靜態分析常見的雜訊。

以 Actions 執行 CI

工作流程放在 .brnch/workflows,使用官方文件列出的 GitHub Actions 語法子集。執行環境可以是託管 runner 或你自己的機器。只有在受保護目標 ref 上、由託管 runner 執行的工作流程,才算合併政策裡的獨立證據。

MCP 伺服器與 A2A

Brnch 在 brnch.io/mcp 提供 MCP 伺服器。把它加進 ChatGPT 或 Claude 的自訂連接器,用 OAuth 登入即可。預設唯讀,寫入動作要明確開啟。另外有 A2A 端點,讓代理程式透過 JSON-RPC 取得唯讀存取。

優缺點

優點

  • 憑證讓稽核人員拿到可離線檢查的檔案,這一點多數程式碼代管平台無論收多少錢都做不到。
  • 代理程式的工作被當成正常工作對待:獨立身分、具名贊助者、受限權杖,審查路徑跟人一樣。
  • 核准綁定修訂版本,先核准再強制推送的漏洞在設計上就補起來了。
  • 價格透明:免費起步,Pro 每人每月 8 美元,Team 每人每月 10 美元,年繳每人 8 美元。
  • 核心代管功能不需要 AI 供應商與金鑰,可以先導入審查模型,再決定要不要碰 AI 功能。

缺點

  • 平台還年輕。整合清單不長,Actions 只涵蓋部分 GitHub Actions 語法,既有工作流程未必能原樣搬過來。
  • 搬遷只做一半。程式碼與歷史可以匯入,星號、追蹤者、secret 與 runner 都得重新設定。
  • `brnch setup` 會把擷取掛鉤寫進本機的 Claude Code、Codex 或 Cursor 設定,除非加上 `--agents none`。沒讀文件的人會嚇一跳。
  • 憑證的份量取決於你的政策。必要檢查太少,或工作流程來自未受保護的 ref,證據就沒什麼說服力。

常見問題

Brnch 是給使用 AI 代理程式的團隊使用的 Git 代管服務。它處理儲存庫、變更、議題與 CI,再加上簽章合併憑證與受限的代理程式工作階段,讓每個變更都有可驗證的作者與核准紀錄。