內建 Git
Restorm 專案本來就是要活在 git 儲存庫裡的。這個整合走得比單純的 git commit
更遠：它看得懂這個格式，能在業務實體的層級解決衝突，而不是在 YAML 的行層級。
沒有任何東西需要設定。只要開啟的 .restorm 檔案位於某個 git 儲存庫內，git 相關
介面就會啟用。
Restorm 使用的是您本機的 git：不必輸入帳號密碼，應用程式裡也不必管理權杖。
規則很簡單 — 如果 git push 在您的終端機裡能用，它在 Restorm 裡就能用。
Git 是在關閉互動提示的情況下啟動的：會要求輸入密碼的儲存庫會立刻失敗，並顯示
git 自己的訊息，而不是把介面卡住。
狀態列的 GIT 格子
Section titled “狀態列的 GIT 格子”兩個按鈕，推送與提取，當有東西要送出、或有更新的版本可以取回時，各自 會帶一個圓點（只是一個點，永遠不是數字）。
標題列的 Git 選單提供相同的動作，另外還有重新整理、 重設為伺服器版本與歷史記錄。
推送對話框會顯示一份已經寫好的提交訊息，它是從結構化差異中 以決定性的方式產生的 — 完全不用語言模型。每一個被修改的實體一行（請求、 情境、資料夾、環境資料夾），絕不會每個欄位一行。
- 一個訊息的語言選擇器，與介面語言各自獨立，並附一個開關可把它設為預設值。
- 一個可編輯的標題，附帶一個以 72 個字元為參考的計數器。
- 一個多行的內文。
確認後會依序執行：儲存、git add、提交、推送。
Restorm 會先儲存，然後才提取並合併。
乾淨合併：樹狀清單與開啟的分頁會就地更新。
發生衝突：會開啟一個四面板的解決檢視。
| 面板 | 內容 |
|---|---|
| 衝突清單 | 發生衝突的實體 |
| 您的版本 | 唯讀 |
| 他們的版本 | 唯讀 |
| 已解決 | 可編輯 — 這才是真正會被寫入的內容 |
關鍵在這裡：每個面板都會把實體顯示在它真正的編輯器裡 — HTTP 請求在 HTTP
編輯器裡，情境在情境編輯器裡。您解決的不是 YAML 裡的 <<<<<<< 標記，而是在
比較兩個請求。
每一邊都有一個**「使用這個版本」按鈕，而且有差異的欄位會以紅色標示** — 當只有一個欄位不同時，面板會直接開在相關的分頁上。
環境資料夾的 API 文件會自動解決（較新的版本勝出）。
取消會執行一次 git merge --abort。若在解決過程中關閉應用程式，下次啟動時
會詢問您是否要放棄這次合併。
背景檢查（半自動提取）
Section titled “背景檢查（半自動提取）”Restorm 會定期檢查是否存在較新的版本 — 但絕不會自己合併。有三個觸發條件：
偵測到 .git 內有變動、開啟一個檔案，以及一個計時器，其頻率可在
設定 ▸ Git 中調整（Off、15 分鐘、30 分鐘、1 小時、4 小時、12 小時、
24 小時）。
此時會出現一則「有可用更新」的通知，並提供 Pull now。
檔案被外部修改
Section titled “檔案被外部修改”如果檔案自開啟以來在磁碟上被改動過，儲存會被拒絕，Restorm 會請您選擇 重新載入或保留您的版本。
為什麼 diff 是可讀的
Section titled “為什麼 diff 是可讀的”這來自格式的兩項特性，詳見
.restorm 專案與檔案：
標準化的鍵順序，以及以穩定方式衍生的識別碼。
結果就是：開啟後不做任何修改再儲存不會產生任何 diff，而兩個人在同一個位置新增 同一個請求時，產生的實體是合併機制能夠正確配對的。
Git ▸ 歷史記錄會開啟一個雙面板檢視：左邊是帶分支軌道的提交清單，右邊是 詳細內容。在某個提交上開啟右鍵選單，可以取回該版本。
透過 MCP
Section titled “透過 MCP”四個工具，屬於 Pro 版：git_commit_push（兩步驟中的第一步 — 回傳一個審查
權杖、標題、內文以及逐實體的差異，完全不寫入任何東西）、
git_confirm_push（兩步驟中的第二步 — 如果專案在審查後又變動過就會被拒絕）、
git_pull 與 git_resolve_conflicts。
拆成兩個步驟是刻意的：代理程式不可能在沒有先呈現差異的情況下推送。