Аз съм изправен пред конфликт на сливане. Как мога да прекъсна сливането?

Използвах git pull и имах конфликт:

 unmerged: _widget.html.erb You are in the middle of a conflicted merge. 

Знам, че другата версия на файла е добра и шахмата ми, така че всичките ми промени трябва да бъдат отменени. Как мога да направя това?

1947
19 сент. определени от Gwyn Morfey 19 септември 2008-09-19 16:21 '08 в 16:21 2008-09-19 16:21
@ 10 отговора

Тъй като pull ви е било неуспешно, тогава HEAD (не HEAD^ ) е последният „валиден“ ангажимент във вашата тема:

 git reset --hard HEAD 

Другата част, която искате, е да позволите промените да надхвърлят промените ви.

По-старите версии на git ви позволяват да използвате стратегията за сливане "тях":

 git pull --strategy=theirs remote_branch 

Но оттогава той е премахнат, както е описано в този пост от Junio ​​Hamano (придружаващ git). Както е посочено в връзката , ще направите следното:

 git fetch origin git reset --hard origin 
1752
19 сент. Отговор, даден от Пат Нот на 19 септември 2008-09-19 17:33 '08 в 17:33 2008-09-19 17:33

Ако вашата версия на git е> 1.6.1, можете да използвате git reset --merge .

Освен това, както споменава @Michael Johnson, ако вашата версия на git е> 1.7.4, можете също да използвате git merge --abort .

Както винаги, преди да започнете сливане, уверете се, че нямате непозволени промени.

На страницата за мъже в git сливане

border=0

git merge --abort еквивалентно на git reset --merge когато MERGE_HEAD присъства.

MERGE_HEAD присъства при сливане.

Също така, по отношение на неприети промени при започване на обединяване:

Ако имате промени, които не искате да направите, преди да започнете сливане, просто ги ги git stash преди сливането и git stash pop след сливането е завършено или отменено.

1610
29 марта '10 в 2:16 2010-03-29 02:16 отговорът е даден от Карл на 29 март '10 в 2:16 2010-03-29 02:16
 git merge --abort 

Прекъснете текущия процес на разрешаване на конфликти и се опитайте да възстановите състоянието преди сливането.

Ако имаше неработни промени в работната ситуация, които бяха налице при git merge --abort на сливането, git merge --abort в някои случаи няма да може да възстанови тези промени. Затова е препоръчително винаги да записвате или записвате промените, преди да стартирате git merge.

git merge --abort еквивалентно на git reset --merge когато MERGE_HEAD .

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

382
13 нояб. отговор даден ignis 13 ноември. 2012-11-13 00:40 '12 в 0:40 2012-11-13 00:40

В този конкретен случай на употреба наистина не искате да прекъснете сливането, просто разрешете конфликта по определен начин.

Няма специална нужда да се рестартират и сливат с друга стратегия. Конфликтите бяха правилно разпределени с git и изискването за приемане на промени от трети страни е само за този един файл.

За несвързан файл в конфликт, git осигурява достъпна обща база, локални и отдалечени версии на файла в индекса. (Тук те се четат за използване в тристранния инструмент diff с 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 
73
20 сент. Отговор, даден от CB Bailey 20 септември. 2008-09-20 13:41 '08 в 13:41 2008-09-20 13:41

Мисля, че трябва git reset .

Имайте предвид, че git revert означава нещо много различно от, да кажем, svn revert - в Subversion, връщането ще отхвърли вашите (необвързани) промени, връщайки файла на текущата версия от хранилището, докато git revert "отменя" коммита.

git reset трябва да направи еквивалента на svn revert , т.е. да изхвърли нежеланите промени.

72
19 сент. Отговор, даден от David Precious 19 септември 2008-09-19 16:25 '08 в 16:25 2008-09-19 16:25

Тъй като коментарите приемат, че git reset --merge е псевдоним за git merge --abort , заслужава да се отбележи, че git merge --abort еквивалентно на git reset --merge само ако има MERGE_HEAD . Това може да бъде намерено в git help за командата за обединяване.

 git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present. 

След неуспешно сливане, когато няма MERGE_HEAD , неуспешното сливане може да бъде отменено с git reset --merge , но не задължително с git merge --abort , така че те не са само стари и нови синтаксиси за едно и също нещо .

Лично аз намирам git reset --merge много по-мощен за сценарии като описания и неуспешните сливания като цяло.

29
02 апр. отговорът е даден на Мартин 02 април. 2015-04-02 15:16 '15 в 15:16 2015-04-02 15:16

Тъй като Git 1.6.1.3 git checkout състояние да провери от двете страни на сливането:

 git checkout --theirs _widget.html.erb 
16
17 июля '10 в 4:29 2010-07-17 04:29 на 17 юли 2007 г. в 4:29 беше даден отговор на Ален О'Диа

Алтернатива на запазването на състоянието на работно копие е:

 git stash git merge --abort git stash pop 

Обикновено не препоръчвам това, защото той е също толкова ефективен, колкото и сливането в Subversion, тъй като отхвърля връзката на разклонението в следващия ангажимент.

14
13 июля '10 в 21:57 2010-07-13 21:57 Отговорът е даден от Ален О'Диа на 13 юли 2007 г. в 21:57 ч. 2010-07-13 21:57

И ако прекратите конфликта за сливане и нямате никакви неща, за да се ангажирате, грешката при сливането се показва след прилагане на всички следващи команди,

 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 

Надявам се това да помогне!

9
11 апр. отговорът е даден от Nirav Mehta на 11 април 2018-04-11 00:26 '18 в 0:26 2018-04-11 00:26

Намерих това, което работи за мен (връщане на един файл в състоянието преди сливането):

 git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset* 
1
31 окт. Отговорът е даден от Малкълм Боекхоф на 31 октомври. 2017-10-31 03:56 '17 в 3:56 2017-10-31 03:56

Други въпроси относно етикетите или Ask a Question