基本の流れ
「枝を切って、PR 出しておきました」は、何をしたのでしょうか
担当者の報告を、何が済んだかに置き換えて読んでみましょう。
01疑問
用語がいっぱい
報告の意味が分からない「コミットしてpush、PRを作りました」。いま何が済んだのでしょう?
02体験
提案書を見てみる
まず目的と結果を見る教えてもらったPRを開いたら、変更の説明と画像がありました!
03仕組み
作業を順にたどる
記録から合流へ枝で編集し、記録して送信。PRで確認を頼み、合流する流れです。
04納得
次の確認が分かった
自分の確認へつなげるいまは提案の段階ですね。頼んだ内容になっているか、確認します。
記録から共有、提案へ進む
開発者は、全員の変更をまとめる基準の枝(main)から、作業用の枝(ブランチ)を新しく作ります。「枝を切る」とは、この操作の呼び名です。編集した内容をコミットで記録し、push で共有して、PR で提案します。確認後にマージで main へ合流させ、最後に pull で手元にも最新を取り込みます。
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「手元から本流合流までの一連の手順」。参加者4人、ステップ9個。 【参加者】(左から右) - 作業担当者: 手元で作業 - ローカル Git: PC内の履歴台帳 - GitHub: 共有サーバ - レビュアー: 確認と承認 【流れ】(上から下へ) ── ① 枝を切る ── 1. 作業担当者 → ローカル Git: 作業用の枝(ブランチ)を作る ── ② 手元で刻む ── 2. 作業担当者(自身で処理): ファイルを編集する 3. 作業担当者 → ローカル Git: 変更を選んでコミット ── ③ 共有する ── 4. ローカル Git → GitHub: 枝を push ── ④ 提案して合流 ── 5. 作業担当者 → GitHub: プルリクエスト(PR)を作る 6. GitHub → レビュアー: レビューを依頼 7. レビュアー → GitHub: 確認して承認(応答) 8. GitHub(自身で処理): main にマージ ── ⑤ 最新を取り込む ── 9. GitHub → ローカル Git: main の最新を pull(応答)
小さくこまめに刻む記録の基本
コミットには「何をなぜ変えたか」を残します。たとえば「申込期限を変更」と「問い合わせ先を追加」を別々に記録すると、後から理由をたどりやすくなります。5slab の生成AIへの指示 /git save も、普通の Git の commit と同じく手元へ記録するだけです。送信(push)と下書きのPRの作成は、main への統合を頼む /git land がまとめて行います。
依頼した変更を確認するときは、担当者からPRのURLを受け取り、まず説明文と画面の画像を見ます。細かな変更一覧は、PR画面の Files changed(変更ファイル)タブにあります。追加の修正も同じPRに送れるので、一度提案したら完成という意味ではありません。main への合流後も、本番公開には検証と承認が必要です。
秘密を記録してしまったら
パスワードや、外部サービスを操作するための鍵(APIキー)は履歴に残しません。誤って含めたと気づいたら、送信や共有を止めて担当者に知らせます。漏れた可能性があれば、管理者が鍵を無効化して交換します。ファイルから消すだけでは十分ではありません。
押さえておきたい用語
- ブランチ(枝)
- コミット
- push(プッシュ)
- プルリクエスト(PR)
- マージ(合流) この用語の解説を読む
- pull(プル)