git pull origin developでコンフリクトしなかったのに、なぜupstream mergeでコンフリクトした?フォーク運用の落とし穴と対策
今回はgit pull origin developでコンフリクトしなかったのに、なぜupstream mergeでコンフリクトした?フォーク運用の落とし穴と対策の紹介です。
目次
結論
大体のことはこれで解決します。
git fetch upstream
git merge upstream/develop
フォークのコンフリクトについては以下を読んでいけば理解が深まります。
git pull origin developでコンフリクトしてないのに、コンフリクトと言われた
フォークしたリポジトリで作業していて、git pull origin developでコンフリクトしてないのに、コンフリクトと言われた経験ありませんか?
git pull origin develop→ コンフリクトなし、問題なし- PR出そうとしたら「コンフリクトしてます」と言われる
git merge upstream/develop→ 突然コンフリクト発生!
「さっきまで大丈夫だったのに…」
と混乱した経験、私にもあります。 この記事では、なぜこういうことが起きるのか、そしてどう対策すればいいのかを解説します。
スポンサードサーチ
フォークとは?
まず基本から。フォーク = リポジトリのコピーを自分のGitHubアカウントに作ることです。
本家リポジトリ (組織のリポジトリ)
↓ フォーク
自分のリポジトリ (個人のリポジトリ)なぜフォークするかというと:
- 本家に直接pushする権限がない
- 自分専用の作業場所が必要
- 本家を汚さずに開発できる
リモートリポジトリの関係性
フォーク運用では、通常2つのリモートリポジトリを扱います:
upstream (本家)
organization/repository
├── develop ← みんなのPRがここにマージされる
└── 常に最新の状態
origin (自分のフォーク)
your-account/repository
├── develop ← 本家と同期しないと古くなる
└── feature/xxx ← 作業ブランチ
スポンサードサーチ
問題が起きる仕組み
git pull origin develop でコンフリクトしない
git pull origin develop
# = git fetch origin + git merge origin/develop
これは自分のフォークから取得しているだけです。
自分のフォーク (origin/develop) ← 古い状態
↓ pull
作業ブランチ ← 古いものとマージするだけ
自分のフォークには他の人のPRがマージされていないので、コンフリクトしません。
git merge upstream/develop でコンフリクト発生
git merge upstream/develop
これは本家の最新状態とマージしようとしているわけです。
本家 (upstream/develop) ← 他の人のPRがマージ済み
↓ merge
作業ブランチ ← 同じファイルを変更していたらコンフリクト!
対策: コンフリクトを事前に防ぐ方法
基本戦略: 常に本家と同期する
# 作業開始前に必ず実行
git fetch upstream
git merge upstream/develop
これを毎日の作業開始時、またdevelopなどの更新日が決まっている時間の後に実行するだけで、コンフリクトのリスクが大幅に減ります。
なぜ効果があるのか
- 他の人の変更を早めに取り込める
- コンフリクトが発生しても早期に発見できる
- 小さなコンフリクトのうちに解消できる
おすすめワークフロー
# 1. 朝一番、または作業開始時
git checkout develop
git fetch upstream
git merge upstream/develop
# 2. 作業ブランチに反映
git checkout feature/your-branch
git merge develop
# 3. コンフリクトがあれば解消
# 4. 作業開始!スポンサードサーチ
応用: 事前確認のテクニック
マージせずにコンフリクトだけ確認
# コンフリクトするか確認したい
git fetch upstream
git merge --no-commit --no-ff upstream/develop
# コンフリクトがあれば表示される
# 確認後、中止
git merge --abort本家との差分を確認
# どのファイルが変わっているか
git diff upstream/develop...HEAD --name-only
# 自分の独自コミットを確認
git log upstream/develop..HEAD --onelineまとめ
重要なポイント
origin= 自分のフォーク、upstream= 本家 と覚える- PRは本家にマージされる ので、originだけ見ていても意味がない
- 定期的に
git fetch upstream && git merge upstream/developを実行する
やってはいけないこと
- ❌
git pull origin developだけで満足する - ❌ 何日も本家と同期せずに作業を続ける
- ❌ PR出す直前に初めて本家と同期する
やるべきこと
- ✅ 作業開始時に本家と同期
- ✅ 定期的に(毎日/毎週)本家と同期
- ✅ コンフリクトは早めに解消
さいごに
フォーク運用は便利ですが、origin と upstream の違いを理解していないと、思わぬところでコンフリクトに悩まされます。
「コンフリクトは避けられない」ではなく「早めに発見して早めに解消する」 という考え方にシフトすると、開発がずっとスムーズになります。
この記事が、フォーク運用で悩んでいる誰かの助けになれば幸いです。
関連記事
- Gitのマージとリベースの使い分け
- コンフリクト解消のベストプラクティス
- チーム開発でのブランチ戦略
