GitRoot
(gitroot.dev)- GitRootは、単一バイナリでリポジトリとアクセス権を管理し、独立したプラグインとして Issue・ボード・ブランチのマージ・Web インターフェースを組み合わせる小型 Git フォージ
- コードだけでなく Issue、マージリクエスト、ボードまで、すべてのデータを通常ファイルとして Git に保存し、別途データベースや隠し blob に依存しない
.gitroot/users.ymlと ブランチ別の書き込み権限で変更を制御し、リポジトリの現在の状態であるデフォルトブランチには許可されたユーザーだけが push できる- 現在は アルファ版で、リポジトリ・ユーザー・プラグイン・SSH Git コマンド・HTTP での閲覧をサポートするが、本番用途には適していない
- 1.0 までにアップデート、ファイル単位の権限、HTTP Git コマンド、グループ・サブグループ、プラグイン API の安定化を進める予定で、現時点での貢献には Git と
grafterプラグインのフローへの理解が必要
必要な機能だけを組み合わせる小型 Git フォージ
- GitRoot は 1 つのバイナリで実行する 小型 Git フォージで、基本機能をリポジトリ作成とリポジトリ別アクセス権管理に限定している
- そのほかの機能は、互いに独立してインストールできるプラグインが担う
- Issue、ロードマップ、スプリント、マイルストーンの作成
- 項目をボード形式で表示
- GitRoot で
graftと呼ぶブランチレビューとマージ - リポジトリデータと各種機能を Web インターフェースで提供
- プラグインが完全に分離されているため、Web インターフェースなしでボードだけを使うこともでき、プロジェクトに必要な機能を自分でプラグインとして作ることもできる
プロジェクトに合わせてフォージを変えられる設計
- プロジェクトごとに必要な作業方式は異なるという前提で、各プロジェクトが 自分たちのフォージを変更する自由を持てるよう設計されている
- 開発者が望む環境は次のとおり
- コード、Issue、pull/merge request、ボードを 1 つのリポジトリに保管
- ランディングページ、翻訳、チケットシステム、フォーラムなど、プロジェクトの広報と運営に必要な機能を提供
- マイグレーションスクリプトやデータ・貢献者表示の損失なしに、別のサーバーフォージへ移行
- 反対に、次のような複雑さは避けようとしている
- pull/merge request や Issue を管理するためにブラウザを開かなければならない方式
- プロジェクトに初めて触れる人に、まずファイルとディレクトリの一覧を見せる構成
- フォージがスプリント・マイルストーン・エピック・ユーザーストーリーの意味と作業フローを決める方式
- ユーザー権限を 1 つ設定するために複数のメニューをたどらなければならない構造
インストールと運用の自律性
- 管理者が簡単にインストールして保守できるよう、依存関係とデータベースのない配布を目指している
- 管理者はユーザー別に許可する操作を設定でき、ユーザーはメールやチャットなしにプロジェクトと機能の作成・アクセスを直接リクエストできるべきだとしている
- アップグレード負担を減らすと同時に、プロジェクトとユーザーデータを第三者に渡さず、運用方針を突然変えうる大手事業者にも依存しないことが目標
- まだ完成していないプロジェクトで、外部からの貢献を受け付けている
通常ファイルとブランチで管理する権限
- データベースや Git ツリー内部の隠し blob ではなく、コードの隣にある 通常ファイルにすべてのデータを保存する
- 各リポジトリの
.gitroot/users.ymlがユーザー別の書き込み可能位置を指定し、アクセス制御は ブランチ制限を中心に動作する- 最初は所有者だけが デフォルトブランチ にアクセスできる
- 権限のないユーザーがデフォルトブランチへ push すると、GitRoot が変更を拒否する
- 誰でも新しいブランチを作成でき、作成したユーザーはそのブランチの書き込み権限を得るが、ほかのユーザーは修正できない
.gitroot/users.ymlを修正するか、ユーザーが自分を追加したブランチをマージすると、そのユーザーもデフォルトブランチへ push できるようになる
- 誰でもファイルを読み、ローカルや新しいブランチで修正できるが、リポジトリの現在の状態を表すデフォルトブランチへ変更を反映するには 所有者によるマージが必要
- フォージ自体の設定もルートリポジトリで管理する
- ルートリポジトリのデフォルトブランチにある
.gitroot/repositories.ymlへ変更を追加するか、その変更をマージするとリポジトリが作成される - 詳しい動作方式は ドキュメント で確認できる
- ルートリポジトリのデフォルトブランチにある
アルファ版でサポートする機能
- 現在は アルファ版のため試用は可能だが、本番環境では使うべきではない
- サポート範囲は次のとおり
- リポジトリの作成と削除
- SSH 経由での Git コマンド処理
- リポジトリ・ブランチレベルでのユーザー別書き込み位置管理
- プラグインのインストールとリポジトリ別の有効化
- インストール時にワークツリーでプラグインを実行
- インストール後、コミットごとに diff を対象としてプラグインを実行
- HTTP 経由でのリポジトリ閲覧
1.0 までの開発計画
- バージョン 1.0 までに次の機能を実装する計画
- GitRoot とプラグインのアップデート
- ファイルレベルのユーザー権限管理
- HTTP 経由での Git コマンド処理
- グループとサブグループを使ったリポジトリ管理
- プラグイン API の安定化
セルフホスティングと貢献手順
- GitRoot の Web サイトは GitRoot のコード自体をホストする GitRoot インスタンスで、GitRoot プロジェクト専用に運用されている
- ほかのプロジェクトで試すには、インストールおよび使用ドキュメント に従う必要がある
- GitRoot 自体も GitRoot リポジトリなので、同じ方法で貢献でき、手順は 貢献ガイド で確認できる
- 現在のインスタンスはコードの一部をデフォルトブランチへ統合する
grafterプラグインを使っているため、貢献前にその動作方式を理解しておく必要がある - コード、Issue、翻訳を含むすべてのデータが Git に保存されるため、現時点で貢献するには Git の使い方を知っている必要がある
- 将来的には、ブラウザから
git commitとgit pushを直接実行し、誰でも参加できるようにすることを目指している
1件のコメント
Lobste.rs の意見
<pre>タグの幅が 720px に制限される原因はbodyのdisplay:gridのようで、これを解除すると期待どおり広がります。また URL に特定のコミット時点の情報がないため、リンクを送った人と受け取った人が同じ画面を見るのが難しいです。個人的な必要のためのプロジェクトだという点は理解していますが、検討に値する事項として伝えたいと思いました個人的にはコーディングに LLM を使っておらず反対ですが、LLM を使っていたとしても、パッチが十分に小さければ拒否するかどうかは確信が持てません
英語が母語ではないため GitRoot を説明するのが難しく、対外的なコミュニケーションには LLM の痕跡があります。以前にも https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 と https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 で助けを求めましたが、誰も来ませんでした
LLM を使わなければならない事実はつらいですが、何もしない代わりに最小限に使うことにしました。今後コミュニティができれば完全に排除したいですし、その前に経済的な理由で自然に消えていく可能性もあると思っています。哲学・セキュリティ・未来を説明する記事は ToDo リストにたくさんありますが、結局 LLM が文章を直したり誤字を修正したり翻訳したりするだろうという考えがあるため、執筆をためらってしまいます