5slab の一本道
5slab の開発は、いつも何をどの順で進めているのでしょうか
作る人と依頼する人の役割を、着手から公開まで追ってみましょう。
01困りごと
いま、どこまで？
次の行動が見えない「進んでいます」と聞いたけれど、私が確認するのはいつでしょう？
02工夫
下書きを共有
PRで状況を共有担当者が送信した下書きのPRで、目的と変更の中身を見られました。
03試す
画面を試してみる
stgで業務を確認検証用のURLが届きました。依頼した操作を試せる段階ですね。
04効果
この版を公開して
対象を指定して承認確認できました。この候補を本番へ公開してください、と伝えます。
着手から本番公開まで、6つの段階
ここからは、5slab の手順です。①着手、②手元への保存、③レビュー、④main への統合、⑤検証環境での確認、⑥本番公開と進みます。依頼する人はPRで変更の目的を確かめ、検証用のURLで実際の業務を試し、公開してよい版を伝えます。/git start は、手順書を使える生成AIへ、作業用の枝とフォルダを用意して着手するよう頼む指示です。GitHub の検索欄へ入力するものではありません。
着手から公開までの6段階
各ステップをクリックすると、その内容の説明がここに表示されます。
変更を作る → 検証環境で試す → 確認した版を承認して公開する
この図をテキストで読む
ステップ図「着手から公開までの6段階」。6ステップ。 【手順】（順番に） 1. 着手（/git start） 2. 保存（/git save） 3. レビュー（cross-review） 4. 統合（/git land） 5. 検証（stgで業務を試す） 6. 本番公開（/git release） 【流れ】 - 一本道の流れ: 着手 → 保存 → レビュー → 統合 → 検証 → 本番公開
いま居るブランチが、環境を決める
開発環境（dev）は変更を作る場所、検証環境（stg）は公開前に試す場所、本番環境（prod）は利用者が実際に使う場所です。5slab の道具には、作業中のブランチから操作先を選ぶものがあります。main のままでは本番へ向くため、開発者は読み取りだけにとどめ、編集やデータ投入は作業用の枝へ移ってから行います。
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
main でやってよいのは読み取りだけ — 作業は枝へ移ってから
この図をテキストで読む
比較表「ブランチと環境の対応表」。3列 × 3行。 【列】 1. 役割（何のための場所か） 2. 対応する環境（操作が届く先） 3. やってよいこと（許される操作） 【比較】（観点ごとに） ■ main（本流） - 役割: 常に公開できる正式な状態 / プロジェクトの背骨 - 対応する環境: prod（本番） / 手元の道具が向く操作先 - やってよいこと: 読み取りだけ / 状態変更は全面禁止 ■ 一時ブランチ - 役割: 1作業ごとの下書きの枝 / 作業ごとに作成 - 対応する環境: 専用の dev 環境 / 開発者ごとの独立環境 - やってよいこと: 依頼した範囲で編集・実験 / 状態変更もここで実施 ■ release タグ - 役割: 本番へ配備した版の記録 / 固定の記録 - 対応する環境: prod（本番） / 本番の公開時点 - やってよいこと: CI が新しく付与 / 人が手で改変しない 【観点】 - 作法で見る: やってよいこと
Issue から枝を切る、机を分ける
依頼する人は「何に困っていて、どうなれば完了か」を Issue（課題票）に書くか、担当者に伝えます。担当者は作業用の枝で編集し、手元に保存しながら進めます。下書きのPRは、統合の準備で変更を送信するときに開きます。PRには送信していない編集は見えないため、途中の状況は担当者に確認します。
担当者は作業ごとに、作業フォルダを分ける worktree を使います。/git start が既定で用意します。書きかけの机をそのままに、隣の机で別件を進めるイメージです。ファイルが混ざるのを防ぐ仕組みで、接続先の環境も分かれているかは別に確認します。
依頼する範囲を言葉にする
「保存まで」「mainへの統合まで」「検証環境へ反映」「この版を本番へ公開」のように、どこまで進めるか伝えます。範囲が曖昧なまま先へ進めず、担当者と確認します。同じ対象を既に承認している場合は、承認を繰り返す必要はありません。
押さえておきたい用語
- トランクベース開発
- 一時ブランチ
- Draft PR
- worktree
- /git スキル
- Issue（課題票）