GitHub Flow完全ガイド｜featureブランチをmainへmergeする実践的な流れを学ぶ
旅行先で地図を見ながら知らない街を歩くとき、いきなり目的地へ向かうより、小さな道を確認しながら進んだ方が迷いません。 Gitのブランチ運用も同じです。
実務開発では、いきなりmainブランチへ変更を入れることはほとんどありません。 機能ごとにfeatureブランチを作り、安全に開発を進め、レビューを受け、問題がなければmainへ統合します。
今回は実際のGitHub Flowを使いながら、featureブランチをmergeする流れ、Pull Requestの作法、コンフリクト解消、ブランチ保護、fork運用まで実践目線でまとめます。
GitHub Flowとは
GitHub Flowはシンプルなブランチ戦略です。 mainブランチを常に安定状態に保ちながら、新機能開発をfeatureブランチで行います。
- mainからfeatureブランチを作成
- 実装作業を進める
- ローカルでテスト
- GitHubへPush
- Pull Request作成
- コードレビュー
- テスト環境で確認
- mainへmerge
- 不要ブランチ削除
流れ自体は単純ですが、品質を維持するための仕組みが詰まっています。
featureブランチを作成して開発を始める
例えば認証機能を追加するとします。 mainで直接作業せず、新しいブランチを作ります。
git checkout main git pull origin main git checkout -b feature/authentication
ブランチ名は何を作るか分かる名前にすると管理しやすくなります。
開発現場では以下のような名前がよく使われます。
- feature/login
- feature/payment
- feature/profile-edit
- fix/header-bug
旅行の荷物にラベルを貼る感覚です。後から見ても迷いません。
実装後はローカル環境で必ずテストする
コードを書いたらすぐPushではありません。 まずはローカル環境で動作確認します。
- エラーが出ないか
- 機能が正常に動くか
- 既存機能を壊していないか
- テストコードが通るか
「GitHubへ上げてから直そう」はチーム開発では事故の元です。 自分のPCで安全確認してから共有します。
GitHubへPushする
git add . git commit -m "認証機能を追加" git push origin feature/authentication
PushするとGitHub側にfeatureブランチが作成されます。
mainブランチへ直接入れるのではなく、一度レビュー用の待機場所へ送るイメージです。
Pull Requestを作成する
GitHub Flowの中心になるのがPull Requestです。
Pull Requestは単なる「マージ依頼」ではありません。 変更内容を共有し、品質を高めるための重要なプロセスです。
Pull Requestの役割
- コードレビュー
- 品質保証
- 知識共有
- 変更履歴の記録
チーム開発では、誰がどんな理由で変更したかを残す意味もあります。
Pull Requestに書く内容
- タイトル（変更内容を簡潔に）
- 背景・経緯
- 実装内容
- 動作確認結果
- スクリーンショット
- 確認してほしいポイント
- その他注意事項
GitHubのPreviewを押せばMarkdown表示も確認できます。 レビューする人が読みやすい状態を作ることも開発スキルの一つです。
Reviewerを設定してコードレビューを受ける
Reviewerに担当者を設定します。
レビュー担当者は「Review changes」からコメントを追加できます。
確認されるポイントは例えば次のような内容です。
- 命名規則は適切か
- 不要なコードがないか
- 処理効率に問題はないか
- バグの可能性はないか
今回は自分でレビューする場合でも、一度客観的に見直す習慣を作ると品質が大きく変わります。
featureブランチをmainへmergeする
レビュー承認後、問題がなければMergeを実行します。
GitHub画面上で「Merge Pull Request」をクリックするとmainへ統合されます。
統合後は不要なfeatureブランチを削除しましょう。
git checkout main git branch -r
リモート追跡ブランチも整理され、リポジトリが見やすくなります。
コンフリクトが発生した場合の対処方法
チーム開発では避けて通れないのがConflict（競合）です。
同じ場所を別メンバーが変更すると、GitHubは自動で判断できなくなります。
GitHubでは次のように表示されます。
this branch has conflicts that must be resolved
その場合はmainの変更を取り込みます。
git fetch origin git checkout feature/authentication git merge origin/main
競合箇所を修正後、再度Pushします。
git push origin feature/authentication
コンフリクト予防策
- 小さな変更を頻繁にコミット
- Pull Requestを溜め込まない
- チーム内で変更範囲を共有
- 定期的にmainを取り込む
大きな変更をまとめて出すほど競合は増えます。 早め早めの共有が重要です。
ブランチ保護設定で事故を防ぐ
実務ではmainブランチを保護します。
「気をつける」ではなく「間違えられない仕組み」を作る考え方です。
ブランチ保護のメリット
- mainへの直接Push防止
- レビュー完了までMerge禁止
- 品質担保
- 運用ルール統一
設定手順
GitHub画面から設定します。
- Settings
- Branches
- Add Branch Ruleset
- 対象ブランチを指定
- ルールを追加
よく使う設定例はこちらです。
- Require a pull request before merging
- レビュー必須
- ステータスチェック必須
- 直接Push禁止
forkでリポジトリを派生させる
OSS開発ではforkも頻繁に使います。
他人のリポジトリを自分のGitHubアカウントへコピーする仕組みです。
forkのメリット
- 安全な実験環境
- OSS貢献しやすい
- 独自開発ができる
fork後にcloneする流れ
git clone URL fork-repo cd fork-repo ls
forkした直後はmainブランチだけ存在するケースが一般的です。
upstream設定
git remote add upstream URL git remote -v
originは自分のfork先、upstreamは元リポジトリです。 分けて管理すると更新追従が楽になります。
元リポジトリの更新を取得する
git fetch upstream git branch -r
最新変更を取り込み、常に同期された状態を維持します。
まとめ
GitHub Flowは単なる操作手順ではありません。 「安全に品質を守りながら開発を進める考え方」です。
- featureブランチで作業する
- ローカルで十分テストする
- Pull Requestでレビューする
- Conflictは早めに解消する
- ブランチ保護で事故を防ぐ
- fork運用も理解しておく
最初は手順が多く感じます。 ただ実務で毎日触っていると、旅行先で駅を乗り換える感覚のように自然と身についていきます。
まずは小さなfeatureブランチを作り、Pull Requestを作るところから始めてみましょう。
0 件のコメント:
コメントを投稿