web-dev-qa-db-ja.com

Gitでマージ競合を解決する方法

Gitでマージ競合を解決する方法を説明する良い方法はありますか?

4303
Spoike

試してください:git mergetool

それはそれぞれの衝突を通してあなたを歩かせるGUIを開き、そしてあなたはマージする方法を選ぶようになります。後で少し手作業で編集する必要がある場合もありますが、通常はそれだけで十分です。それは確かに全てを手作業でやるよりずっといいです。

@JoshGloverのコメントによると:

GUIをインストールしない限り、コマンドによって必ずしもGUIが開くわけではありません。私のためにgit mergetoolを実行すると、vimdiffが使用されました。 meldopendiffkdiff3tkdiffxxdifftortoisemergegvimdiffdiffuseecmergep4mergearaxisvimdiffemerge:あなたの代わりにそれを使用するには、次のいずれかのツールをインストールすることができます。

以下はマージの競合を解決するためにvimdiffを使用するサンプル手順です。に基づいて このリンク

ステップ1 :端末で以下のコマンドを実行してください。

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.Prompt false

これはデフォルトのマージツールとしてvimdiffを設定します。

ステップ2 :端末で以下のコマンドを実行する

git mergetool

ステップ3 :次の形式でvimdiffが表示されます。 

  +----------------------+
  |       |      |       |
  |LOCAL  |BASE  |REMOTE |
  |       |      |       |
  +----------------------+
  |      MERGED          |
  |                      |
  +----------------------+

この4つの見解は 

LOCAL - これは現在のブランチからのファイルです 

BASE - 共通の先祖、ファイルが両方の変更の前にどのように見えたか 

REMOTE - ブランチにマージしようとしているファイル 

MERGED - マージ結果、これがリポジトリに保存されます。

ctrl+wを使用してこれらのビュー間を移動できます。 ctrl+wに続けてjを使用すると、MERGEDビューに直接アクセスできます。

Vimdiffナビゲーションに関するより多くの情報 ここ そして ここ

ステップ4 。以下の方法でMERGEDビューを編集できます。 

REMOTEから変更を加えたい場合

:diffg RE  

BASEから変更を加えたい場合

:diffg BA  

LOCALから変更を加えたい場合

:diffg LO 

ステップ5 。保存、終了、コミット、クリーンアップ

:wqa保存してviから終了

git commit -m "message"

git clean diffツールによって作成された余分なファイル(例:* .orig)を削除します。

2569
Peter Burns

上から順に、ユースケースです。

あなたはいくつかの変更を実行するつもりですが、おっと、あなたは最新ではありません:

git fetch Origin
git pull Origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

それであなたは最新の状態になってやり直してみるが、矛盾がある:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull Origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

それで、あなたは変化を見ることに決めます:

git mergetool

ああ、ああ、私の、上流はいくつかのことを変更したが、ただ私の変更を使用するために...いいえ...それらの変更.

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

そして最後にやってみる

git pull Origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

ただ!

1631
CoolAJ86

マージツールが競合や解決方法を理解するのに役立つことはめったにありません。私は通常、テキストエディタで競合マーカーを調べ、補足としてgit logを使うほうがうまくいっています。

ここにいくつかのヒントがあります:

ヒント1

私が見つけた最高のものは "diff3"マージ衝突スタイルを使うことです:

git config merge.conflictstyle diff3

これにより、次のような競合マーカーが生成されます。

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

真ん中のセクションは、共通の祖先がどのように見えたかです。各ブランチで何が変更されたのかをより正確に把握するためにトップバージョンとボトムバージョンを比較できるため、これは便利です。これにより、各変更の目的が何であるかをより的確に把握できます。

競合がほんの数行である場合、これは一般に競合を非常に明白にします。 (競合を解決する方法を知ることは非常に異なります。他の人が取り組んでいることを知っておく必要があります。混乱している場合は、相手に自分の部屋に電話をかけるだけでよいでしょう。で。)

競合がもっと長ければ、3つのセクションをそれぞれ「mine」、「common」、「theirs」などの3つの別々のファイルにカットアンドペーストします。

その後、以下のコマンドを実行して、競合を引き起こした2つのdiffハンクを確認できます。

diff common mine
diff common theirs

これはマージツールを使用するのと同じではありません。マージツールには競合しない差分ハンクもすべて含まれるためです。気を散らすものだと私は思います。

ヒント2

誰かがすでにこれについて言及していますが、各diff hunkの背後にある意図を理解することは、衝突がどこから来たのか、そしてそれをどのように処理するのかを理解するのに非常に役立ちます。

git log --merge -p <name of file>

これは、共通の先祖とマージしている2つのヘッドの間でそのファイルに触れたすべてのコミットを示しています。 (したがって、マージ前に両方のブランチにすでに存在しているコミットは含まれません。)これは、明らかに現在のコンフリクトの要因ではないdiff hunkを無視するのに役立ちます。

ヒント3

自動化ツールを使って変更を確認します。

自動テストがある場合は、それらを実行してください。 lint がある場合は、それを実行してください。ビルド可能なプロジェクトの場合は、コミットする前などにビルドします。どのような場合でも、変更が壊れていないことを確認するために少しテストを行う必要があります。 (矛盾のないマージでも、正常に機能するコードが壊れる可能性があります。)

ヒント4

事前に計画します。同僚とコミュニケーションをとる。

詳細を念頭に置いておく一方で、前もって計画を立て、他の人が何に取り組んでいるのかを知っておくことは、マージの競合を防ぐのに役立ちます。 

たとえば、あなたと他の人が同じリファクタリングに取り組んでいることがわかっているなら、前もってお互いに話し合い、それぞれの変更がどのような種類であるのかをよく理解しておくべきです。作ります。計画した変更を並列ではなく連続して実行すれば、かなりの時間と労力を節約できます。 

大量のコードにまたがる大きなリファクタリングの場合は、逐次的に作業することを強くお勧めします。1人が完全なリファクタリングを実行している間は、誰もがコードのその領域の作業を中止します。

時間的なプレッシャーが原因で連続して作業できない場合は、少なくとも予想されるマージの競合について通知することで、詳細がまだ明確になっている間に問題をより早く解決できます。たとえば、同僚が1週間にわたって破壊的な一連のコミットを行っている場合、その週に毎日1回または2回その同僚ブランチにマージ/リベースすることを選択できます。このようにして、マージ/リベースの競合が見つかった場合は、数週間待ってすべてをひとまとめにするよりも迅速に解決できます。

ヒント5

マージがわからない場合は、無理に押し込まないでください。

特に競合するファイルが多数あり、競合マーカーが何百行にも及ぶ場合は、マージが非常に困難になることがあります。ソフトウェアプロジェクトを見積もる際には、通常のマージ処理のようなオーバーヘッド項目のための十分な時間がないため、各競合を分析するのに数時間を費やすのは大変なことです。

長期的には、事前に計画を立て、他のユーザーが何に取り組んでいるのかを認識することが、マージの競合を予測し、短期間で正しく解決できるように準備するための最善の方法です。

700
Mark E. Haase
  1. どのファイルが衝突しているかを特定します(Gitがこれを教えてくれるはずです)。

  2. 各ファイルを開き、差分を調べます。 Gitはそれらを区別します。うまくいけば、それは各ブロックのどのバージョンを保持するべきか明らかであろう。コードをコミットした他の開発者と話し合う必要があるかもしれません。

  3. ファイルgit add the_fileで競合を解決したら.

  4. all の競合を解決したら、git rebase --continueまたは任意のコマンドを実行します Gitは、完了時に実行するように指示しました。

328
davetron5000

Stack Overflow questionGitでマージを中断する、特に Charles Bailey's answer の答えを調べてください。これは、問題のあるファイルの異なるバージョンを表示する方法を示しています 

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp
101
Pat Notz

同時にファイルに変更が加えられると、マージの競合が発生します。これを解決する方法は次のとおりです。

git CLI

競合状態になったときにすべき簡単な手順は次のとおりです。

  1. git statusUnmerged pathsセクションの下)で競合ファイルのリストに注意してください。
  2. 次のいずれかの方法で、ファイルごとに別々に競合を解決します。

    • GUIを使用して競合を解決します。git mergetool(最も簡単な方法)。

    • リモートまたは他のバージョンを受け入れるには、git checkout --theirs path/fileを使用します。これにより、そのファイルに対して行ったローカルの変更はすべて拒否されます。

    • ローカル/私たちのバージョンを受け入れるには、次のようにしてください。git checkout --ours path/file

      ただし、何らかの理由で競合が発生したことがリモートで変更されるため、注意が必要です。

      Related: gitにおける "ours"と "theirs"の正確な意味は何ですか?

    • 競合しているファイルを手動で編集して<<<<</>>>>>の間のコードブロックを探し、次に=====の上または下からバージョンを選択します。参照してください: 競合がどのように提示されるか

    • パスとファイル名の衝突はgit add/git rmで解決できます。

  3. 最後に、git statusを使用してコミットの準備ができているファイルを確認します。

    Unmerged pathsの下にまだファイルがあり、手動で競合を解決した場合は、Gitにそれを解決したことをgit add path/fileで知らせてください。

  4. すべての競合が正常に解決された場合は、git commit -aを使用して変更をコミットし、通常どおりリモートにプッシュします。

以下も参照してください。 コマンドラインからのマージ競合の解決 at GitHub

DiffMerge

私は DiffMerge をうまく使っていて、これはWindows、macOSそしてLinux/Unix上のファイルを視覚的に比較してマージすることができます。

それはグラフィカルに3つのファイル間の変更を示すことができ、自動マージ(安全な場合)と結果ファイルの編集に対する完全な制御を可能にします。

DiffMerge

画像ソース: DiffMerge (Linuxスクリーンショット)

単にそれをダウンロードしてレポとして実行する:

git mergetool -t diffmerge .

マックOS

MacOSでは、以下からインストールできます。

brew install caskroom/cask/brew-cask
brew cask install diffmerge

そしておそらく(もし提供されていなければ)あなたはあなたのPATHに置かれた次の特別な単純なラッパーが必要です(例:/usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "[email protected]"

その後、次のキーボードショートカットを使用できます。

  • - Alt - Up/Down 前/次の変更にジャンプします。
  • - Alt - Left/Right 左または右からの変更を受け入れる

あるいは、 opendiff (Xcode Toolsの一部)を使用すると、2つのファイルまたはディレクトリをマージして3番目のファイルまたはディレクトリを作成できます。

90
kenorb

頻繁に小さなコミットをするのであれば、まずgit log --mergeでコミットのコメントを見てください。それからgit diffはあなたに衝突を見せます。

数行以上の衝突がある場合は、外部のGUIツールで何が起こっているのかを確認する方が簡単です。私はopendiffが好きです - Gitはvimdiff、gvimdiff、kdiff3、tkdiff、meld、xxdiffをサポートしています。他の人もインストールできます:git config merge.tool "your.tool"は選択したツールを設定し、失敗したgit mergetoolは差分を表示しますコンテキスト。

競合を解決するためにファイルを編集するたびに、git add filenameはインデックスを更新し、あなたの差分はそれを表示しなくなります。すべての競合が処理され、それらのファイルがgit addされている場合、git commitはマージを完了します。

76
Paul

競合がどのように表されるか またはGitでは、マージ競合マーカーが何であるかを理解するためのgit mergeドキュメントを参照してください。

また、 競合の解決方法 のセクションでは、競合の解決方法について説明しています。

衝突が発生したら、次の2つのことができます。

  • マージしないことを決定します。必要な唯一のクリーンアップは、インデックスファイルをHEADコミットにリセットして2.を元に戻し、2.と3によって行われた作業ツリーの変更をクリーンアップすることです。これにはgit merge --abortを使用できます。

  • 衝突を解決してください。 Gitはワーキングツリーの衝突をマークします。ファイルをshapeに編集し、それらをインデックスにgit addします。契約を結ぶためにgit commitを使用してください。

あなたは多くのツールとの衝突を乗り越えることができます。

  • マージツールを使用してください。グラフィカルなmergetoolを起動するためのgit mergetoolです。

  • 差分を見てください。 git diffは三方差分を表示し、HEADMERGE_HEADの両方のバージョンからの変更点を強調表示します。

  • 各ブランチの差分を見てください。 git log --merge -p <path>は、最初にHEADバージョン、次にMERGE_HEADバージョンの差分を表示します。

  • オリジナルを見てください。 git show :1:filenameは共通の先祖を、git show :2:filenameHEADのバージョンを、そしてgit show :3:filenameMERGE_HEADのバージョンを表します。

Pro Git bookセクション Basic Merge Conflicts で、マージ競合マーカーとその解決方法についても読むことができます。

44
user456814

Emacs マージ競合を半手動で解決したい場合:

git diff --name-status --diff-filter=U

競合解決が必要なすべてのファイルを表示します。

これらの各ファイルを一つずつ開くか、次のようにして一度に全部開く。

emacs $(git diff --name-only --diff-filter=U)

Emacsで編集が必要なバッファを訪問するときは、

ALT+x vc-resolve-conflicts

これは3つのバッファを開きます(mine、theirs、およびoutputバッファ)。 'n'(次の地域)、 'p'(予告地域)を押して移動します。 'a'と 'b'を押して、それぞれ自分の領域または自分の領域を出力バッファにコピーします。出力バッファを直接編集します。

終了したら: 'q'を押してください。 Emacsはこのバッファを保存するか尋ねます:はい、バッファを終了した後、境界から実行して解決したことをマークします。

git add FILENAME

全バッファタイプで終了したら

git commit

マージを終了します。

37
eci

私は自分のバージョンまたは自分のバージョンを完全に表示したいか、個々の変更を検討してそれぞれを決定したいのです。

自分のバージョンを完全に受け入れます

私のバージョンを受け入れます(ローカル、私達のもの):

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

自分のバージョンを受け入れます(remote、theirs)。

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

すべての衝突ファイルに対して を実行したい場合は、/ run:

git merge --strategy-option ours

または

git merge --strategy-option theirs

すべての変更を確認して個別に受け入れます

  1. git mergetool
  2. 変更を確認し、それぞれに対してどちらかのバージョンを受け入れます。
  3. git add <filename>
  4. git commit -m "merged bla bla"

デフォルトのmergetool コマンドライン で動作します。コマンドラインmergetoolの使い方は別の質問です。

ビジュアルツール をインストールすることもできます。 meld and run

git mergetool -t meld

それはローカルバージョン(私たちのもの)、「ベース」または「マージされた」バージョン(マージの現在の結果)そしてリモートバージョン(彼らのもの)を開くでしょう。終了したらマージしたバージョンを保存し、 "No files need merging"が表示されるまでgit mergetool -t meldを実行してから、手順3と4に進みます。

31
Noidea

Gitのマージの競合を修正するには、次の手順に従ってください。

  1. Gitステータスを確認します:git status

  2. パッチセットを取得します:git fetch(Gitコミットから正しいパッチをチェックアウトします)

  3. ローカルブランチをチェックアウトします(ここの例ではtemp1):git checkout -b temp1

  4. マスターから最近のコンテンツをプルします:git pull --rebase Origin master

  5. Mergetoolを起動し、競合を確認して修正します...そして、現在のブランチとのリモートブランチの変更を確認します。git mergetool

  6. ステータスをもう一度確認します:git status

  7. Mergetoolでローカルに作成された不要なファイルを削除します。通常、mergetoolは* .orig拡張子を持つ余分なファイルを作成します。そのファイルは重複しているため削除し、ローカルで変更を修正して、正しいバージョンのファイルを追加してください。 git add #your_changed_correct_files

  8. ステータスをもう一度確認します:git status

  9. 変更を同じコミットIDにコミットします(これにより、新しい個別のパッチセットが回避されます):git commit --amend

  10. マスターブランチにプッシュします:git Push(Gitリポジトリへ)

28
Chhabilal

簡単に言えば、一方のリポジトリの変更が重要ではないことをよく知っていて、もう一方のリポジトリを優先してすべての変更を解決したい場合は、次のようにします。

git checkout . --ours

あなたのリポジトリ の方に変更を解決するため

git checkout . --theirs

その他またはメインのリポジトリ を支持する変更を解決するため。

それ以外の場合は、GUIマージツールを使用してファイルを1つずつステップスルーする必要があります。マージツールはp4mergeであると言うか、既にインストールした名前を入力します

git mergetool -t p4merge

ファイルが完成したら、保存して閉じる必要があるので、次のファイルが開きます。

27
Mohamed Selim

ボーナス:

上記の回答のプル/フェッチ/マージについて言えば、興味深い生産的なトリックを共有したいのですが、

git pull --rebase

この上記のコマンドは、私のgitライフで最も便利なコマンドであり、多くの時間を節約しました。

新しくコミットされた変更をリモートサーバーにプッシュする前に、git pull --rebaseではなくgit pullと手動mergeを試してください。最新のリモートサーバーの変更が自動的に同期され(フェッチ+マージ)、ローカル最新コミットがgitログの先頭に配置されます。手動でのプル/マージについて心配する必要はありません。

競合する場合は、

git mergetool
git add conflict_file
git rebase --continue

詳細については、 http://gitolite.com/git-pull--rebase をご覧ください。

27

他の人が詳しく述べているように、あなたはいくつかの方法でマージ競合を修正することができます。

本当の鍵は、ローカルとリモートのリポジトリで変更がどのように流れるかを知ることだと思います。その鍵は、枝の追跡を理解することです。トラッキングブランチは、私のローカルの実際のファイルディレクトリとOriginとして定義されているリモートの間の「欠けている部分」と考えることがわかりました。 

私は個人的にこれを避けるのを助けるために2つのことの習慣を身に付けました。

の代わりに:

git add .
git commit -m"some msg"

これには2つの欠点があります -

a)すべての新しい/変更されたファイルは追加されます、そしてそれはいくつかの望まれない変更を含むかもしれません。
b)ファイルリストを最初に確認することはできません。

だから代わりに私は行います:

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

これにより、どのファイルが追加されるのかをより慎重に検討したり、リストを確認したり、メッセージをエディタを使用しながらもう少し考えたりすることができます。 -mオプションではなくフルスクリーンエディタを使用すると、コミットメッセージも改善されます。

[更新 - 時間が経つにつれて私はより多くに切り替えました:

git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

また(そしてあなたの状況により関連して)、私は避けようとします:

git pull

または

git pull Origin master.

pullはマージを意味し、マージしたくない変更をローカルで行っている場合は、マージされたコードやマージされてはいけないコードに対するマージの競合が発生しやすくなります。

代わりに私がやろうとしている

git checkout master
git fetch   
git rebase --hard Origin/master # or whatever branch I want.

これも参考になるでしょう。

ブランチ、フォーク、フェッチ、マージ、リベース、クローンのgit、違いは何ですか?

25
Michael Durrant

CoolAJ86の答えはほとんどすべてをまとめたものです。同じコードで両方のブランチを変更した場合は、手動でマージする必要があります。任意のテキストエディタで競合しているファイルを開くと、次のような構造になるはずです。

(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

等号と山括弧を削除しながら、新しいコードになるように、選択肢の1つまたは両方の組み合わせを選択します。 

git commit -a -m "commit message"
git Push Origin master
22
iankit

3つのステップがあります。

  1. コマンドによってどのファイルが競合を引き起こすかを見つける

    git status
    
  2. ファイルを確認します。このファイルで、競合が次のようにマークされています。

    <<<<<<<<head
    blablabla
    
  3. 望みの方法に変更してから、コマンドでコミットする

    git add solved_conflicts_files
    git commit -m 'merge msg'
    
20
Qijun Liu
git log --merge -p [[--] path]

いつもうまくいくとは限らず、通常2つのブランチ間で異なるコミットを表示することになります。これは、--を使用してコマンドからパスを分離する場合でも発生します。

この問題を回避するために私がすることは2つのコマンドラインを1回の実行で開くことです

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

そして他の

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

$MERGED_IN_BRANCHを私がマージしたブランチに、[path]を競合しているファイルに置き換えます。このコマンドは、(..)2回のコミットの間に、すべてのコミットをパッチの形で記録します。上記のコマンドのように片側を空のままにしておくと、gitは自動的にHEAD(この場合はマージしているブランチ)を使います。

これにより、分岐した後に2つのブランチでコミットがファイルに入ったことを確認できます。それは通常衝突を解決することをはるかに容易にします。

15
Brian Di Palma

patienceを使う

マージ再帰戦略でpatienceを使って競合を解決することについて誰も話さなかったことに驚きました。大きなマージの衝突のために、patienceを使うことは私に良い結果を提供しました。その考えは、個々の行ではなくブロックを一致させようとするということです。

たとえば、プログラムのインデントを変更した場合、デフォルトのGitマージ方法は、異なる関数に属する単一の中括弧{に一致することがあります。これはpatienceで避けられます。

git merge -s recursive -X patience other-branch

ドキュメントから:

With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

一般的な先祖との比較

マージの競合があり、ブランチを変更するときに他の人が念頭に置いていたことを確認したい場合は、(ブランチではなく)直接共通の祖先とブランチを比較する方が簡単な場合があります。そのためにはmerge-baseを使うことができます。

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

通常は、特定のファイルに対する変更だけを確認します。

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
15
Conchylicultor

2016年12月12日現在、ブランチをマージして github.comで競合を解決することができます

したがって、コマンドラインやここでは古い回答から提供されているサードパーティ製のツールを使用したくない場合は、GitHubのネイティブツールを使用してください。

このブログ記事 は詳細に説明していますが、基本的にはUIを介して2つのブランチを 'マージ'する際に、 'merge conflict'オプションが表示されます。衝突します。

enter image description here

15
maxwell

私はいつも衝突を避けるために以下のステップに従います。

  • git checkout master(マスターブランチへ)
  • git pull(マスターをアップデートして最新のコードを入手する)
  • git checkout -b mybranch(新しいブランチをチェックアウトし、そのブランチで作業を開始して、マスターが常にトランクのトップになるようにします。)
  • git add。 AND git commit AND git Push(変更後、あなたのローカルブランチで)
  • git checkout master(マスターに戻ってきてください。)

今、あなたは同じことをすることができて、あなたが望む限り多くの地元のブランチを維持して同時に働くことができます。

12
Chetan

マージ競合はさまざまな状況で発生する可能性があります。

  • 「git fetch」を実行してから「git merge」を実行した場合
  • "git fetch"を実行してから "git rebase"を実行すると
  • "git pull"を実行するとき(実際には上記の条件の1つと等しい)
  • 「git stash pop」を実行しているとき
  • Gitパッチを適用しているとき(例えば、Eメールで転送されるファイルにエクスポートされたコミット)

競合を解決するにはGitと互換性のあるマージツールをインストールする必要があります。私は個人的にKDiff3を使用しています、そして私はそれが素晴らしくて便利であると思った。 Windows版はこちらからダウンロードできます。

https://sourceforge.net/projects/kdiff3/files/ /

ところでGit Extensionsをインストールする場合、そのセットアップウィザードにKdiff3をインストールするオプションがあります。

それからgit configsをマージツールとしてKdiffを使うように設定します。

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(パスをKdiff exeファイルの実際のパスに置き換えてください。)

その後、マージの競合に遭遇するたびに、このコマンドを実行するだけです。

$git mergetool

その後、Kdiff3を開き、最初にマージの競合を自動的に解決しようとします。ほとんどの競合は自然に解決されるため、残りの部分は手動で修正する必要があります。

これがKdiff3の外観です。

Enter image description here

それが終わったら、ファイルを保存してください、そしてそれは衝突で次のファイルに行きます、そしてあなたはすべての衝突が解決されるまであなたは再び同じことをします。

すべてが正常にマージされたかどうかを確認するには、もう一度mergetoolコマンドを実行するだけで、次の結果が得られます。

$git mergetool
No files need merging
11
akazemis

ブランチ(テスト)からマスターにマージしたい場合は、次のステップに従ってください。

ステップ1:支店に行く

git checkout test

ステップ2:git pull --rebase Origin master

ステップ3:競合がある場合は、これらのファイルを参照して修正します。

ステップ4:これらの変更を追加する

git add #your_changes_files

ステップ5:git rebase --continue

手順6:それでも矛盾がある場合は、手順3に戻ります。競合がない場合は、次のようにします。git Push Origin +test

ステップ7:そして、テストとマスターの間に競合はありません。あなたは直接mergeを使うことができます。

11
Haimei

これは私のようなVIMユーザーに代わるものを追加することです。


TL、DR

enter image description here


Tpopeは 逃亡者 と呼ばれるVIMのためのこの素晴らしいプラグインを思い付きました。インストールが完了したら、:Gstatusを実行して競合のあるファイルをチェックし、:Gdiffを実行してGitを3通りの方法で開くことができます。 

3-way mergeに入ると、 fugitive を使用すると、マージしているブランチのいずれかの変更を次のように取得できます。

  • :diffget //2、元の( _ head _ )ブランチからの変更を取得: 
  • :diffget //3、マージブランチから変更を取得: 

ファイルのマージが終了したら、マージしたバッファに:Gwriteと入力します。 Vimcastsはこのステップを詳しく説明したすばらしい ビデオ をリリースしました。

gitフェッチ 
git checkout あなたのブランチ
git rebase master

このステップでは、好みのIDEを使用して競合を解決しようとします

あなたはファイル内の競合を修正するためにhoをチェックするためにこのリンクをたどることができます
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ /

git add
git rebase - 続行する
git commit --amend
git Push Origin HEAD:参照/ドラフト/マスター(ドラフトのようにプッシュ)

今、すべてが大丈夫です、あなたはgerritであなたのコミットを見つけるでしょう

これがこの問題に関するすべての人に役立つことを願っています。 

4
Baini.Marouane

まだ編集していない場合は、編集用にVisual Studioのコードを試してください。

元のものに加えられた変更は何かを示すことで非常に役立ちます。incomingを受け入れてください。 

current change(マージ前のオリジナルの意味) '?.

それは私を助け、それはあなたのためにも働くことができます! 

シモンズ:それはあなたがあなたのコードとVisual Studioのコードでgitを設定した場合にのみ機能するでしょう。 

2
Kailash Bhalaki

私は以下の手順に従います。

マージの競合を修正するためのプロセス

  1. まず、マージしたい先のブランチから最新のものを取得しますgit pull Origin develop

  2. 目的地から最新のものを入手したら、IDEでそれらの余分な文字を削除して手動で競合を解決します。

  3. git addを実行してこれらの編集済みファイルをgitキューに追加し、作業中のブランチと同じブランチにcommitおよびPushになるようにします。

  4. git addが完了したら、git commitを実行して変更をコミットします。

  5. それでは、git Push Origin HEADを使って作業ブランチへの変更をプッシュしましょう。

これはそれであり、あなたがBitbucketまたはGitHubを使用しているなら、あなたはそれがあなたのpull requestで解決されるのを見るでしょう。

1
Aniruddha Das

IDEとしてintelliJを使用している場合親をブランチにマージするようにしてください。

git checkout <localbranch>
git merge Origin/<remotebranch>

それはこのようなすべての衝突を示します

A_MBPro:test anu $ git merge Origin /自動マージ src/test/Java/com /.../ TestClass.Java CONFLICT (内容):内のマージの競合src/test/Java/com /.../ TestClass.Java

TestClass.JavaファイルはintelliJ で赤く表示されています。またgit statusも表示されます。 

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/Java/com/.../TestClass.Java

IntelliJでファイルを開くと、セクションがあります。 

  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> Origin/<remotebranch>

ここでHEADはローカルブランチでの変更、Origin /はリモートブランチからの変更です。ここでは必要なものを保管し、不要なものは削除してください。その後、通常の手順で実行します。あれは

   git add TestClass.Java
   git commit -m "commit message"
   git Push
1
AJC

Gitlense For VS Code

あなたは Gitlense VS Codeを試すことができます、彼らの主な機能は以下のとおりです。

3.競合を簡単に解決します。

私はすでにこの機能が好きです:

enter image description here

現在の行の責任。

enter image description here

3.ガター責任

enter image description here

4.ステータスバーのせい

enter image description here

そして、あなたがそれらをチェックできる多くの機能があります ここ

1
Ilyas karim

Visual Studioを使用している人のために(私の場合は2015年)

  1. VSでプロジェクトを閉じます。特に大規模プロジェクトでは、UIを使用してマージするとVSがおかしくなる傾向があります。

  2. マージインコマンドプロンプトを実行します。 

    git checkout target_branch

    git merge source_branch

  3. 次にVSでプロジェクトを開き、チームエクスプローラ - >ブランチに移動します。今すぐMergeが保留中で、競合するファイルがメッセージのすぐ下に表示されているというメッセージが表示されます。

  4. 競合するファイルをクリックすると、マージ、比較、ソースの取得、ターゲットの取得のオプションがあります。 VSのマージツールはとても使いやすいです。

1
Mike
  1. ターゲットブランチから新しい機能ブランチを作成する
  2. 競合する機能ブランチからの変更点にパッチを当てる
  3. パッチを適用しながら差分ツールの競合を解決
  4. クリーンプル要求のコミット/確認
  5. 競合しているブランチを削除します。 

これは、Gitを使用するよりもずっと速くて簡単です。変更がpullリクエストをめちゃくちゃにして、あなたのIDEがGitマージをうまく処理できない場合、それは特に有益です。

0
git checkout branch1

git fetch Origin

git rebase -p Origin/mainbranch

マージの競合がある場合は修正してください。その後、次のコマンドを実行して、リベースプロセスを続行します。git rebase –-continue

修正後は、ローカルブランチをリモートブランチにコミットしてプッシュできます。

git Push Origin branch1
0

衝突を解決するためのより安全な方法は git-mediate を使用することです(ここで提案されている一般的な解決策はかなり誤りがちなimhoです)。

使い方の簡単な紹介は この記事 をご覧ください。

0
yairchu

私はBeyond Compareをインストールしました、それでgit mergetoolを使うとき、それはどんなマージでも実行するためのとても素晴らしいGUI方法を持っているBCを起動します。

0
JasonDiplomat