【実務Gitフロー実践ガイド】チーム開発で衝突を防ぎながら爆速で開発を進める方法

Last updated at 2026-08-23Posted at 2026-08-23

前書き

今回の記事の執筆に至った経緯として、
未経験から挑戦しにきた友人から改めて訊かれ、自分も感覚的にやっていたので今一度整理しておきたく筆を取りました。

チーム開発では、複数のメンバーが同時に異なる機能や修正を行います。その際、全員が別々のファイルを触っているとは限らず、共通のファイル（ヘッダー、共通レイアウト、共通設定など）を同時に編集することは日常茶飯事です。

「誰かの修正が main にマージされるのを待つ」のではなく、「自分のブランチを常に最新の main に追従させ続ける」というプロの立ち回りを身につけることで、マージ時の事故（コンフリクトによるシステム破損）を防ぎ、自分の作業を一切止めずに開発を進めることができます。

ブランチ名と中身を一致させる
- 例：feature/add-conductor（案内ページの追加）というブランチを作ったら、その中には案内ページ以外の変更（SNSアイコンの追加など）を混ぜない。
- 「ついで」に別件の修正を混ぜると、Gitの履歴（Git Log）やPRの意図が汚染され、後からバグの原因特定やコードレビューが非常に困難になります。
同じファイルを触る修正が複数ある場合
1. main ではなく、最新の状況に合わせて別のフィーチャーブランチを切る
  - レビュー中のブランチとは別に、現在の最新 main から新しいブランチを切って paralelo（平行）に作業を進める。
2. 依存関係があるなら、前のブランチから生やす
  - もし「前のPRの修正内容が入っている前提で次の機能を書きたい」という場合は、main からではなく前の作業ブランチから新しいブランチを切るという手法を取ることもあります（※ただ、これやるとレビューが複雑になるのでチームの文化によります）。

自分が作業している最中に、他のメンバーのPRが先に main にマージされた場合、自分の手元のブランチは「古い状態」に取り残されます。これを安全に最新化するための手順です。

自分の作業用ブランチ（例: feature/xxx）にいる状態で、GitHub上の最新情報を手元に安全にダウンロードします。コードはまだ書き換わりません。

bash
git fetch origin

自分のブランチに対して、GitHub上の最新の main（origin/main）を取り込みます。

bash
git merge origin/main

なぜ main ではなく origin/main なのか？
- 単に git merge main とすると、自分のパソコン内にある古いローカルの main を参照してしまうリスクがあるため、GitHub上の正真正銘の最新である origin/main を指定します。

git merge origin/main を実行した際、自分と他のメンバーが「同じファイルの同じ行」を修正していた場合、Gitはどちらを優先すべきか判断できず、以下のようなコンフリクト（衝突）を発生させます。

CONFLICT (content): Merge conflict in src/components/Header.tsx

そういう時は以下の4ステップを参考にしてみてくださいな。

エディタ（VS Codeなど）で該当ファイルを開く
- ファイル内に <<<<<<< HEAD や ======、>>>>>>> origin/main といった特殊なマーカーが表示されます。
- 上側が「自分の変更」、下側が「取り込もうとした最新の変更（他人の変更）」です。
どちらのコードを残すか選ぶ（または両方残すように書き直す）
- VS Codeの上部に表示される「両方の変更を取り入れる」「現在の変更を採用する」「受信側の変更を採用する」などのボタンを使って綺麗に整えます。
修正したファイルをステージングに追加する
```
bash
git add .
```

マージコミットを作成してプッシュする

bash
git commit -m "fix: resolve merge conflict with main"
git push origin 自分のブランチ名

このフローが体に染み込むと、何十人・何百人規模の開発現場であっても、他人の足を引っ張ることなく、自分のペースで安心して爆速開発ができるようになります。
ちなみにSourceTreeは知りません。堪忍を。