Разрешаване на конфликти при сливане: Принудително презаписване на всички файлове

Работя върху git хранилище сам (така че да, знам последиците и предупрежденията от това) и по някакъв начин едно от дърветата получи ангажимент, след като беше натиснато, когато не трябваше.

Сега се опитвам да се отдръпна и се оплаква от стотици конфликти при сливане.

Има ли начин да кажете на git принудително да презапише всички и всички локални файлове, които идват от отдалечения сървър? Има ли по-бърз начин от това да направите git reset --hard HEAD~1 и след това да изтеглите?

На същата бележка, има ли начин да направите същото с просто сливане? Всичко, което видях, предполага да се провери всеки един файл по време на етапа на разрешаване на конфликти при сливане, но със стотици файлове просто не е възможно да се направи това ръчно.


git git-pull git-merge
person Qix - MONICA WAS MISTREATED    schedule 10.01.2013    source източник
comment
защо просто не издухате вашата пясъчна кутия и git не я клонирате отново?   -  person gview    schedule 10.01.2013
comment
Надявах се на нещо, което не отнема много време. Проектът е голям и ще отнеме доста време за клониране.   -  person Qix - MONICA WAS MISTREATED    schedule 18.01.2013

Отговори (2)


arrow_upward
78
arrow_downward

Има три прости решения за копиране на последната версия, която е във вашето отдалечено хранилище, като отхвърлите всички промени, които сте направили локално:

  1. Изхвърлете вашето хранилище и клонирайте отново. Това е най-простото решение, но ако вашето хранилище е голямо, може да отнеме много време и може да изисква допълнителни усилия като reconfigureing и т.н.

  2. Отхвърлете локалните промени с git reset --hard <hash> и след това направете git pull. Проблемът е, че първо трябва да намерите ангажимент, който предшества хронологията на промените, която се опитвате да избегнете. След нулиране до този хеш на ангажиране, направете git pull.

  3. Направете git fetch, за да пренесете актуализациите във вашата локална референция на отдалечения клон (обикновено origin/master) и след това направете git reset --hard, предавайки тази референция, т.е. git reset --hard origin/master.

person William Seiti Mizuta    schedule 10.01.2013
comment
#3 беше доста умен. Добър отговор. Добре дошли в StackOverflow, между другото. Само забележка: използвайте обратни кавички (`), за да обозначите код или неща от командния ред. - person Qix - MONICA WAS MISTREATED; 10.01.2013
comment
git checkout --theirs . изглежда работи, ако сливането не включва изтривания - person Alex R; 23.12.2014
comment
Години по-късно реших, че #3 е окончателният правилен отговор. Да научите как работят fetch и refs е много важно за ефективното използване на Git. - person Qix - MONICA WAS MISTREATED; 24.11.2018
comment
След стартиране на git fetch origin my_branch и след това опитване на git reset --hard origin/my_branch получавам следната грешка: fatal: ambiguous argument 'origin/my_branch': unknown revision or path not in the working tree. Проблемът в бита working tree ли е? - person elPastor; 24.11.2018

arrow_upward
6
arrow_downward 

git reset --hard {remote_repository_name}/{branch_name}

Пример:

git reset --hard upstream/branch1

Ако работите с клон, можете да използвате горния код. Но преди това трябва да зададете (нагоре или произход) на вашето локално хранилище,

git remote add upstream https://github.com/lakini/example.git

тук https://github.com/lakini/example.git е отдалеченото хранилище нагоре по веригата.

По същия начин можем да работим и в отдалеченото хранилище (origin).

git reset --hard origin/branch1
person Sithara    schedule 04.10.2017