自分だけのGitHubを作るなら

 (matduggan.com)
4 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • GitHub、GitLab、Gitea のような現代的な forge は GitHub 型のモデルを共有しているが、実際の業務の中心は git よりも PR、Actions、Issues、Releases といった forge 機能の中で起きていることのほうが多い
  • 新しい forge は、コミット後ではなく push 前にフィードバックを返す 強制 pre-commit hook をリモート実行できるようにし、Feature、fix、actually fix、asdfasdf のような繰り返しコミットを減らせるべき
  • PR 承認は承認/却下の二分法を超え、Gerrit のように弱い承認や後で見直す印をサポートし、作成者がメンテナであり LLM が低リスクと判断した小さな変更は、より柔軟に通せるべき
  • Stacked PR は forge と VCS の 第一級機能 であるべきで、ローカルリポジトリはコードだけでなく PR 承認や Issue まで含めたリポジトリ全体の状態を表現できるべき
  • 理想の組み合わせは、VCS として JJ、小さな単位でホスティングできる新しい forge、署名・SHA・オフライン実行をサポートする Actions だが、単一の巨大 forge である GitHub がデフォルトとなっている時代に、まだ明確な代替は存在しない

現代の forge の問題

  • GitHub、GitLab、Gitea は細部の違いこそあれ、ほぼ同じ設計モデルに従っており、GitHub が作った業界パターンを他のツールが持ち込んだ形に近い
  • 現在の forge の機能の大半は git そのものとは直接ほとんど関係がなく、クライアントは実際の使われ方とかけ離れている
  • git はカーネル開発のような環境に適した分散バージョン管理システムで、メールでパッチをメンテナに送り、メンテナが自分の担当領域を管理し、マージするかどうかを判断する高信頼ベースのワークフローに向いている
  • しかし多くの職場では、git は中央 forge に保存されたリポジトリからコードを pull/push するための手段に近く、重要な作業は forge の中で行われる
    • Pull Request は four-eyes 原則 を強制するための手段になっている
    • GitHub Actions は Pull Request でテストやリンティングを実行し、機能性や組織要件を満たしているかを確認する
    • forge 内のユーザー ID は、そのユーザーを検証する基準になる
    • Issues はコード上の問題追跡に使われ、Releases はユーザーがダウンロードするリリースを作るために使われる
  • こうしたワークフローでは git 自体よりも git の上に載った forge 機能のほうが多いため、新しい forge を作るなら git という制約に必ず縛られる理由は薄れる

新しい forge に望む機能

  • フィードバックはコミット後ではなくコミット前に来るべき

    • よくある PR には Feature、fix、fix、actually fix、please、asdfasdf のようなコミットが連なる
    • フィードバックループがコミット後に来ると、ユーザーは遅い時間まで修正を続けることになり苦しむ
    • forge でリモートにジョブを実行する 強制 pre-commit hook を提供し、ユーザーが push する前にフィードバックを受けられるようにすべき

  • PR 承認は二分法すぎる

    • 現在の PR は承認済みか未承認かに分かれるが、実際のコードレビューにはその間の領域が多い
    • 「ひとまず大丈夫、後で対応しよう」のような人間的な反応もボタンで表現できるべき
    • Gerrit はこの点でより良いモデルを提供している
    • メンテナが弱く承認した場合、後で見直せるように印を付けられるべき

  • PR ポリシーはもっと柔軟であるべき

    • すべての変更に four-eyes レビューが必要なわけではなく、特に LLM が存在する環境ではなおさらだ
    • 4 行の PR に対してシニアエンジニアが LGTM を残すのを待つコストは高すぎる
    • 作成者がメンテナで、LLM が低リスクまたは無リスクと判断したなら、すぐ進められるようにもっと簡単に制御できるべき

  • Stacked PR は第一級機能であるべき

    • Stacked PR はレビューと理解を容易にする
    • VCS 外部ツールによる付加機能ではなく、forge と VCS の中で 第一級市民 として扱われるべき

  • forge は何でもやろうとしてはいけない

    • Issue 追跡は必要だが、Kanban ボードはおそらく不要
    • Wiki も必要性が疑わしい
    • すべての機能を入れるツールは結局品質が落ち、機能追加は簡単でも保守コストは採用率に関係なく発生し続ける
    • 誰かがどこかで使い始めると、その機能に縛られることになる

  • ホスティング単位が大きすぎる

    • GitHub Enterprise の運用は大仕事で、GitLab の運用も比較的大きな負担だ
    • これらの製品は可動部分の多い複雑なシステムである
    • より小さな個別ホスティング単位を作り、それらをつないで 1 つの組織を構成できるべき
    • グローバル federation である必要はなく、組織ごとにアカウントを作る必要があっても構わないが、組織は「この 12 台の Raspberry Pi が自分の組織だ」と言えるくらい柔軟であるべき

  • ローカルリポジトリはコードだけでなくリポジトリ全体を表現すべき

    • ローカルコピーはコードだけでなく、PR 承認や Issue のようなリポジトリ全体を表現すべき
    • コードをチェックインするのと同じ VCS で PR を承認できるべき
    • ローカルファイルを見て回るように Issue を確認できるべき

  • 常に完全な履歴保存のコストを払う必要はない

    • チームと適切に働くにはオンライン状態が必要なので、常にすべての保存コストを負担させる必要はない
    • VCS と forge は連携して動作すべき
    • リポジトリを clone するときは限定された履歴だけを受け取り、過去にさかのぼろうとしたときにワーカーを立ち上げて必要な内容を VCS から取得すればよい
    • ユーザーがいつかプロジェクト全履歴から forge を再構築するかもしれない、という前提だけで、巨大な clone 要求を forge に送り続ける必要はない

  • Actions は署名され、SHA が付き、オフラインでも使えるべき

    • Actions は重要なので、署名、SHA、オフライン利用可能性が必要
    • 望むならすべての action の tarball を取得してリポジトリに入れ、checkout action を外部から取らずローカルリポジトリ内のものを使うようシステムに指示できるべき
    • latest を指定したら、現在の Dependabot のように最新 tarball をリポジトリに入れる PR を開く形で動作すべき
    • Actions は望むなら同じ VCS を通じてローカルマシンでも実行できるべき

すでに一部を実現するツールはあるが、必要なのは組み合わせ

  • こうした要件の一部を満たすツールはすでに多く存在する
  • 必要なのは、それらのツールを持ってきてまとめ、きちんとかみ合わせることだ
  • 理想の組み合わせは、VCS として JJ、forge として新しいシステム、そしてユーザーが Raspberry Pi 1 台を forge として長く満足して使えるという期待である
  • 新しい forge は、オブジェクトストレージ、shallow clone、LLM ボットからの継続的なリクエストといった現代的な概念を中心に設計されるべき

GitHub がデフォルトである時代の亀裂

  • GitHub がうまくやれていたなら、こんな構想を書く必要はなかったはずだ
  • GitHub はデフォルトであり、デフォルトを超えようと説得するのはたいてい時間の無駄に近い
  • 2026 年まで forge を使うなら、みんなが使うツールを選ばないためには非常に強い理由が必要だった
  • 最近まで他の forge は、実際に望む選択肢ではなく代替品のように見なされていた
  • しかし単一の巨大 forge は崩れつつあり、まだ代替品は作られていない
  • 金のある人はロケットで忙しく、こだわりのある人は本業で忙しく、残りの人たちは深夜に asdfasdf という PR を開き、ロボットの検査を待ちながら、一日中使うツールがいつからユーザーのために作られなくなったのかと問い始めている

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsの意見

  • PR承認はあまりに二分法的すぎるという批判は、矛盾しているように見える。PR承認は権限付与なので、結局はブール値であるしかなく、コードをマージできるかできないかのどちらかしかない
    ここで言っているのは、気に入らないコードを承認しつつ「後でもう一度見直す必要がある…」のような言葉で少し気を楽にするための仕組みに近い。単に新しいチケットを切ればよい

    • Gerritには -2 から +2 まである
      -2: 悪いアイデアなのでやるべきではない
      -1: 良いアイデアだが改善が必要
      +1: 良さそうだが、承認する知識や権限が足りない
      +2: 承認
    • 「この3つのコミットは今すぐ承認してマージ、この2つはやり直しが必要」と言えるボタンがあればいいのに
    • コードは承認されたがマージはされない、ということもある。この場合、管理者が変更を加えて手動で適用し、その変更コミットの共同著者としてPR作成者を載せることもできる
    • より大きな問題は、GitHubが課題追跡システムとあまりにも分離されていることのように思える。手動で同期し続ける負担が大きく、Linearがある程度はやってくれるが理想的ではない
    • 「コードをマージできるかできないかのどちらかだ」だなんて、直観主義者ではなさそうだ

  • 「Yもその一部はやっている」というのは正しいが、tangled.orgは実際にはその大半をやっている

    1. バージョン管理システムとしてJJを使用: tangledはjj change-idによって積み重ねたPRをサポートする。https://blog.tangled.org/stacking tangled自体もこの方式で多く作られている: https://tangled.org/tangled.org/core/pulls
    2. Raspberry Piで長時間動かせるforge: これも可能。gitサーバーのshimは非常に軽く、gitリポジトリ上のXRPCレイヤーとsqlite3データベースにすぎない。RAM 512MBのRISC-Vボードで動かしている人もいる
    3. Actionsは重要でローカルマシンで実行可能であるべき: この要件は少しずれていると思う。密閉され、どこでも実行でき、クロスビルドを扱えることは、たいていビルドシステムの仕事だ。そうしたビルド結果をforge自体に「昇格」できるなら本当に良さそうだ
    • ワークフローの中核データをホスティングするのにRaspberry Piが出てきたのは意外だ。以前SDカード破損であまりに痛い目を見たので、最近はNVMEドライブを使っているのか気になる
    • そう、それはビルドシステムの仕事だ。ただ、人々がローカル実行可能なActionsで解決したがっている問題の大半は、ビルド失敗そのものではなく全体の統合だ
      YAML定義、シークレット、正確にどのコマンドを実行するのか、ツールやキャッシュをどう復元するのか、といった部分だ。ビルドシステムが一部を処理することもできるが、GHAが提供するプリミティブ機能は非常に乏しい。結局、システム全体を別の場所で動かす問題に行き着くので、こうしたシステムはたいてい試行錯誤型になるようだ
    • その通りで、さらに言えば密閉ビルドの概念を拡張して、ローカルでも計算資源のある場所ならどこでも簡単に動かせるようにしたい、という意味だ
      ここでいう根本問題は、変更・コミット・ネットワーク呼び出しを含むループの中で、CIがグリーンになるまで回し続けるのが非常につらいことだ。この反復を避ける最善の方法は、バグを絶対に書かないことだけだ！冗談だけど
    • RadicleとTangledはどちらも核心を外している。これらは公開協業向けだが、プライベートリポジトリはどうするのか。多くのユーザーはサイドプロジェクトを持っていて、そのためにGitHub privateを使っている
      GitHubを覚えると、公開プロジェクトもGitHubで始めるようになる。サイドプロジェクト用のプライベートリポジトリを作れるようにしない限り、広く使われるのは難しい。人々が望んでいるのは、プライベートリポジトリを作って何か月か離れても、戻ってきたときにそのまま待っていてくれることだ
    • うわ、Tangledのjujutsu対応はまさに探していたものだ。今週末はセルフホスティングのセットアップで消えそうだ

  • 限られた履歴だけをクローンし、必要なときに過去データを取り込みたいなら、blobless cloneを使えばよい
    git clone --filter=blob:none
    履歴は取得し、blobは必要になったときだけ取得する。GitHubに良い記事がある: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • 解決策そのものが問題になるなら、破壊的イノベーションの好機が開ける。最近この話はかなり多く、GitHubが方向修正する前に、新しく出てきている多くの代替のうちどれか一つでも勢いを得るのか気になる

    • 問題は、MicrosoftがAIに完全に全振りしていることだと思う。もう後戻りはできず、GitHubもその影響を受けるしかない
      Microsoftの広報はAIがあらゆるものの解決策だと言うだろうが、現実には同じ問題が繰り返されるだけだ。GitHubのサービス障害がAIと直接関係ないことはあり得ても、Microsoftの戦略自体がすでに変わっているので、ほとんどの判断はAI中心のトップダウン統制に合わせられる。GitHubを使う人たちのワークフローが壊れるかどうかは、Microsoftにとってせいぜい副次的な関心事でしかなく、その問題は繰り返し現れ続けるだろう。3か月くらい静かかもしれないが、そう遠くないうちにGitHubが衰退しているという新たなドラマが100%また出てくると思う。Ghosttyが最後ではないだろう。代替が出るのは興味深いが、その代替がひどくあってはならないのに、多くのウェブサイトはかなり出来が悪い
    • 自分の道具は自分で作っている。人々も自分の道具を自分で作るべきだと思う
      将来は、有料ソフトウェアやオープンソースソフトウェアの代わりに、コードforgeのための要求仕様書の束、いわばレシピを受け取るようになるのかもしれない。各自がそれを焼き、自分の用途や好みに合わせて変えるという形だ

  • もっと単純なgitサービスには市場の隙間があると思う。必要なのは、他の人が見られるようにプロジェクトをpushするためのリモートホストだけで、PRやActionsのようなものは特に欲しくない
    ローカルでビルドしたバイナリアセットをアップロードする「リリース」機能くらいはあってもいい。フォークは、人々がリポジトリをクローンして新しいプロジェクトとして上げれば対処できる

    • 不要な機能を無効にすれば、この多くは解決できるのでは？ たった今自分のForgejoインスタンスを見たら、リポジトリごとにCode、Projects、Releases、Packages、Actions、Issues、PRs、Wikisを無効にするオプションがある
    • https://sr.ht/
    • ではまたcgitに戻るのか？

  • レビューデータもソースのようにgitリポジトリに入れられるという主張は、かなり説得力がある
    よく知られた接頭辞を付けてレビューごとにブランチを持てばとても簡単に実装できるが、デフォルトのブランチ名前空間はすぐに散らかるだろう。git namespacesでメイン名前空間と分離するか、各レビューブランチの末端コミットIDだけを入れた.reviewsのような特別なブランチを置くこともできる。誰かが十分に関心を持って仕様と実用的な実装を作れば、人々が採用し始めるかもしれない。GitHubや複数のforgeがこの方式を取っていない理由は、レビューのメタデータを自分たちの生態系に閉じ込めておくことがプラットフォーム価値だからだと思う。誰もが好きなローカルツールで他人のコードをレビューできるなら、ベンダーロックインは減る。ただし、アクセス制御やリポジトリ間レビューのように、レビューメタデータを別リポジトリに置きたい他の理由もあるだろう

  • PRではなく差分をレビューするGerritワークフローが本当に好きだ。だが、giteaのようなものと比べると、課題管理やプロジェクト計画など、gitホスティングに期待される残りの機能が不足しているため、多くの人を説得するのは難しそうだ
    Phabricatorのような、まともな差分レビュー基盤があればいいのだが惜しい

    • でもなぜGiteaはそれを追加しないのだろう？ もう他は全部あるのに、なぜこうしたforgeはいつもGitHubのコピーにとどまり、その先へ進まないのか分からない

  • PR、レビューコメント、課題のようなあらゆるメッセージ保存の基本形式としてRFC2822を使い、メッセージ表示時にはCommonMarkで装飾すればいいと思う
    すべてのメタデータはヘッダーに入れ、Message-ID / In-Reply-To / References ヘッダーで相互に関連付けられる。こういうよく定義された形式を使えば、すべてのメッセージをどう保存・転送するかを選べる。gitリポジトリに入れてもいいし、メールを使ってもいいし、他の適した方法でもいい。コードレビューは個人的にはGerritがGitHubなどよりはるかに優れていると思う。CIは可能な限り外に置き、パイプラインを開始し、結果を表示し、マージ可否を決めるフックくらいだけを置きたい

    • GitHubの魅力の一つは、コードレビュー、ソース探索、チケット追跡、CIの4つを統合している点だと思う
      4つすべてが飛び抜けて優れているわけではないが、ひとまとめにするのはうまい。Gerritがより良いコードレビューのモデルだという点には同意するが、残り3つの要素がなければ製品にはならない。GoogleでGerritを毎日使っていた頃でさえ、コード検索とコードレビュー、CIの統合の弱さには不満があった。Google3 / Critique / ForgeのようなGoogle社内ツールは、これらすべてをずっと上手く結び付けていた

  • メールベースのワークフローの利点が一つ思い浮かぶ。メールを見始めたなら、たいていその気分のときであり、その状態では他の邪魔がないと予想するので、より集中できる
    通知の問題は、表示されたらすぐ片付けたくなる力があることだ。しかし、その瞬間にそれを処理するエネルギーがある保証はない。ウェブの通知システムの大半は、メールクライアントが何十年も前にすでに達成していたことを不器用に真似しているように見える。もしかすると、昔の人たちがメールを使っていたのは本当に正しかったのかもしれない

    • メールも通知なのに、届いた瞬間にどうしてそれを受け取る気分になっていると言えるのか、もう少しはっきり説明してくれないか

  • MicrosoftがGitHubを取り込んだとき、すでに多くの人が苛立っていた。ただ、現実には代替がしばしばいまひとつだった。Sourceforgeは課題作成が延々と面倒で、GitLabはSourceforgeよりはましだが、それでも課題を作るのは嫌だ。Codebergは最近UIが変わったようだが、依然としてかなり使いにくい
    GitHubが最初にうまくやったのは、UIとGitHubを使う人々に焦点を当てて、作業を簡単に、あるいはより簡単にしたことだ。ただ、何もかも上手かったわけではなく、wiki対応はひどいと思う。あまりにひどいのでwikiはほとんど使わない。本当に大きな問題は、商業的利害、つまり私的利害だと思う。Microsoftはその一例にすぎず、似たようなサイトのほとんどどこにでもある問題だ。以前、xzバックドア関連ユーティリティの課題議論を例に出したし、私自身も議論に参加したが、翌日Microsoftが全部消した。Microsoftだったのかリポジトリ所有者だったのかは重要ではない。問題は、個人が潜在的に有用な情報をあまりにも簡単に検閲できることだ。その課題議論は有用で、そして検閲された。当時、情報はすべて復元されていなかったと記憶している。誰かがミラーしていたのかもしれないが、リンクは見なかった。これはトップダウン統制が本当に有害になり得ることを示している。正直、Microsoftをどれだけ信頼できるだろう？ 脱中央集権的で、安定してうまく動き、デフォルトUIが良く、シンプルか少なくとも優れたワークフローが必要だ。私的主体が皆を人質に取る状況も避けなければならない。どう解くべきかはまったく分からず、複数のアプローチが同時に必要かもしれない。ウェブは変わってしまい、特に巨大な超大企業の私的利害が、この10〜15年で状況をずっと悪くしたように感じる。変わるべきだ

    • 問題は、SaaS製品の運営には多額の金がかかることだ
      巨大企業ならそのコストを払えるが、予算の小さい開発者が大勢集まっても、同じことをするだけの金はない。だからどんな商用プロジェクトも結局、平均的な人より巨大企業の利害をより支える方向に向かわざるを得ない