リポジトリを守る仕組み

守りは何層あるのか

ファイルと履歴の保管場所（リポジトリ）では、確認していない変更の合流や、履歴の強制的な書き換えを防ぐ対策を重ねます。それぞれが担当する範囲は違います。対策があるから無条件に安全とは考えず、どの操作をどの仕組みが止めるかを確かめます。

advisory では、手順が受け持つ

advisory では、自動検査が不合格でも GitHub 画面から合流できてしまいます。担当者は /git land を使い、手順の中で検査を確認します。strict と同じ強制力があるわけではありません。管理者が保護を回避できる設定もあるため、直接の変更を通常の手順として使わないことが大切です。

review-gate は何を見ているのか

review-gate は、レビューした版と、合流しようとしている版が同じかを検査します。たとえばレビュー後にコードが変わっていたら、古い結果で進めず再確認を求めます。これはレビュー漏れを減らすための検査で、コードをもう一度点検する処理ではありません。

レビューの記録や検査設定を、編集権限のある人が書き換える可能性は残ります。管理者は招待する相手と権限を確かめ、不要になったアクセスを外します。依頼者は、知らない人が追加されていたり、検査を飛ばすよう求められたりしたら、担当者に確認しましょう。

押さえておきたい用語

branch protection

本流（main）を直接の変更から保護するGitHubの機能。提案書の必須化や強制プッシュの禁止などをサーバー側で強制する。

review-gate

提案書の末尾にあるレビュー証跡を検査するCIの仕組み。確認後に本流が進んでいないかや、変更規模の上限を判定する。

repo-guard

リポジトリの保護設定を自動化する道具。GitHubのAPI応答を判別し、環境に合わせて最適な保護ルールを適用する。

strict

GitHubのブランチ保護と必須チェックが有効な保護モード。保護対象の操作では、必須検査に通らない提案のマージをGitHub側で止める。

advisory

プラン制限などでGitHub側がマージを止められない保護モード。/git landの手順で合否を確認する。画面からの直接操作には同じ強制力がない。

レビューの記録

点検したコードの版と結果の記録。合流する版と照合し、再確認が必要かを判断する。