ユーザーフィードバックを元に機能を直していた時期、自分のPCとノートPCの2台で作業を進めていたら、git pullした瞬間に見慣れない記号だらけの画面が表示されました。それが初めてのコンフリクト（競合）との遭遇でした。今回は、そのとき何が起きていたのかと、落ち着いて対処できるようになるまでの記録です。
1.
git pullを実行した直後、ファイルの中に見たことのない記号が大量に挿入されていました。
<<<<<<< HEAD
let buttonColor = Color.blue
=======
let buttonColor = Color.orange
>>>>>>> origin/main最初はこれが何を意味しているのか全く分からず、ファイルが壊れたのかと本気で焦りました。実際には、同じ箇所を自分（別PC側）とリモート側の両方で編集していたために、Gitがどちらを採用すべきか判断できず「両方をファイルに書き出して人間に決めてもらう」状態になっていただけでした。
2. の意味を理解していなかった
記号の意味を調べるまで、単に不要な文字が紛れ込んだと思い込んでいました。実際は明確な構造がありました。
<<<<<<< HEAD ← ここから自分側の変更
自分が書いたコード
======= ← 区切り線
origin/mainの変更
>>>>>>> origin/main ← ここまでが相手側の変更HEADが今いるブランチ（自分側）、=======より下がマージしようとした相手側の内容だと分かってからは、記号を見ても慌てなくなりました。どちらを残すか、あるいは両方を組み合わせるかを決めて、記号自体は手動で全部消してから保存する、という単純な作業だと理解できたのが大きかったです。
3. 保存しただけでコンフリクトが解消したと勘違いした
記号を消してファイルを正しい内容に直し、保存だけして安心していたら、git statusを見るとまだ「both modified」の表示のままでした。
git add ContentView.swift
git commitファイルの中身を直しただけでは不十分で、git addでGitに「この解決内容でいいです」と明示的に伝え、その上でcommitまで完了させて初めてコンフリクトが解消されるのだと知りました。エディタ上の見た目が綺麗になったことと、Git側の状態が解決済みになることは別のステップなのだと実感しました。
4. 焦ってgit merge --abortを打てず固まった
一度、直している途中で「これ全部なかったことにしたい」とパニックになったのですが、元に戻す方法が分からず、中途半端な状態のままファイルを開いたり閉じたりして時間を浪費してしまいました。
git merge --abortこのコマンド1つで、マージ開始前の状態に丸ごと戻せると知ってからは、気持ちに余裕を持ってコンフリクトに向き合えるようになりました。「うまく解決できなければやり直せる」という逃げ道を知っているだけで、焦って変な操作をしてしまう回数が減りました。
まとめ
<<<<<<<・=======・>>>>>>>は「自分側の変更」と「相手側の変更」を区切って表示しているだけで、壊れたわけではない- 記号を消して内容を直しただけでは未完了。
git addしてからcommitするまでがコンフリクト解決 - 迷ったら
git merge --abortでマージ前の状態に戻せる。まずこの逃げ道を知っておくと焦らず対処できる - 複数端末で作業する場合はコンフリクトが起きやすいので、こまめに
pull・pushする習慣も効果的
コンフリクトは「何か重大なミスをした」証拠ではなく、Gitが「判断を人間に委ねているだけ」の状態だと分かってからは、身構えずに向き合えるようになりました。
次は、App Store公開後にアップデートを出すまでの流れをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント