Git・GitHubを使った開発フロー
GitHub DesktopとGitHubのWeb画面で操作
1 / 22mainへ直接送らず、ブランチで作ってプルリクエストで確かめる。
ブランチの変更をmainへ取り込むことをマージと呼びます。一人で作るときも、見直してから入れられます。
main：みんなが使う基準のブランチ。前回のmyprojectにも最初からある
ブランチで作り、mainへ入れるまでを4段階で進める。
例：myprojectのmypage.htmlに、お問い合わせ欄を足す
ブランチで何をしても、マージするまでmainは変わらない。
作業用のブランチを、mainから作る。
GitHub Desktop 3.x・前回のmyprojectを開いた状態
mainにいる状態で作ると、mainが元になります。
ブランチ名は、中身が分かる英語を2〜3語つなぐ
ブランチに記録しても、mainは変わらない。
commitの手順は前回と同じです。違うのは、commitがブランチに積まれることだけです。
mainへ切り替えると、フォルダの中身もmainの状態に戻る
Publish branchで、ブランチをGitHubへ送る。
ブランチを送っただけでは、GitHubのmainは変わりません。
このブランチへの2回目からは、Push originで送る
プルリクエストは「このブランチをmainへ入れたい」という提案書。
入れたいブランチと入れ先の組で作る（例：add-contact → main）
提案の説明と会話。タイトル・説明・レビューのコメントが時系列に並ぶ。
このブランチに積んだcommitの一覧。直すたびに増える。
自動の検査の結果。緑は合格、赤は不合格。
mainと比べて変わった行（差分）。レビューはここを読む。
PRの画面は、この4つのタブで1つの提案を見せます。
PRはpull requestの略。提案をmainへ取り込むことをマージと呼ぶ
PRは、Draft・Open・Mergedの順に進む。
この図をテキストで読む
状態遷移図。4状態・4遷移。 【状態】（★ = 焦点） 1. Draft（作業中・マージできない）〔開始〕 2. Open（レビューと検査を待つ） 3. ★ Merged（mainに入った）〔終了〕 4. Closed（マージせずに閉じた）〔終了〕 【遷移】（A —[イベント [条件] / 動作]→ B） - Draft —[Ready for review]→ Open - Open —[Convert to draft]→ Draft - Open —[緑ならSquash and merge]→ Merged - Open —[Close pull request]→ Closed 開始: Draft から始まる。 終了: Merged / Closed で終わる。
最初からOpenで作ることもできます。Closedは取り下げた提案で、Reopenで開き直せます。
Ready for reviewのボタンでDraftを外すと、表示がOpenになる
Draft PRで、途中のまま見せる。
Preview Pull Request → Create Pull Requestで開く
Draftで作れば、途中のままでも見せて相談できます。
GitHubのプランでDraftを選べないときは、通常のPRで進める
Draftは「まだ途中」の印。マージできない。
5S LABのリポジトリでは、Draftの間は自動の検査を止め、Openになってから実行します。
Draftのままレビューを受け、指摘は同じブランチで直す。
レビューは人のほか、AIに頼むこともできます。どちらも、読むのはFiles changedの差分です。
PRを作り直す必要はない
Ready for reviewで、Draftの印を外す。
検査の中身はリポジトリごとに決めます。テストや書式の確認などです。
検査がすべて緑になってから、マージする。
赤いままマージすると、検査に通らない変更がmainに入ります。緑になるまで待ちます。
Squash and mergeで、1つの記録にしてmainへ入れる。
マージボタンの▼で選び、Confirm squash and mergeで確定
mainの履歴は「PR1つ＝記録1つ」で読めます。途中の3つは、PRの画面に残ります。
末尾の(#1)はPRの番号。GitHubが自動で付ける
マージしたら、ブランチを消して手元のmainを最新にする。
次の作業は、最新のmainから始めます。
消したブランチは、PRの画面のRestore branchで戻せる
作る・見せる・確かめる・入れるの順で進める。
Claude Codeでは、同じ流れを/gitが進める。
例：5slab/claude-plugins（5S LABのプラグイン）
送るところからマージまでは、/git landが受け持ちます。
/git land 1回で、止まる理由がなければマージまで進む。
この図をテキストで読む
状態遷移図。5状態・5遷移。 【状態】（★ = 焦点） 1. 手元のcommit（/git saveで記録済み）〔開始〕 2. Draft PR（AIがレビューする） 3. Open（review-gateなどの検査） 4. ★ マージ済み（mainに入った）〔終了〕 5. 止まって報告（直して/git landをもう一度）〔終了〕 【遷移】（A —[イベント [条件] / 動作]→ B） - 手元のcommit —[送ってDraft PRを作る]→ Draft PR - Draft PR —[指摘がなければ総評を書く]→ Open - Open —[緑ならSquash and merge]→ マージ済み - Draft PR —[重大な指摘が残る]→ 止まって報告 - Open —[検査が赤]→ 止まって報告 開始: 手元のcommit から始まる。 終了: マージ済み / 止まって報告 で終わる。
review-gateは、最新のcommitにレビューの総評（結果をまとめたコメント）があるかを確かめます。総評の後にcommitを足すと通りません。
重大な指摘：AIのレビューが「直すまで入れない」とした指摘
versionを上げてマージした時点で、配布が始まる。
アプリのリポジトリは、マージの後にstg（検証環境）・本番へ届ける
用語集｜ブランチとプルリクエスト
みんなが使う基準のブランチ。直接は変えず、マージで入れる。
作業の流れを分ける線。mainもその1つ。
ブランチをmainへ入れたいという提案書。
作業中の印。マージできず、Ready for reviewで外す。
PRの状態の表示。Openは受付中、Closedはマージせずに閉じた提案。
用語集｜確かめてマージする
変わった行を読み、指摘や承認をすること。人のほかAIにも頼める。
PRごとに自動で走るテストや確認。緑が合格、赤が不合格。
ブランチの変更をmainへ入れること。
マージの方法の1つ。PRのcommitを1つにまとめてmainへ入れる。
用語集｜自動化とプラグイン
GitHubの上で、決めた作業を自動で動かすしくみ。検査もこれで動く。
最新のcommitにレビューの総評があるかを確かめる、5S LABの検査。
Claude Codeにコマンドや確認の仕組みを足すひとまとまり。/gitもその1つ。
プラグインの一覧。利用者はここから入れ、/setup pluginsで更新する。