Appearance
5. ブランチを準備する
概要
main から develop を作り、develop から feature ブランチを作ります。
ブランチを作ると、未完成の変更を安定したコードから分離できます。複数の作業を並行して進められるほか、Pull Request で差分をレビューし、CI が成功した変更だけを共有ブランチへ取り込めます。
このハンズオンでは、feature ブランチを develop へマージして変更を統合し、動作を確認してから develop を main へマージしてリリースします。
補足: Git Flow とは
Git Flow は、リリース済みのコードを管理する main、次のリリースに向けて変更を統合する develop、個別機能を実装する feature を中心に、release と hotfix を使い分けるブランチモデルです。定期的にバージョンをまとめてリリースする製品では、開発中、リリース準備中、公開済みのコードを分離できます。
完全な Git Flow では、feature を develop へ統合し、リリース前に release ブランチで最終調整します。緊急修正は main から hotfix を作り、修正後に main と develop の両方へ反映します。このハンズオンでは流れを理解しやすくするため、release と hotfix を省略し、feature → develop → main の部分を体験します。
Git Flow はすべての開発に必要なわけではありません。継続的に小さな変更をデプロイするチームでは、main から短期間のブランチを作る GitHub Flow など、より単純なモデルが適する場合があります。リリース頻度、並行開発の数、承認手順に合わせて選択します。
参考資料:
手順
1. develop を作成する
最新の main から develop を作成してリモートへ push し、変更の統合先として利用できる状態にします。
Agent モードで以下の指示を与えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
作業ツリー、現在のブランチ、origin/main との同期状態を確認し、main を fast-forward で最新化してから main を起点に develop を作成する計画を示してください。
develop の作成と origin への初回 push について対象と影響を要約し、askQuestions で明示的な承認を得てから実行してください。未コミット変更、既存 develop、起点や remote の不整合があれば変更せず質問してください。
実行後にローカルとリモートの develop を確認してください。次を確認します。
mainが fast-forward で最新化され、mainを起点にdevelopが作成されている- 作成と初回 push の対象と影響を確認して明示的に承認するまで実行されていない
- ローカルとリモートの
developが報告されている - 未コミット変更や起点の不整合がある場合は変更されていない
powershell
# main ブランチへ切り替えます
git switch main
# リモートの main ブランチを fast-forward で取り込みます
git pull --ff-only
# main から develop ブランチを作成して切り替えます
git switch -c develop
# develop ブランチをリモートへ初回 push し、追跡先に設定します
git push -u origin developbash
# main ブランチへ切り替えます
git switch main
# リモートの main ブランチを fast-forward で取り込みます
git pull --ff-only
# main から develop ブランチを作成して切り替えます
git switch -c develop
# develop ブランチをリモートへ初回 push し、追跡先に設定します
git push -u origin develop2. feature ブランチを作成する
作成した未完了 Issue の番号を取得し、ブランチ名を組み立てます。
Agent モードで以下の指示を与えます。
text
現在の GitHub リポジトリで、未完了かつタイトルが「残席が少ないイベントを分かりやすくする」と一致する Issue を読み取り専用で検索してください。
一致する1件の Issue 番号を取得し、後続で使う feature/<Issue番号>-low-availability というブランチ名を示してください。0件または複数件なら推測せず質問し、ブランチはまだ作成しないでください。次を確認します。
- 未完了でタイトルが一致する Issue が1件だけ特定されている
- ブランチ名が
feature/<Issue番号>-low-availabilityとして示されている - Issue が0件または複数件の場合は推測されていない
- ブランチはまだ作成されていない
powershell
# 未完了 Issue の番号とタイトルを取得します
$issues = gh issue list --state open --limit 100 --json number,title | ConvertFrom-Json
# 演習で作成したタイトルと一致する Issue を1件選びます
$issue = $issues |
Where-Object { $_.title -eq "残席が少ないイベントを分かりやすくする" } |
Select-Object -First 1
# 選択した Issue の番号を変数へ保存します
$issueNumber = $issue.numberbash
# 演習で作成したタイトルと一致する未完了 Issue の番号を取得します
issue_number=$(gh issue list --state open --limit 100 --json number,title \
--jq '.[] | select(.title == "残席が少ないイベントを分かりやすくする") | .number' |
head -n 1)GitHub で作成した Issue を開き、タイトル横に表示される番号を設定します（1 は実際の Issue 番号へ置き換えてください）。
powershell
# 作成した Issue の番号を設定します
$issueNumber = 1bash
# 作成した Issue の番号を設定します
issue_number=1取得した Issue 番号を使って develop から feature ブランチを作成し、実装を開始できる状態にします。
Agent モードで以下の指示を与えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
現在のブランチが develop、作業ツリーが clean、Issue 番号とブランチ名が確定済みであることを確認し、develop を起点に feature/<Issue番号>-low-availability を作成して切り替えてください。
同名ブランチ、起点不整合、対象不明があれば変更せず質問してください。push、コミット、ファイル変更は行わず、実行後に現在のブランチと起点コミットを報告してください。次を確認します。
- 作成前のブランチが
developで、作業ツリーが clean である developを起点にfeature/<Issue番号>-low-availabilityが作成されている- 現在のブランチと起点コミットが報告されている
- push、コミット、ファイル変更が行われていない
powershell
# Issue 番号を含む feature ブランチ名を組み立てます
$featureBranch = "feature/$issueNumber-low-availability"
# develop から feature ブランチを作成して切り替えます
git switch -c $featureBranchbash
# Issue 番号を含む feature ブランチ名を組み立てます
feature_branch="feature/$issue_number-low-availability"
# develop から feature ブランチを作成して切り替えます
git switch -c "$feature_branch"確認事項
- 現在のブランチが
feature/<Issue番号>-low-availabilityである - feature ブランチが
developを起点としている
まとめ
main から変更を統合する develop ブランチを作り、さらに develop から実装作業用の feature ブランチを作成しました。未完成の変更を共有ブランチから分離することで、実装途中のコードがリリース対象へ混入することを防げます。
feature ブランチ名には Issue 番号を含めました。これにより、ブランチ、コミット、Pull Request、Issue の関係をたどりやすくなり、何のための変更なのかをチームで共有できます。また、ブランチの起点を develop にそろえることで、次に統合するコードとの差分を正しく確認できます。
補足: 実務で役立つブランチ運用
- ブランチを作る前に起点となるブランチを更新し、古いコードから作業を始めないようにします。
- 1つのブランチでは1つの目的だけを扱い、レビューできる大きさに保ちます。
feature/<Issue番号>-<変更内容>のような命名規則を決めると、一覧から目的を判断しやすくなります。- 長期間使うブランチでは、統合先の更新を定期的に取り込み、競合を早い段階で見つけます。取り込み方法はチームのルールに従います。
- マージ済みの feature ブランチは削除し、完了した作業と進行中の作業を区別します。
mainやdevelopへの直接 push を制限し、Pull Request、レビュー、CI を経由するルールを設定すると、安全性を高められます。
次は、この feature ブランチ上でコードとテストを変更し、Issue に記載した完了条件を実装します。