Gitチーム開発ベストプラクティス：コンフリクト地獄からの脱出

はじめに

「すみません、masterブランチ消しちゃいました」
金曜日の午後5時、新人の沈痛な声がオフィスに響き渡りました。全員の背筋が凍ったのを覚えています。幸い、Gitは分散管理システムなのでローカルから復旧できましたが、私の寿命は確実に3年縮みました。

また別の現場では、「コンフリクト解消だけで半日が終わる」という地獄のようなプロジェクトもありました。マージするたびに数十ファイルの衝突が発生し、コードレビューは「LGTM（Looks Good To Me）」という名の思考停止ボタンと化していました。

Gitは強力なツールですが、使い手次第で武器にも凶器にもなります。
この記事では、私が数々の修羅場をくぐり抜けて辿り着いた「チーム開発におけるGitの正解」を共有します。教科書的なコマンド解説ではなく、**「どう運用すれば事故が起きないか」「どうすれば開発スピードが上がるか」**に焦点を当てます。

第1章：ブランチ戦略を選ぶ

「どのフローがいいですか？」とよく聞かれますが、答えは「チームの規模とリリースの頻度による」です。

1. Git Flow

最も有名ですが、最も複雑です。master, develop, feature, release, hotfix の5種類のブランチを使います。

メリット：リリース管理が厳格。バージョンごとのメンテナンスがしやすい。
デメリット：複雑すぎる。CI/CDと相性が悪い。
推奨：定期リリース（例：2週間に1回）をしている受託開発や、大規模なエンタープライズ製品。

2. GitHub Flow

シンプルです。main ブランチと feature ブランチだけです。

メリット：学習コストが低い。CI/CDと相性抜群。
デメリット：本番環境へのデプロイフローがしっかりしていないと、バグが即本番に出る。
推奨：Webサービス、スタートアップ、継続的デプロイを行っているチーム。
個人的には、9割のプロジェクトはこれで十分だと思っています。

3. Trunk Based DevelopmentTBD）

上級者向けです。全員が main（Trunk）に直接、あるいは超短命なブランチからマージし続けます。

メリット：統合の痛みが最小限。マージコストがほぼゼロ。
デメリット：高度な自動テストとFeature Toggle（機能フラグ）の実装が必須。
推奨：GoogleやFacebookのような、テスト自動化が完備された超ハイレベルなチーム。

第2章：ブランチ管理の鉄則

どの戦略を選ぶにせよ、以下のルールは絶対です。

1. ブランチ保護（Branch Protection）

GitHub/GitLabの設定で、main ブランチを保護してください。

Require pull request reviews before merging：最低1人の承認を必須にする。
Require status checks to pass before merging：CI（テスト、Lint）が通らないとマージボタンを押せなくする。
これだけで事故の90%は防げます。「間違ってpushしちゃった」を物理的に不可能にするのです。

2. 命名規則

ブランチ名から中身が推測できるようにします。

feat/user-login：機能追加
fix/login-bug：バグ修正
chore/update-deps：雑務（依存関係更新など）
hotfix/critical-error：緊急修正
悪い例：update-code（何のだよ！）、easton/work（個人の日記か！）

第3章：コミットとPRの作法

1. コミットメッセージ

「修正」とか「update」とか書いていませんか？ 1ヶ月後の自分が泣くことになります。
Conventional Commits を採用しましょう。

feat: ユーザーログイン機能を追加
fix: パスワードリセット時のバリデーションエラーを修正
docs: READMEにセットアップ手順を追記
style: インデント修正（ロジック変更なし）
refactor: 認証ロジックのリファクタリング
test: ログインAPIのテスト追加
chore: ビルドスクリプトの更新

これを守ると、リリースノートの自動生成などが楽になります。

2. PR（プルリクエスト）は小さく！

これが一番重要です。**「巨大なPRは、誰にもレビューされない」**という法則があります。
1000行の変更を渡されたら、レビュアーはスクロールして「LGTM」と言うしかありません。

目安：1つのPRは200行以内、または1つの機能単位。
分割：機能が大きくなるなら、feat/login-backend と feat/login-frontend に分ける。

3. マージ戦略：Merge vs Rebase vs Squash

Merge Commit：履歴が残るが、ツリーが汚くなる。
Rebase：履歴が一直線になり美しいが、コンフリクト解消が面倒な場合がある。
Squash Merge：PR内の細かいコミット（「typo修正」など）を1つにまとめてマージ。履歴が綺麗。

推奨：GitHub上での Squash Merge です。メインブランチの履歴が「1機能 = 1コミット」となり、非常に追いやすくなります。

第4章：コンフリクト地獄を避けるために

1. 最新のmainをこまめに取り込む

featureブランチで開発中、毎日朝イチで git pull origin main → git rebase main（またはmerge）をしましょう。
差分が小さいうちに解消すれば、ボヤで済みます。1週間放置すると火事になります。

2. 共通ファイルを触らない

チーム内で「誰がどこを触るか」を共有しましょう。「utilsファイルを全員がいじっている」状況は最悪です。コードのモジュール化を進め、責任範囲を明確にします。

3. ロックファイル（package-lock.jsonなど）を手動で直さない

これらは自動生成されるファイルです。コンフリクトしたら、基本的にロックファイルを削除して npm install し直すか、git checkout --ours/theirs で対応します。手で編集してはいけません。

第5章：効果的なコードレビュー

レビューは「粗探し」ではありません。「品質向上と知識共有の場」です。

レビュアーの心得

否定しない：「ダメです」ではなく「〜の方が良いと思いますが、どうでしょう？」と提案形で。
早めに返す：レビュー待ちは開発をストップさせます。半日以内にリアクションしましょう。
些末なことはLintに任せる：スペースとかセミコロンとかを人間が指摘するのは時間の無駄です。自動化してください。

レビュイー（依頼者）の心得

コンテキストを書く：PRの説明欄に「何をしたか」「なぜしたか」「どう検証したか（スクショなど）」を書く。
自分自身でレビューする：人にお願いする前に、一度自分で差分を見直す。console.log の消し忘れとか恥ずかしいですよ（自戒）。

まとめ：チームのためのGitチェックリスト

明日からチームで確認してほしいリストです。

main ブランチは保護設定されているか？
CI（自動テスト）はPR作成時に回っているか？
ブランチ命名規則はあるか？
コミットメッセージの規約（Conventional Commits）はあるか？
PRのテンプレート（説明欄のフォーマット）はあるか？
巨大なPR（500行以上）を放置していないか？

Gitは単なるバージョン管理ツールではありません。チームのコミュニケーションツールです。
ルールを守って、平和な開発ライフを送りましょう。

Gitチーム開発・ブランチ戦略決定ガイド

プロジェクトの特性に合わせた最適なブランチ戦略の選択と、安全な運用設定の手順

⏱️ Estimated time: 15 min

1
Step1: 戦略の選択
プロジェクトのタイプで選びます：
• Webサービス、継続的デプロイ → **GitHub Flow**（main + featureのみ。シンプル）
• パッケージ製品、受託開発、定期リリース → **Git Flow**（develop, releaseなどが存在。厳格）
• 超高速開発、テスト完全自動化済み → **Trunk Based**（main直コミット。上級者向け）
2
Step2: リポジトリの保護設定（GitHub例）
Settings -> Branches -> Branch protection rules から main ブランチを設定：
• Require a pull request before merging（PR必須）
• Require status checks to pass（CI通過必須）
• Require linear history（任意：マージグラフを綺麗に保つ）
3
Step3: 開発フローの確立
1. Issueを立てる（タスク定義）
2. ブランチを切る（命名：feat/issue番号-概要）
3. コミットする（Conventional Commits準拠）
4. PRを作成（テンプレート記入）
5. レビュー & CIパス
6. Squash Merge でマージ
4
Step4: トラブルシューティング
コンフリクト発生時：
• 慌てず git rebase main または git merge main で手元に最新を取り込む
• エディタのコンフリクト解消機能を使う（VS Codeのマージエディタ推奨）
• ロックファイル（yarn.lock等）のコンフリクトは、ファイルを削除して再インストールで再生成するのが安全

FAQ

MergeとRebase、どっちを使うべき？

ローカル作業での最新取り込みには **Rebase** を推奨します。履歴が分岐せず一直線になり、後で見やすくなります。ただし、すでにPushした共有ブランチをRebaseしてはいけません（歴史改変になるため）。
PRのマージには、GitHub上の **Squash Merge** がおすすめです。PR内の細かいコミットを1つにまとめてmainに入れるため、メインブランチの履歴が非常にクリーンになります。

コンフリクトが怖いです。どうすれば減らせますか？

1. **こまめな同期**：毎日mainブランチの内容をfeatureブランチに取り込んでください。
2. **PRを小さくする**：変更範囲が小さければ、衝突確率は下がります。
3. **責任範囲の明確化**：同じファイルを複数人が同時に触らないよう、事前にタスクを調整しましょう。

コミットメッセージの修正はどうやるの？

直近のコミットなら `git commit --amend` で修正できます。
それより前のコミットは `git rebase -i HEAD~n`（nは戻る数）を使いますが、これはPush前のコミットに限定してください。Push済みのコミットを書き換えると、チームメンバー全員に迷惑がかかります。

間違ってmasterに直接pushしてしまいました！

落ち着いてください。まず、他のメンバーに連絡し、誰もpullしないように伝えます。
その変更を新しいブランチに退避させ（`git branch new-feature`）、masterを元の状態に戻します（`git reset --hard origin/master` ※注意：ローカルの変更は消えます）。
そして何より、二度と起きないようにリポジトリ設定で**ブランチ保護（Branch Protection）**を有効にしてください。

3 min read · 公開日: 2025年11月24日 · 更新日: 2026年1月22日

Easton

技術開発

Gitチーム開発ベストプラクティス：コンフリクト地獄からの脱出

はじめに