- 最もシンプルな Git コラボレーションツールを作ることが目標
- 外部コラボレーターの時間とエネルギーを犠牲にせず、セルフホスト Git サーバーの運用を SSH サーバーの運用と同じくらい簡単にする
- メーリングリストと pull request ワークフローを組み合わせる
- パッチ作成のようにシンプルでありながら、pull request の使いやすさを備えたコラボレーションツールを目指す
- 別のコードリポジトリを作るのではなく、外部コントリビューターと協業できる非常にシンプルなセルフホスト Git ソリューションを作りたい
必要なもの
- コードオーナーが Git サーバーを動かすために必要なもの:
- 外部コントリビューターに必要なもの:
現在の問題点
- メールは Git リポジトリへの変更（パッチセット）を送受信するための分散システムとしては優れているが、新しいユーザーをメーリングリストにオンボーディングし、メールクライアントを正しく設定してからコード投稿を行う必要があるため、それだけで多くの開発者が諦めてしまう
- メールプロトコルを使ってコラボレーションするため、機能セットに制約がある。たとえばメールは編集できず、全員が異なるクライアントを使い、それらのクライアントはプレーンテキストメールやパッチのダウンロードに関してそれぞれ異なる制限を持っている
- GitHub の pull request は利用・編集・管理がしやすいが、コードレビューを行うには GitHub の Web サイト内にいなければならないという欠点がある
- 素早い変更には向いているが、Web ブラウザ内でコードを読み始めるとかなり大きな欠点がある。ある時点からは、ローカルの開発環境や IDE などでコードをレビューするほうが理にかなっている
- IDE 内で PR をレビューできるツールやプラグインもあるが、実際に使えるようにするには膨大な労力が必要
- さらに、pull request を模倣するセルフホスト型ソリューションは、その管理のために多くのインフラを必要とする。データベース、Git と連携した Web サイト、管理機能、サービスなど
- もう 1 つの大きな摩擦点は、外部ユーザーがコード変更を投稿する前に、まずアカウントを作成してログインしなければならないこと。これは外部コントリビューターだけでなく、インフラを用意しなければならないコードオーナーにとっても大きな負担となる
- PR を投稿する前に、コードリポジトリ内でリポジトリをフォークしなければならないことが多い。その後二度と貢献しないのに、フォークしたリポジトリをずっと保持することになる。これはばかげているように見える
Patch Request (PR) の紹介
- メール設定の煩わしさや、メールプロトコルによる制約なしにパッチをやり取りできるセルフホスト Git "サーバー" を作りたい
- また、主要なワークフローはローカル開発環境を中心にしてほしいと考えている。GitHub はブラウザに IDE を持ち込むことでワークフローを支援しているが、こちらはその発想を逆転させ、コードレビューをローカル開発環境の中で第一級の存在にしたい
- GitHub の pull request ワークフローと、メールによるパッチ送受信の中間にあるものと考えている
- 基本的なアイデアは、SSH アプリを活用してコントリビューターとプロジェクトオーナーの間のやり取りの大半を処理すること。すべてをターミナル内で使いやすく、かつ完全な機能を備えた形で実行できる
- 通知は RSS で行われ、すべての状態変更は静的 Web アセットの生成につながるため、シンプルなファイル Web サーバーですべてをホストできる
format-patch ワークフロー
- ここでの基本的なコラボレーションツールは format-patch
- コード変更の投稿も、コード変更のレビューも、すべてコードの中で行われる
- コントリビューターとオーナーの双方が新しいコミットを作成し、互いの上にパッチを生成していく
- これにより、レビュアーがコードブロックの 1 行に「コメント」を付けられる Web ビューアーは不要になる。必要ない。コントリビューターのパッチを適用し、コメントやコード変更を書き、新しいパッチを生成し、そのパッチを「レビュー」として Git サーバーに送ればよい
- この流れは、2 人のユーザーが一連の変更について協業する場合でもまったく同じように機能する
- 同じコード変更に対して複数のパッチセットを送る問題も解決される。すべての変更とコラボレーションが行われる単一の中央 Patch Request がある
- git note を使ってレビューやコメントを扱う方法も見つけられるかもしれないが、正直なところその解決策はかなり粗暴で、多くの Git ユーザーの快適圏を外れているように感じる
- レビューはコードで送り、使っているプログラミング言語でコードに注釈を書けばよい
- それらの注釈を「処理」し、後続のパッチで削除するのはコントリビューターの仕事
- すべての注釈に対応することを強制する機能: コード内に未処理の注釈があると、パッチはマージされない。無視することはできず、そうしないと誤ってアップストリームに入ってしまう
Patch Request の仕組み
- Patch Request (PR) は、Git リポジトリへの変更を投稿・レビュー・受け入れする最もシンプルな方法。流れは次のとおり:
- 外部コントリビューターがリポジトリをクローン (
git-clone)
- 外部コントリビューターがコードを変更 (
git-add & git-commit)
- 外部コントリビューターがパッチを作成 (
git-format-patch)
- 外部コントリビューターが SSH サーバーに PR を投稿
- オーナーが新しい PR の RSS 通知を受け取る
- オーナーが SSH サーバーからローカルにパッチを適用 (
git-am)
- オーナーがコードに提案を書き込む (
git-add & git-commit)
- オーナーがパッチを SSH サーバーへパイプしてレビューを投稿 (
git-format-patch)
- 外部コントリビューターが PR レビューの RSS 通知を受け取る
- 外部コントリビューターがパッチを再適用 (
git-am)
- 外部コントリビューターがコード内の注釈を確認して削除
- 外部コントリビューターがさらに別のパッチを投稿 (
git-format-patch)
- オーナーがローカルでパッチを適用 (
git-am)
- オーナーが PR を承認済みとしてマークし、コードを main にプッシュ (
git-push)
1件のコメント
Pico.sh - SSHを使ってあらゆるWebサービスを管理するオープンソース集 に新しく追加されたものですね。
以前から、次のようなものが含まれています。