私はマージの衝突に遭遇しました。どうすればマージを中止できますか？

私は使用git pullしてマージの競合がありました：

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

私はファイルの他のバージョンが良いこと、そして私のものは悪いことを知っているので、私の変更はすべて放棄されるべきです。これどうやってするの？

あなたpullが失敗したので、HEAD（ではなくHEAD^）あなたのブランチの最後の「有効な」コミットです：

git reset --hard HEAD

もう1つ必要なのは、それらの変更が変更を上書きできるようにすることです。

古いバージョンのgitでは、「それら」のマージ戦略を使用できました。

git pull --strategy=theirs remote_branch

しかし、このメッセージで説明されているように、これは削除されました。リンクに記載されているように、代わりに次のようにします。

git fetch origin
git reset --hard origin

gitバージョンが1.6.1以上の場合は、を使用できますgit reset --merge。

また、@ Michael Johnsonが言及しているように、gitのバージョンが1.7.4以上の場合は、も使用できますgit merge --abort。

いつものように、マージを開始する前に、コミットされていない変更がないことを確認してください。

gitのマージmanページ

git merge --abort に相当 git reset --mergeMERGE_HEAD存在場合です。

MERGE_HEAD マージの進行中に存在します。

また、マージ開始時のコミットされていない変更について：

マージを開始する前にコミットしたくない変更がある場合は、マージのgit stash前とマージのgit stash pop終了後または中止した後の変更のみ。

git merge --abort

現在の競合解決プロセスを中止し、マージ前の状態を再構築してください。

マージの開始時にコミットされていないワークツリーの変更があった場合、 git merge --abortこれらの変更を再構築できない場合があります。したがって、git mergeを実行する前に、常に変更をコミットまたは隠しておくことをお勧めします。

git merge --abortが存在するgit reset --merge場合 と同等MERGE_HEADです。

http://www.git-scm.com/docs/git-merge

とてもシンプルです。

git merge --abort

このタイプの問題が発生してgit statusコマンドを実行すると、Git自体に解決策が表示されます。

git status

これが人々の役に立つことを願っています。

git reset必要だと思います。

つまりgit revert、たとえば、svn revertSubversionでは元に戻すと、（コミットされていない）変更が破棄され、ファイルがリポジトリから現在のバージョンに戻されます。git revert「アンドゥ」はコミット。

git reset 同等のことを行う必要があります svn revert必要があります。つまり、不要な変更を破棄します。

この特定の使用例では、実際にマージを中止するのではなく、特定の方法で競合を解決します。

リセットして別の戦略でマージを実行する必要も特にありません。競合はgitによって正しく強調表示されており、反対側の変更を受け入れる要件は、この1つのファイルに対してのみです。

競合するマージされていないファイルの場合、gitはインデックス内のファイルの共通のベースバージョン、ローカルバージョン、リモートバージョンを利用できるようにします。（これは、によって3方向差分ツールで使用するために読み込まれる場所ですgit mergetool。）を使用git showして表示できます。

# common base:
git show :1:_widget.html.erb

# 'ours'
git show :2:_widget.html.erb

# 'theirs'
git show :3:_widget.html.erb

リモートバージョンをそのまま使用して競合を解決する最も簡単な方法は、次のとおりです。

git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb

または、git> = 1.6.1の場合：

git checkout --theirs _widget.html.erb

のようなシナリオの場合、私はとgit fetchを実行git pullしましたが、上流のブランチがマスターブランチではないことに気づきました。これにより、不要な競合が発生しました。

git reset --merge 

これは、ローカルの変更をリセットせずに元に戻りました。

コメントは、git reset --mergeがのエイリアスであることを示唆していgit merge --abortます。a が存在git merge --abortする場合にのみ同等であることは注目に値します。これはgit help for mergeコマンドで読むことができます。git reset --mergeMERGE_HEAD

git merge --abortは、MERGE_HEADが存在する場合のgit reset --mergeと同等です。

マージが失敗した後、がないMERGE_HEAD場合、失敗したマージはで元に戻すことができますgit reset --mergeが、必ずしもで元に戻すことはできませんgit merge --abort。それらは同じものの古い構文と新しい構文だけではありません。

個人的にはgit reset --merge、説明したシナリオと同様のシナリオで非常に強力であり、マージは一般的に失敗しました。

マージの競合が発生し、コミットするものがない場合でも、マージエラーが表示されます。以下のすべてのコマンドを適用した後、

git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch origin
git reset --hard origin

削除してください

.git \ index.lock

ファイル[リカバリの場合は他の場所にカットアンドペースト]し、必要なバージョンに応じて以下のコマンドのいずれかを入力します。

git reset --hard HEAD
git reset --hard origin

お役に立てば幸いです!!!

作業コピーの状態を保存する別の方法は次のとおりです。

git stash
git merge --abort
git stash pop

次のコミットでブランチの関係を破棄するので、Subversionでマージするのと同じような効果があるので、一般的にはこれはお勧めしません。

Git 1.6.1.3以降git checkoutは、マージのどちらの側からでもチェックアウトできるようになりました。

git checkout --theirs _widget.html.erb

以下が機能することがわかりました（単一のファイルをマージ前の状態に戻します）。

git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*

ソースツリー

マージをコミットしないので、別のブランチをダブルクリックします（つまり、チェックアウトすることを意味します）。sourcetreeがすべての変更の破棄について尋ねてきたら、同意します:)