導入: なぜこの戦略が重要なのか
チーム開発で頻繁に発生する「マージコンフリクト」。一つずつ手動で修正するのは非常に時間がかかり、ミスも起きやすい作業です。しかし、ビルド生成物や環境設定ファイルのように、「どちらかのブランチを正として上書きしてしまえばよい」ケースも多々あります。Gitの「-Xours / -Xtheirs」戦略を使えば、コンフリクトを機械的に解消し、作業効率を劇的に向上させることが可能です。
基礎知識: oursとtheirsの違い
Gitのコマンドで出てくる「ours（私たちのもの）」と「theirs（彼らのもの）」は、マージの方向性によって役割が変わります。
・ours: 現在チェックアウトしているブランチ（マージ先）の変更を優先します。
・theirs: マージしようとしているブランチ（マージ元）の変更を優先します。
この戦略は、コンフリクトが発生したファイルに対してのみ自動的に適用されるため、コンフリクトしていないファイルは通常通りマージされます。
実装/解決策: 具体的なコマンド手順
コンフリクトが予想される状況で、以下のコマンドを利用します。
マージする場合:
git merge -Xours <ブランチ名>
（コンフリクト時に、現在のブランチの変更を優先します）
リベースする場合:
git rebase -Xtheirs <ブランチ名>
（コンフリクト時に、リベース元のブランチの変更を優先します）
サンプルプログラム: 実践的な利用シナリオ
例えば、開発チームで「設定ファイル（config.json）」を頻繁に変更しており、マージのたびにコンフリクトが発生して面倒な場合のフロー例です。
1. マージを開始し、コンフリクトが発生しそうなファイルは自分のブランチを正とする
git merge -Xours feature/new-login-flow
2. もし手動で特定のファイルだけを「相手の変更」で上書きしたい場合は、以下のコマンドも有効です
checkoutコマンドで指定ファイルを相手のバージョンに差し替える
git checkout –theirs path/to/config.json
3. 差し替えたファイルをステージングに追加
git add path/to/config.json
4. マージを完了させる
git commit -m “Merge branch ‘feature/new-login-flow’ with automatic conflict resolution”
応用・注意点: 現場で陥りやすい罠
非常に強力なコマンドですが、注意点が2つあります。
1. ロジックの破壊に注意: プログラムコードに対して機械的に適用すると、必要な変更まで消し去ってしまうリスクがあります。あくまで「設定ファイル」や「自動生成ファイル」など、内容が完全に置き換わっても問題ない対象に限定してください。
2. -Xours と –ours の違い: 似たコマンドに「git checkout –ours」がありますが、これはファイル単位で適用するものです。「-Xours」はマージ戦略として全体に適用されるため、混同しないようにしましょう。
機械的な解決は時間短縮の鍵ですが、最後は必ず「git diff」などで最終的な状態を確認する習慣をつけることが、安全なDevOps運用の第一歩です。
コメント