Jujutsu UI 成為 Git 替代方案的領先 TUI 工具，引發社群對 GitHub 侷限性的討論

BigGo Editorial Team

Jujutsu 版本控制系統在開發者社群中勢頭強勁，一個名為 Jujutsu UI (jjui) 的新文字使用者介面 (TUI) 正在成為測試過多種介面選項使用者的首選。這一發展凸顯了開發者對傳統 Git 工作流替代方案日益增長的興趣，並揭示了對現有程式碼審查平臺的重大不滿。

廣泛測試過各種 Jujutsu TUI 工具的開發者報告稱，jjui 在效能和可用性方面表現突出。使用者稱讚其響應迅速的介面、直觀的鍵盤快捷鍵以及在不同程式碼庫中的穩定執行。該工具透過簡潔的終端介面提供了修訂變基、變更合併和互動式檔案管理等基本功能。

其他 TUI 選項如 lazyjj 因效能問題和穩定性問題而受到批評，而基於 bash 指令碼構建的命令列替代方案則被認為不可靠。這種共識表明 jjui 已經成功解決了尋求 Jujutsu 操作視覺化介面的開發者的核心需求。

Jujutsu UI 主要功能：

一個主要討論點集中在 GitHub 無法有效處理堆疊拉取請求，而許多開發者認為這是現代開發工作流的基本功能。與允許審查單個提交的 Gerrit 等程式碼審查系統不同，GitHub 的模式將拉取請求視為單一的變更單元。

「GitHub 不理解所有提交都可以為了審查目的而改變。這就是讓它成為'玩具'的原因。」

這一侷限性已成為企業環境中團隊考慮採用 Jujutsu 的重大障礙。缺乏適當的堆疊支援意味著開發者在使用 GitHub 託管的程式碼庫時失去了 Jujutsu 的大部分優勢，迫使他們依賴變通方法或替代平臺。

長期使用 Git 的使用者報告稱，切換到 Jujutsu 感覺很自然，將其比作初期調整後的騎腳踏車。該系統的變更管理方法消除了許多傳統 Git 的痛點，特別是在儲存管理和變基操作方面。使用者描述採用了變更驅動開發等新工作流，其中空提交在分支內充當待辦事項列表。

然而，轉換並非沒有挑戰。開發者經常在進行更改前忘記建立新修訂，一些成熟的程式碼庫擁有期望 Git 目錄結構的工具。這些相容性問題可以透過共置程式碼庫來解決，但它們代表了採用過程中的摩擦點。

Jujutsu 作為 Git 儲存系統之上的新介面層執行，使用 Gitoxide Rust 庫進行 Git 物件管理。最近的版本已開始將直接 Git 二進位制使用納入網路操作，提高了與各種身份驗證系統和協議的相容性。

該系統的後端無關設計為超越 Git 侷限性的未來儲存改進開闢了可能性，包括更好地支援大型程式碼庫和原生大檔案處理。當前的開發包括向原生後端同步邁出的早期步驟，這將允許在不同機器之間無縫切換而不丟失 Jujutsu 特定的歷史記錄。

系統要求：

Jujutsu UI 作為首選 TUI 的出現反映了開發者對改進版本控制工作流的更廣泛興趣。雖然 GitHub 在堆疊 PR 方面的侷限性仍然是採用的重大障礙，但該工具的成功表明了對現代版本控制概念更好介面的需求。隨著生態系統的成熟，這些發展可能會影響主要平臺如何處理程式碼審查和變更管理。