私は使用git pullし、マージの競合がありました：
unmerged: _widget.html.erb
You are in the middle of a conflicted merge.
ファイルの別のバージョンが適切で、私のファイルが不適切であることはわかっているので、すべての変更を破棄する必要があります。これどうやってするの？
質問する
2247468 次
15 に答える
2556
あなたpullが失敗したので、 HEAD(not HEAD^) はあなたのブランチでの最後の「有効な」コミットです:
git reset --hard HEAD
あなたが望むもう一つの部分は、彼らの変更があなたの変更を上書きできるようにすることです.
古いバージョンの git では、「theirs」マージ戦略を使用できました。
git pull --strategy=theirs remote_branch
しかし、 Junio Hamano (Git メンテナー)によるこのメッセージで説明されているように、これはその後削除されました。リンクに記載されているように、代わりに次のようにします。
git fetch origin
git reset --hard origin
于 2008-09-19T14:33:20.870 に答える
2235
git のバージョンが 1.6.1 以上の場合は、git reset --merge.
また、@Michael Johnson が言及しているように、git バージョンが 1.7.4 以上の場合は、git merge --abort.
いつものように、マージを開始する前に、コミットされていない変更がないことを確認してください。
git merge --abortgit reset --mergeが存在する場合と同等MERGE_HEADです。
MERGE_HEADマージが進行中の場合に存在します。
また、マージ開始時のコミットされていない変更について:
マージを開始する前にコミットしたくない変更がある場合は、マージgit stashの前と、マージをgit stash pop終了または中止した後にコミットします。
于 2010-03-28T23:16:48.167 に答える
612
git merge --abort
現在の競合解決プロセスを中止し、マージ前の状態の再構築を試みます。
マージの開始時にコミットされていない作業ツリーの変更が存在する場合、
git merge --abortこれらの変更を再構築できない場合があります。したがって、git merge を実行する前に、常に変更をコミットまたは隠しておくことをお勧めします。
git merge --abortgit reset --mergeが存在する場合 と同等MERGE_HEADです。
于 2012-11-12T21:40:24.550 に答える
113
私はそれgit resetが必要だと思います。
たとえば、 Subversion では、元に戻すと (コミットされていない) 変更が破棄され、ファイルがリポジトリから現在のバージョンに戻されますが、コミットは "元に戻されます"git revertとは非常に異なることを意味することに注意してください。svn revertgit revert
git resetつまり、不要svn revertな変更を破棄します。
于 2008-09-19T13:25:09.910 に答える
78
この特定のユースケースでは、マージを実際に中止するのではなく、特定の方法で競合を解決するだけです。
リセットして別の戦略でマージを実行する必要も特にありません。競合は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
于 2008-09-20T10:41:32.293 に答える
59
git reset --mergeコメントは、が のエイリアスであることを示唆していgit merge --abortます。aが存在git merge --abortする場合にのみ が同等であることに注意してください。これは、merge コマンドの git ヘルプで読むことができます。git reset --mergeMERGE_HEAD
MERGE_HEAD が存在する場合、git merge --abort は git reset --merge と同等です。
マージが失敗した後、 がないMERGE_HEAD場合、失敗したマージは で元に戻すことができますがgit reset --merge、必ずしも を使用するとは限りませんgit merge --abort。それらは、同じものに対する新旧の構文であるだけではありません。
個人的にはgit reset --merge、説明したシナリオに似たシナリオや、一般的にマージの失敗に対してはるかに強力だと思います。
于 2015-04-02T12:16:45.667 に答える
20
作業コピーの状態を保持する別の方法は次のとおりです。
git stash
git merge --abort
git stash pop
次のコミットでブランチの関係を破棄するため、Subversion でマージするのと実質的に似ているため、通常はこれに反対することをお勧めします。
于 2010-07-13T18:57:42.047 に答える
18
Git 1.6.1.3git checkoutでは、マージのどちらの側からでもチェックアウトできるようになっています。
git checkout --theirs _widget.html.erb
于 2010-07-17T01:29:33.400 に答える
2
私は次のことがうまくいったことを発見しました（単一のファイルをマージ前の状態に戻します）：
git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*
于 2017-10-31T00:56:24.403 に答える