main へ統合する
「land しました」と聞いたとき、何が起きたのでしょうか
止まった理由と、mainへの合流後に残る確認を見てみましょう。
01異変
合流が止まった
未完了に気づくmainへの合流が止まったと連絡が来ました。何が起きたのでしょう？
02確認
検査が不合格だった
結果と原因を調べる自動検査が不合格でした。担当者が結果を調べ、原因を確認します。
03対応
直して、もう一度
修正した版を再確認担当者が作業用の枝で修正し、その版でレビューと検査をやり直しています。
04再確認
合流の次は検証
本番公開はまだ先検査が完了し、合流できました。次はstgを更新して、画面を確かめます。
/git land の関所
/git land は、生成AIに main への統合を依頼する指示です。変更の送信と下書きのPRの準備、最新の変更の取り込み、レビューの確認、下書きの解除、自動検査を順に行います。「landしました」は、main に合流したという報告です。本番公開や検証環境の更新が終わったという意味ではありません。
/git land の検査と合流手順
- 止まる経路
各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
業務フロー図「/git land の検査と合流手順」。レーン4本、工程11個。 【レーン（担当）】（左から右） - あなたの枝: 作業用のブランチ - /git land: 統合を担う道具 - GitHub: 本流の保管庫 - stg 環境: 検証用ステージング 【図の符号】破線=止まる経路 【工程】（上から下へ。担当 → 工程名） ── フェーズ: 準備 ── 1. あなたの枝: 一時ブランチで実行〔開始・終了〕（/git land の開始） 2. /git land: Draft PR を整える（送信して base を main に） 3. /git land: main からの遅れは？〔分岐〕（最新の取り込み確認） はい → /git sync で同期 いいえ → レビュー済み？ 4. あなたの枝: /git sync で同期（最新 main を取り込んで push） ── フェーズ: 関所 ── 5. /git land: レビュー済み？〔分岐〕（承認マーカーの確認） いいえ → レビュー実行または省略 はい → Draft を解除 6. /git land: レビュー実行または省略（advisory のみ軽量スキップ可） 7. GitHub: Draft を解除（Open PR へ昇格） 8. GitHub: checks は全部緑？〔分岐〕（自動検査の合否判定） いいえ → 中断して枝で修正（破線） はい → squash マージ 9. あなたの枝: 中断して枝で修正〔開始・終了〕（main には入らない） ── フェーズ: 合流 ── 10. GitHub: squash マージ（1つに束ねて合流・枝削除） 11. stg 環境: stg へ反映〔開始・終了〕（auto は自動 / manual は案内）
守りの強さは、GitHub の設定が決める
保護の方式は2つあります。GitHub自身が条件を満たさない合流を止める方式が strict、5slab の /git land の手順で止める方式が advisory です。後者ではGitHub画面から直接合流すると検査を飛ばせてしまうため、決めた手順を使います。保護設定に不備があるときや、状態を確認できないときも統合を止めます。
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表「2つの保護モードの違い」。2列 × 4行。 【列】 1. strict モード（GitHubの保護機能が制限） 2. advisory モード（ツールによる安全確認） 【比較】（観点ごとに） ■ いつそうなるか - strict モード: 保護と関所が有効 / 有料プランまたは公開リポジトリ - advisory モード: プラン制限時のみ / 契約上の利用制限 ■ 何がルールを強制するか - strict モード: GitHub サーバー / PR・レビュー・直押し禁止を強制 - advisory モード: /git land の手順 / ツールの検査待ちと判定 ■ レビューのスキップ - strict モード: 一切スキップ不可 / レビュー証跡が必須 - advisory モード: 軽量変更のみ明示可 / 3ファイル・50行以内など ■ 自動検査（checks）の扱い - strict モード: GitHub が拒否 / 必須検査が赤なら遮断 - advisory モード: /git land が判断 / 検査の合格を待って合流 【観点】 - 守りの実体を見る: strict モード / advisory モード
合流したあとに起きること
検証環境（stg）は、本番へ出す前に試す場所です。auto方式は、配備対象の変更が main に入ると更新を始めます。たとえば、この5Sラボのサイトはmanual方式なので、合流だけでは更新されません。担当者が対象の版を決め、/git stg で自動処理を起動します。
確認を頼まれたら、担当者から「検証用URL」と「反映した変更の一覧」を受け取りましょう。更新完了後に、依頼した操作と普段使う操作を試します。合流の報告だけを見て、古い検証画面を確認済みにしないことが大切です。
どこまで進めるかを確認する
統合や検証環境の更新も、依頼した範囲で進めます。manual方式では、検証環境への反映まで依頼済みなら重ねて確認しません。本番へ出すときは、公開する候補を人が確認して承認します。
押さえておきたい用語
- /git land
- checks（自動検査）
- guard mode
- squash マージ
- stg（ステージング環境） この用語の解説を読む
- /git stg