Git 応用テクニック：チーム開発とブランチ管理のベストプラクティス

はじめに

同僚がチャットで @ しました。「さっきマージしたコードで、僕のログイン機能が上書きされた。本番ユーザーが入れなくなった……」

コードを開くと、コンフリクトマーカーだらけ。自分のコードと同僚のコードの区別がつかない。その夜の教訓——Git の基本コマンドが使えることと、チーム開発ができることは別問題。

ブランチが多すぎて覚えられない、マージが怖い、履歴が絡み合っている——そんな経験があれば、この記事が役立ちます。チーム開発で積んだ実戦知見を、ワークフロー選択からコンフリクト処理、rebase による履歴整理、コードレビューの流れまで共有します。読み終える頃には、チームに合ったブランチ戦略の選び方、コンフリクトの解き方、rebase の使い方、効率的なレビューの要点が身につきます。

第 1 章：チームに合った Git ワークフローを選ぶ

正直、最初にチームを率いたとき、どの Git ワークフローを使うべきか分かりませんでした。Git Flow がプロっぽいと聞いてそのまま導入したら、5 人の小チームでブランチ管理だけ毎日 30 分。結局みんなうんざり。

後から気づいたのですが、ワークフローに「最良」はなく「最適」しかない。

Git Flow vs GitHub Flow vs Trunk Based Development

3 つの違いをシンプルに説明します。

Git Flow は厳格な工場ラインのような方式です。develop、feature、release、hotfix など専用ブランチがあります。Microsoft や IBM のような大企業で、月 1 回など明確なリリースサイクルがある場合に向いています。

小チームには重すぎます。以前のチームでは、リリースのたびに develop から release を切り、テスト後 master にマージし、再び develop に戻す——この一連だけで相当な手間。

GitHub Flow はもっとシンプル。main（または master）だけが主軸で、機能はそこから feature ブランチを切り、PR でマージします。3〜10 人規模のチームに向き、高速イテレーションと継続的デリバリーを重視します。

今のチームも GitHub Flow + CI/CD 自動テストで、1 日に何度もリリースできます。メンバーも楽で、覚えるブランチルールが少ない。

Trunk Based Development（TBD） はさらに極端で、ほぼ main で直接開発し、ブランチ寿命は 1 日以内が普通です。Google や Meta のように強力な自動テストがある企業向け。

一般チームには攻撃的すぎます。テストカバレッジ 90% 以上でなければ、main を簡単に壊します。

2025 年のトレンド

最近の資料では、2025 年はハイブリッドモデルが主流です。1〜10 人の小チームは GitHub Flow + GitHub Actions や GitLab CI。中〜大規模チームは Git Flow の要素を GitHub Flow に組み合わせます。

知人の 20 人チームは「GitHub Flow + release ブランチ」：日常は GitHub Flow、リリース前だけ release ブランチで安定化。

私の提案：

• 1〜5 人：GitHub Flow で十分。考えすぎない
• 5〜15 人：GitHub Flow + 簡易 release
• 15 人以上：Git Flow またはハイブリッド。ただし CI/CD を整備

もう 1 点：過剰設計しない。最初から複雑なブランチ戦略を作ると誰も守らず、結局各自バラバラに戻りがち。

第 2 章：ブランチ管理の黄金律

チーム開発でいちばん頭を抱えるのがブランチ管理の混乱。以前のプロジェクトではリモートブランチが 70 以上、半数は 2 年前のゾンビブランチ。自分のブランチを探すだけで時間がかかりました。

その後まとめた「黄金律」を導入して、リポジトリがかなりすっきりしました。

ブランチ命名規則

まず命名規則。全ブランチにプレフィックス必須：

• feature/ — 新機能
• bugfix/ — バグ修正
• hotfix/ — 緊急修正
• release/ — リリース

タスク番号も必須。例：feature/JIRA-1234-user-login

一目で目的と担当が分かります。以前 test というブランチがあり、3 ヶ月後誰も覚えておらず削除するしかなかった。

避けるべき点：

• 中国語ブランチ名（一部システムで文字化け）
• 特殊文字（特にスペースと @）
• 単語区切りはハイフン -（アンダースコア _ は業界慣習で避ける）

ブランチライフサイクル

最悪の例：feature ブランチが 3 ヶ月放置され、マージ時にコンフリクトが解消不能で作り直し。

今はfeature ブランチは 3 日以内を徹底。機能が大きければ小さな feature に分割して段階的にマージ。

マージ後は即削除が鉄則。「後で使うかも」はほぼ起きません。Git に履歴は残っています。

削除コマンドはメモ帳に保存：

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

# ローカルブランチ削除
git branch -d feature/xxx
# リモートブランチ削除
git push origin --delete feature/xxx

ゾンビブランチが溜まっている場合：

# main にマージ済みのブランチを表示
git branch --merged main
# 一括削除（注意して実行）
git branch --merged main | grep -v "main" | xargs git branch -d

ブランチ保護

main を保護することも重要です。

最初は誰でも main に push でき、インターンが未完成コードを push してテスト環境が壊れたことがあります。

GitHub / GitLab で保護ルールを設定：

• main への直接 push 禁止、PR / MR 必須
• 最低 1 人 approve
• CI 必須（ユニットテスト、lint）

GitHub では Settings → Branches → Branch protection rules から設定。

面倒に見えても、初歩的なミスを防げます。レビュー自体も学習の機会になります。

第 3 章：Git Rebase vs Merge — いつどちらを使う？

rebase を初めて使ったときは本当に混乱しました。git rebase 後に commit ID が全部変わり、コードを失ったと思いました。

rebase も merge もコードを統合できますが、仕組みはまったく違います。

Merge と Rebase の本質

生活の比喩で説明します。

Merge は 2 本の川が合流するイメージ。どこで合流したか履歴に残り、merge commit ができてツリーに分岐が見えます。

Rebase は支流を主流に注ぎ直すイメージ。最初から 1 本の川に見えます。履歴を書き換え、コミットを 1 つずつ移動するため commit ID が変わります。

技術的には：

• Merge：ブランチの作成・マージ過程を含む完全な履歴
• Rebase：線形で見やすいが、ブランチの文脈は失われる

使い分けと黄金律

Merge を使う場面：

• feature を main に最終マージ
• チーム共有ブランチの統合
• マージ履歴を残したいとき

Rebase を使う場面：

• feature が main より遅れているときの同期
• 個人ブランチの履歴整理（push 前）
• 線形履歴を保ちたいとき

絶対守る黄金律：

push 済み共有ブランチのコミットに rebase しない！

rebase は commit ID を変えます。他人が古い commit をベースに作業していたら、あなたの rebase 後にブランチが乱れます。同僚がこのミスをして、チーム全員がブランチを取り直し、1 週間怒られました。

原則：ローカルでは rebase 自由、push 前に考える。

インタラクティブ Rebase 実践

git rebase -i（インタラクティブ rebase）は非常に強力です。

機能開発中に 10 回以上 commit し、メッセージが「fix」「修正」「また修正」ばかりだった経験。main にマージする前に git rebase -i で 3 つの明確な commit に整理しました。

# 直近 10 コミットを整理
git rebase -i HEAD~10

エディタに次のような一覧が開きます：

pick a1b2c3d ユーザーログイン機能を追加
pick e4f5g6h ログインバグを修正
pick i7j8k9l 再修正
pick m0n1o2p ログインロジックを最適化
...

操作の意味：

• pick — この commit を残す
• squash または s — 前の commit にまとめる
• reword または r — メッセージを変更
• edit または e — ここで止めて内容を修正
• drop または d — この commit を削除

例：

pick a1b2c3d ユーザーログイン機能を追加
squash e4f5g6h ログインバグを修正
squash i7j8k9l 再修正
reword m0n1o2p ログインロジックを最適化

最初の 3 つが 1 つにまとまり、4 つ目でメッセージ編集のプロンプトが出ます。

最初は複雑に感じますが、数回で慣れます。rebase 後の履歴は格段にきれい。「修正」「また修正」のような commit が消えます。

2025 年のベストプラクティス：ローカルで rebase して整理、main への統合は merge。main の履歴を保ちつつ、マージ情報も残せます。

第 4 章：コンフリクトに慌てない

Git コンフリクトにはトラウマがあります。初めて <​<<<<<< と >​>>>>>> だらけの画面を見て、自分のコードを全部消して書き直したことも。

コンフリクトは理解すれば怖くありません。マーカーの意味と予防策を押さえましょう。

コンフリクト予防のベストプラクティス

多くは予防できます。チームで次を徹底：

1. 1 日 1 回以上 main を同期

作業開始前：

git checkout main
git pull origin main
git checkout feature/xxx
git merge main  # または git rebase main

feature が main から遅れすぎず、マージ時のコンフリクトも減ります。

2. 小さくコミット、早くマージ

feature は 3 日以内。長く残すほど差分が大きく、コンフリクト率が上がります。

3. 共同作業前に連絡

同じファイルを触るなら事前に声をかける。Notion で「開発中機能」表を共有し、誰が何を触っているか可視化しています。

コンフリクトマーカーと手動解消

予防しても起きます。例：

<​<<<<<< HEAD
function login(username, password) {
  // あなたのコード
  return api.post('/login', { username, password });
}
=​======
function login(email, password) {
  // 同僚のコード
  return api.post('/auth/login', { email, password });
}
>​>>>>>> feature/new-login

読み方：

• <​<<<<<< HEAD から =​====== までが現在ブランチ
• =​====== から >​>>>>>> feature/new-login までがマージ元

残す部分を決めるか、両方を組み合わせます。username と email のどちらか、API パスはどれか——同僚と相談が必要なことも。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

解消後はマーカーを削除 git add . と git commit -m "ログイン機能のマージコンフリクトを解消"。

可視化ツールで効率化

手動は特にコンフリクトが多いと大変。今は VS Code 内蔵ツールが中心です。

コンフリクトファイルはハイライトされ、ボタンが表示されます：

• “Accept Current Change” — 自分のコードを残す
• “Accept Incoming Change” — 相手のコードを残す
• “Accept Both Changes” — 両方残す
• “Compare Changes” — 比較ビュー

複雑な場合は git mergetool + p4merge で 3 カラム（ベース、自分、相手）比較。

解消後の検証

コンフリクト解消後に push し、同僚の重要ロジックを誤って消して本番障害になった経験があります。解消後は必ず検証が習慣になりました。

毎回：

1. ローカルでテスト
2. git diff で誤削除がないか確認
3. 可能なら同僚に review

数分の手間で、多くの本番事故を防げます。

第 5 章：効率的なコードレビューの流れ

最初はコードレビューが嫌いでした。自分のコードは十分だと思っていたのに、指摘ばかり。何度も直させられて時間の無駄に感じました。

他人のコードをレビューするようになって、価値は「バグ探し」以上にあると分かりました。

コードレビューの本当の価値

少なくとも 3 つの価値があります。

1. 知識共有 — メンバーが互いの作業を把握し、情報サイロを防ぐ。PR レビューで「こう実装できるのか」と学ぶことが何度もありました。

2. 品質保証 — 他人の目が自分では見落とす問題を拾う。再帰関数を書いたとき、自分のテストでは問題なく、レビュアーが境界条件未処理を指摘。スタックオーバーフロー寸前でした。

3. 技術成長 — 優れたコードを読むのが最良の学習。シニアエンジニアの PR から多くのコーディング技法を学びました。

PR ベストプラクティス

レビューを効率化するには、PR 自体を良く書く必要があります。

PR サイズを適切に

200〜400 行が理想、500 行以内。大きすぎる PR は形式的なレビューになりがち。

機能が大きければ小 PR に分割。ユーザーシステムなら例：

• PR1：DB 設計と基本 model
• PR2：ユーザー登録 API
• PR3：ログイン API
• PR4：ユーザー情報更新 API

PR 説明を明確に

チームの PR テンプレート：

## 背景
なぜこの変更が必要か
## 変更内容
- xxx 機能を追加
- xxx バグを修正
- xxx モジュールをリファクタ
## テスト状況
- [ ] ユニットテスト通過
- [ ] ローカル機能テスト通過
- [ ] テスト環境で検証済み
## 注意事項
設定変更、DB マイグレーションなど

レビュアーが何を・なぜしたか一目で分かります。

Commit message を規範化

Conventional Commits に従い、タイププレフィックス必須：

• feat: ユーザーログイン機能を追加
• fix: パスワード検証バグを修正
• refactor: ユーザー service 層をリファクタ
• docs: API ドキュメントを更新

changelog 自動生成や履歴追跡が容易になります。

レビュアーと作者の役割

レビューは双方向です。

レビュアー：

• 24 時間以内に PR に返信
• 建設的な指摘（「こう書くとダメ」より「xxx に変更を提案。理由は…」）
• スタイルよりロジック・可読性・潜在バグ

作者：

• コメントに速やかに返信
• 設計意図を説明（理解されないならコードが不明瞭な可能性）
• 提案を素直に検討

最初は「ここがおかしい、直して」というコメントばかり。今は「このループはデータ量が多いと性能問題の可能性。xxx か xxx への変更を提案。どう思いますか？」と書くと効果が良い。

2025 年の新トレンド：AI 支援コードレビュー

2025 年は AI 支援レビューツールが増えました。GitHub は 10 月に Code Quality を発表し、保守性・セキュリティ問題を自動検出します。

試してみると、見落としがちな問題を拾えました：

• 未処理の例外
• 潜在的なメモリリーク
• 複雑すぎる関数（サイクロマティック複雑度が高い）

ただし AI は人工レビューの代替にはなりません。技術的問題は見つけても、設計意図やビジネスロジックの妥当性は人間の判断が必要です。

今のやり方：AI で明らかな問題を先に洗い出し、人間が設計とロジックを深くレビュー。効率が上がりました。

第 6 章：よくあるミスと避け方

最後に、チームで踏んだ坑を共有します。

force push の危険

feature が main よりかなり遅れ、rebase 後に push できない。ローカルとリモートの履歴が一致しない。

git push -f を見つけ「強制プッシュ、強そう」と使ったら、同僚が push したコードを上書き。バックアップがなければ 1 日分が消えていました。

git push -f（git push --force）はローカル履歴でリモートを上書きする最も危険なコマンドの 1 つ。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

使える場合：

• 個人の feature ブランチで、他に誰も使っていない

絶対禁止：

• main / master など共有ブランチ
• 他メンバーが使うブランチ

どうしても必要なら git push --force-with-lease。リモートに新コミットがあれば拒否されます。

その他の高頻度ミス

1. main で直接開発

1 文字の修正でもブランチを切り PR でマージ。レビュー記録が残り、問題時にロールバックしやすい。

2. 適当な commit message

「fix」「修正」「111」「asdf」——後から追跡できません。何を・なぜ変えたか毎回書く。

3. マージ済みブランチを削除しない

マージ後は即削除。GitHub / GitLab の PR マージ時「ブランチを削除」にチェック。

4. 盲目的な git add .

意図しないファイルまでステージング。.env（パスワード入り）を誤コミットした事例も。

git add -p で変更を 1 つずつ確認。遅いが安全。

チーム規約チェックリスト

参考用チェックリスト：

ブランチ管理

• 統一命名規則（feature/、bugfix/ など）
• タスク番号を含む
• feature ブランチ 3 日以内
• マージ後即削除
• main ブランチ保護

コードコミット

• 規範的 commit（タイププレフィックス）
• 1 commit 1 目的
• コミット前に lint とテスト
• 機密情報（.env、鍵など）をコミットしない

コードレビュー

• PR サイズ 200〜400 行
• 説明が明確（背景、変更、テスト）
• 1 人以上 approve
• CI 通過必須
• 24 時間以内に返信

コンフリクト処理

• 毎日 main を同期
• 解消後にテスト
• 不明点は同僚と連絡

禁止操作

• main で直接開発しない
• 共有ブランチに git push -f しない
• push 済み共有ブランチを rebase しない
• 未テストコードをコミットしない

まとめ

深夜 2 時の本番障害対応を思い出すと、当時これらの技法を知っていたら……。踏んだ坑は経験になりました。

Git 自体は難しくありません。難しいのはチームの合意です。どんなに良いワークフローも、メンバーが守らなければ意味がありません。

シンプルから始めて、段階的に最適化をおすすめします。最初から複雑な規約を作らず、チームの実情に合わせて調整を。

例：

• 1 週目：ブランチ命名を統一
• 2 週目：ブランチ保護を設定
• 3 週目：PR レビューの流れを確立
• 4 週目：commit message 規約を導入

ゆっくり、適応の時間を与えて。

いちばん重要なのはコミュニケーション。問題を一人で抱え込まず、同僚と議論を。多くの Git コンフリクトは技術よりコミュニケーションの問題です。

さらに Git スキルを上げたいなら：

• Atlassian Git Tutorial — 包括的な Git チュートリアル
• Pro Git 電子書籍 — 公式、無料オンライン
• GitKraken や SourceTree — 可視化 Git クライアント、初心者向き

次回は cherry-pick、stash、submodule など Git 上級テクニックを書くかもしれません。興味があればフォローを。

最後に、あなたとチームの Git 協業がますますスムーズになり、深夜の merge コンフリクト対応から解放されることを願っています！