Питання Скасувати об'єднання Git, яке ще не було висунуто


В межах моєї магістерської гілки я зробив це git merge some-other-branch локально, але ніколи не підштовхувала зміни до основного майстра. Я не мав на увазі злиття, тому я хотів би його скасувати. При виконанні a git status після мого злиття я отримав це повідомлення:

# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.

На підставі деяких інструкції я знайшов, Я спробував бігти

git revert HEAD -m 1

але тепер я отримую це повідомлення git status:

# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.

Я не хочу, щоб моя філія була попереду будь-якою кількістю зобов'язань. Як я можу повернутися до цього моменту?


3088
2018-03-05 19:24


походження


Якщо вам потрібно зберегти історію, інакше кажучи, це зміни, які хтось колись вирвав із вас, або ви натискали його де-небудь, використовуючи рішення Юрія Ушакова, дайте відповідь нижче! - Sedrik
Будь ласка, скасувати вибір поточної відповіді на виграш, це небезпечно (як зазначено багато), хоча і все ще збирають голоси. Для мене "MBO" -с виглядає найкращим, хоча у нього менше очок. - inger
Якщо вам потрібно зберегти історію, використовувати Юрійросійське рішення нижче! (просто додайте посилання на @Sedrik коментар) - cregox
Пов'язані: Повернутися до попередньої команди Git.
Це чудовий ресурс прямо з Github: Як відхилити (майже) що-небудь з Git - jasonleonhard


Відповіді:


З git reflog перевірте, яка фіксація є однією перед об'єднанням (git reflog буде кращим варіантом, ніж git log). Тоді ви можете скинути його за допомогою:

git reset --hard commit_sha

Існує ще інший спосіб

git reset --hard HEAD~1

поверне вас 1 commit.

Майте на увазі, що будь-які модифіковані та незв'язані / нерозміщені файли будуть скинуті до їх незмінених станів. Щоб утримувати їх, натисніть "Змінити" або "Переглянути" --merge опція нижче.


Оскільки @Velmont запропонував нижче у своєму відповіді, у цій прямої випадку використовуючи:

git reset --hard ORIG_HEAD

може принести кращі результати, оскільки він повинен зберігати ваші зміни. ORIG_HEAD буде вказувати на скоєння безпосередньо перед початком злиття, тому вам не треба полювати це самостійно.


Ще одним підказком є ​​використання --merge перемикач замість --hard оскільки він не скидає файли необов'язково:

- пограбувати

Відновлює індекс та оновлює файли у робочому дереві, що відрізняються між <commit> і HEAD, але зберігає ті, які відрізняються між індексом та робочим деревом (тобто мають зміни, які не були додані).


3380
2018-03-05 19:34



Я не думаю, що це буде (завжди?) Робота - "один до злиття" буде найновішою комбінацією, яка була об'єднана з іншої галузі - це не буде найновішою фіксацією у поточній галузі . Правильно? (Це може бути просто результатом того, що git log вибирає показ за замовчуванням - може бути, існує інший вихід git log або git reflog може бути використаний для цього) - John Bachir
Я думаю, що це може залежати від того, чи ви збиваєте сквош. - Marcin Gil
@ ДжонБахір правий. В git log Вихід, ви хочете поглянути на два основних зобов'язує. Один з них - це остання фіксація у вашій гілці, одна - остання фішка в галузі, в яку ви об'єднали. Ти хочеш git reset --hard до батьківської фіксації у філії, до якої ви об'єднали. - Justin
@ JohanBachir: поки "злиття" насправді не є швидким перемотуванням вперед, це призведе до нового вчинення, яке знаходиться у верхній частині журналу, і це зобов'язання має двох батьків (або більше 2, якщо ви робите восьминіг злиття) Якщо ви видалите цю комбінацію злиття, тоді всі старші, що вводяться в результаті злиття, також зникнуть. Однак, щоб бути в безпеці, після перезавантаження git скаже вам, де нова голова: "HEAD зараз на 88a04de <повідомлення про копію>". Я завжди дивлюся на це, щоб переконатися, що я опинився там, де я очікував бути. Мій проект використовує стандартну схему іменування філій, щоб зберегти речі незабутнім. - Mark E. Haase
Те, що мені виявилося корисним, було подивитися на "git reflog" і шукати останнє зобов'язання, яке я зробив у майстра. Тоді робіть git reset --hard <commit_sha> - Max Williams


Припускаючи, що ваш місцевий майстер не попереду походження / майстра, ви повинні мати можливість це зробити

git reset --hard origin/master

Тоді ваш місцевий master філія повинна виглядати ідентично origin/master.


1290
2018-03-17 18:06



@Carter це насправді не найкраща відповідь. Цілком можливо, що походження / майстер може попередити свого місцевого майстра просто перед злиттям деякими зобов'язаннями, в цьому випадку це може не дати бажаних результатів - Dhruva Sagar
@ дррува-сагар Так, але до тих пір, поки гіт не говорить, що ти за спиною, і ти не приїжджаєш, ти маєш в порядку. - Kelvin
Дякую! Це ідеально, якщо (і тільки якщо) у вас є віддалений сховище. - tomc
Ні, це не є ідеальним для цього питання, див. Пропозицію "Припустити". Відповідь MBO фактично охоплює цю справу, і той випадок, коли злиття не є єдиним місцевим зобов'язанням. - inger
Ще раз, можливо це УВАГА треба вдатися в саму відповідь: Завжди уникати переписування історії git! - cregox


Побачити глава 4 в книзі Гіта і оригінальний пост Лінуса Торвальдса.

Скасувати злиття це вже було підштовхнуто:

git revert -m 1 commit_hash

Не забудьте відновити зворотний зв'язок, якщо ви знову розпочнете філію, як сказав Лінус.


1085
2018-06-02 16:31



^ - Єдина правильна відповідь тут, як повернути злиття, не порушуючи історію. Це важливо, якщо ви працюєте з загальним репо. - Ruslan Kabalin
Це більше не було спростовано, оскільки зміна ніколи не була висунута, тому немає підстав додавати випадкове об'єднання до історії. Видаліть його локально і перемістіться. - Justin
Відновлення зупинки, яке не було натиснуто, виглядає потворним у історії та ускладнює його. Якщо ви ще не натиснули це, то має сенс рухати свою голову назад, кілька виконує, потім натискайте. - Mark E. Haase
"Це більше не було виправдане тому, що ...", тим не менше, тому що люди, як я, підходять до цього питання, тому що ми / є / підштовхнули додаткові зобов'язання, це безцінне. - perfectionist
@perfectionist погодився :) Сподобалось, що існував спосіб перенести цю відповідь на інше питання - (можливо, є?) - mikermcneil


Дивно, що найпростішого команди було відсутнє. Більшість відповідей працюють, але скасовує злиття, яке ви щойно зробили це легкий і безпечний спосіб:

git reset --merge ORIG_HEAD

Реф ORIG_HEAD вкаже на оригінальне зобов'язання перед об'єднанням.

(The --merge Варіант не має нічого спільного з об'єднанням. Це просто так git reset --hard ORIG_HEAD, але безпечніше, оскільки вона не торкається незв'язаних змін.)


832
2018-01-29 15:46



Так, це найпростіший спосіб. Я задаюсь питанням, чому він має так мало голосів у порівнянні з іншими відповідями. - Pablo Olmos de Aguilera C.
Якщо ви забруднили своє робоче дерево, оскільки git reset --merge ORIG_HEAD зберігає ці зміни. - yingted
Це для мене відповідь. Не потрібно git reflog або що-небудь ще. Дякую. - crmpicco
Так, найкраща відповідь. Це приклад того, як система голосування за поточним потоком, по суті, просто винагороджує відповіді, які розміщені рано. - samthebest
Що ж, ця відповідь прийшла майже через три роки після прийнятої; але я згоден, це чудово працювало! - Mike Branski


З версією Git новіші, якщо ви ще не здійснили злиття ще і у вас є конфлікт злиття, ви можете просто зробити:

git merge --abort

Від man git merge:

[Це] можна запускати тільки після того, як об'єднання призвело до конфліктів. git merge --abort скасує процес об'єднання та спробує реконструювати стан перед злиттям.


307
2018-02-12 02:13





Вам слід скинути попередню фіксацію. Це має працювати:

git reset --hard HEAD^

Або навіть HEAD^^ повернути цей зворотний фікс. Ви завжди можете надати повне посилання на SHA, якщо ви не впевнені, скільки кроків вам слід зробити.

У випадку, коли у вас виникли проблеми, і ваша гілка не змінила місцевість, ви можете скинути налаштування origin/master.


104
2018-03-05 19:31



Найкраща відповідь IMHO включає в себе власне ОР (припускаючи лише 1 крок для повернення, що, як видається, відбувається у Q), а також ярлик randomguy3 (який працює, коли "ваш головний розділ не мав ніяких локальних змін ") - inger
Я повністю згоден з тим, що це найкраща відповідь тут !!! - Konstantin
Ви коментарів, @ Інгер і @ Костянтин, чому? Ви прийшли сюди після того, як моя відповідь була створена, і це правильніше. Просто піднявши голову, один крок часто неправий, і ви повинні насправді розраховувати, як далеко вам потрібно йти. Гіт вже встановлює ORIG_HEAD для вас, чому б не використати його? - odinho - Velmont
чи зможе він скинути локальні зміни? #PleaseUpdate - CoDe
Це відмінно працювало для мене, скидання голови на зразок цього робить набагато більше сенсу, ніж половину відповідей тут. - Varda Elentári


Останнім часом я використовував git reflog допомогти з цим. Це працює, як правило, лише тоді, коли злиття відбулося просто, і це було на вашій машині.

git reflog може повернути щось на зразок:

fbb0c0f HEAD@{0}: commit (merge): Merge branch 'master' into my-branch
43b6032 HEAD@{1}: checkout: moving from master to my-branch
e3753a7 HEAD@{2}: rebase finished: returning to refs/heads/master
e3753a7 HEAD@{3}: pull --rebase: checkout e3753a71d92b032034dcb299d2df2edc09b5830e
b41ea52 HEAD@{4}: reset: moving to HEAD^
8400a0f HEAD@{5}: rebase: aborting

Перша рядок вказує на те, що відбулося злиття. Другий рядок - це час до мого злиття. Я просто git reset --hard 43b6032 щоб змусити цю галузь відслідковувати перед злиттям, а також продовжувати.


78
2017-12-19 17:51



Omigosh life saver :) - M.G.Palmer
О, чоловік. Дуже дякую. - Ross Henderson
Чому це не найкраща відповідь, яку я не знаю. Це чудово працювало. - Matt
Дякую за це, дивовижне! - zooblin


За допомогою сучасного Git ви можете:

git merge --abort

Старший синтаксис:

git reset --merge

Стара школа:

git reset --hard

Але насправді це варто помітити git merge --abort лише еквівалентно git reset --merge враховуючи це MERGE_HEAD присутній. Це можна прочитати в довідці Git для команди злиття.

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 набагато потужніше і корисніше в повсякденній роботі, так це те, що я завжди користуюся.


42
2018-05-08 19:13



Працював відмінно для мене. Кожен інший пост говорить, що це так складно, але це робилося саме те, що очікується. Я думаю, що це працювало лише тому, що існували конфлікти, що не відповідає початковому питанню. - Jeremy
Ця відповідь не зосереджується на ситуації ОР та залишає важливий контекст. - Ben Wheeler


Гаразд, відповіді інших людей, які дали мені, були близькі, але це не спрацювало. Ось що я зробив.

Робіть це ...

git reset --hard HEAD^
git status

... дав мені такий статус.

# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.

Тоді мені довелося вводити те саме git reset команда ще кілька разів. Щоразу, коли я це зробив, повідомлення змінено на один, як ви можете побачити нижче.

> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 1 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.

На цьому етапі я бачив повідомлення про статус змінено, тому я намагався зробити git pull, і це, здавалося, працює:

> git pull
Updating 2df6af4..12bbd2f
Fast forward
 app/views/truncated |    9 ++++++---
 app/views/truncated |   13 +++++++++++++
 app/views/truncated |    2 +-
 3 files changed, 20 insertions(+), 4 deletions(-)
> git status
# On branch master

Так довго, коротка історія, мої команди дійшли до цього:

git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git pull

32
2018-03-05 19:54



або ви могли б використати HEAD^^^^ - hasen
може навіть скинути до origin/master ;) - hasen
Оце Так! це працювало! - Yiğit Güler


Ви могли б використовувати git reflog знайти попередню розсилку. Іноді це хороший стан, який ви хочете повернутися до.

Конкретно,

$ git reflog
$ git reset --hard HEAD@{0}

21
2018-01-17 22:36



Дякую! Ви врятували половину дня своєї роботи. Однак я не міг вийти з режиму reflog з будь-якою командою. - Katarzyna
@ Катарзіна використовуйте клавішу "q", щоб вийти з reflog - Amjed Baig