Anularea unei fuziuni Git care nu a fost încă împinsă (Programare, Git, Undo, Git Merge)

Matt Huggins a intrebat.

În cadrul ramurii mele principale, am făcut un git merge some-other-branch la nivel local, dar nu am împins niciodată modificările în origin master. Nu am vrut să fuzionez, așa că aș dori să anulez. Atunci când se face un git status după fuziune, am primit acest mesaj:

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

Based upon some instrucțiuni pe care le-am găsit, am încercat să execut

git revert HEAD -m 1

dar acum primesc acest mesaj cu git status:

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

Nu vreau ca ramura mea să fie în avans cu orice număr de comenzi. Cum mă întorc la acel punct?

Comentarii

  • Dacă aveți nevoie să păstrați istoricul, cu alte cuvinte, există o modificare pe care cineva a tras-o vreodată de la dumneavoastră sau ați împins-o undeva, folosiți soluția din răspunsul lui Yuri Ushakov de mai jos! –  > Por Sedrik.
  • Vă rugăm să deselectați răspunsul câștigător actual, este nesigur (așa cum mulți au subliniat), deși încă adună voturi. Pentru mine „MBO”-s pare cel mai bun, deși are mult mai puține puncte. –  > Por inger.
  • Dacă aveți nevoie de păstrați istoria, folosiți Yuri‘s mai jos! (doar adăugând un link la comentariul lui @Sedrik) –  > Por cregox.
  • În legătură cu: Reveniți la o confirmare Git anterioară. – user456814
  • Aceasta este o resursă excelentă direct de pe Github: Cum să anulezi (aproape) orice cu Git –  > Por jasonleonhard.
33 răspunsuri
Marcin Gil

Cu git reflog verificați care commit este unul anterior fuziunii (git reflog va fi o opțiune mai bună decât git log). Apoi, îl puteți reseta folosind:

git reset --hard commit_sha

Există și o altă modalitate:

git reset --hard HEAD~1

Aceasta vă va aduce înapoi 1 commit.

Fiți atenți la faptul că toate fișierele modificate și neangajate/neangajate vor fi resetate la starea lor nemodificată. Pentru a le păstra, fie ascundeți modificările, fie vedeți --merge opțiunea de mai jos.


Așa cum a sugerat @Velmont în răspunsul său de mai jos, în acest caz direct folosind:

git reset --hard ORIG_HEAD

ar putea da rezultate mai bune, deoarece ar trebui să păstreze modificările. ORIG_HEAD va indica o confirmare direct înainte de a avea loc fuziunea, astfel încât nu trebuie să o căutați singur.


Un alt sfat este să folosiți opțiunea --merge în loc de --hard deoarece acesta nu resetează fișierele în mod inutil:

git reset --merge ORIG_HEAD

–merge

Resetează indexul și actualizează fișierele din arborele de lucru care sunt diferite între <commit> și HEAD, dar le păstrează pe cele care sunt diferite între index și arborele de lucru (adică cele care au modificări care nu au fost adăugate).

Comentarii

    133

  • Nu cred că acest lucru va funcționa (întotdeauna?) – „cea anterioară fuziunii” va fi cea mai recentă confirmare care a fost fuzionată din cealaltă ramură – nu va fi cea mai recentă confirmare de pe ramura curentă. Nu-i așa? (Acest lucru ar putea fi doar un rezultat a ceea ce git log alege să afișeze în mod implicit — poate că există o ieșire diferită a git log sau git reflog ar putea fi folosită pentru acest lucru) – –  > Por John Bachir.
  • Cred că ar putea depinde de faptul dacă striviți fuziunea. –  > Por Marcin Gil.
  • 30

  • @JohnBachir are dreptate. În git log ieșire, trebuie să vă uitați la cele două comisii părinte. Unul este cel mai recent commit din ramura ta, iar celălalt este cel mai recent commit din ramura în care ai fuzionat. Vreți să git reset --hard la commit-ul părinte de pe ramura în care ați fuzionat. –  > Por Justin.
  • @JohnBachir: Atâta timp cât „fuziunea” nu este de fapt un fast forward, aceasta va avea ca rezultat o nouă confirmare care se află în partea de sus a jurnalului, iar această confirmare are doi părinți (sau mai mult de 2 dacă faceți o fuziune octopus). Dacă eliminați această singură confirmare de fuziune, atunci vor dispărea și toate confirmările mai vechi care au venit în urma fuziunii. Totuși, pentru a fi în siguranță, după o resetare, git vă va spune unde se află noul cap: „HEAD este acum la 88a04de <commit message>”. Întotdeauna mă uit la acest lucru pentru a mă asigura că am ajuns unde mă așteptam să fiu. Proiectul meu folosește o schemă standard de denumire a ramurilor pentru a păstra lucrurile memorabile. –  > Por Mark E. Haase.
  • 47

  • Ceea ce mi s-a părut util a fost să mă uit la „git reflog” și să caut ultima confirmare pe care am făcut-o în master. Apoi faceți git reset --hard <commit_sha> –  > Por Max Williams.
randomguy3

Presupunând că masterul local nu a fost înaintea origin/master, ar trebui să puteți face următoarele

git reset --hard origin/master

Apoi, fișierul dvs. local master ar trebui să arate identic cu origin/master.

Comentarii

    75

  • @Carter, de fapt, nu este cel mai bun răspuns. Este posibil ca origin/master să fie înaintea masterului local chiar înainte de fuziune cu câteva comenzi, în acest caz s-ar putea ca acest lucru să nu dea rezultatele dorite –  > Por Dhruva Sagar.
  • 15

  • @dhruva-sagar Da, dar atâta timp cât git nu spune că sunteți în urmă și nu faceți fetch, ar trebui să fie bine. –  > Por Kelvin.
  • Mulțumesc! Acest lucru este perfect dacă (și numai dacă) aveți un depozit la distanță. –  > Por tomc.
  • Nu, nu este perfect pentru această întrebare, vezi clauza „presupun”. Răspunsul lui MBO acoperă de fapt acest caz, precum și cazul în care fuziunea nu este singurul commit local. –  > Por inger.
  • Încă o dată, poate că acest avertisment ar trebui să fie inclus în răspunsul însuși: Evitați întotdeauna să rescrieți istoricul git! –  > Por cregox.
Yuri Geinish

A se vedea capitolul 4 din cartea Git și postarea originală a lui Linus Torvalds.

Pentru a anula o fuziune care a fost deja împinsă:

git revert -m 1 commit_hash

Aveți grijă să reveniți la revenire dacă comiteți din nou ramura, așa cum a spus Linus.

Comentarii

  • @perfectionist de acord 🙂 Aș vrea să existe o modalitate de a migra acest răspuns la o altă întrebare… (poate că există?) –  > Por mikermcneil.
  • pentru mai multe informații despre revert: link –  > Por assaqqaf.
  • Pentru a fi siguri că această revenire a funcționat, puteți face următoarele git diff hash1 hash2 unde hash1 este revenirea confirmată, iar hash2 este vechea confirmare la a cărei stare ați încercat să reveniți. Nici o ieșire == succes! Am reușit să dau înapoi mai multe comenzi făcând acest lucru de mai multe ori, începând prin anularea celei mai recente fuziuni și mergând înapoi. git diff mi-a arătat că am ajuns în starea pe care o doream. –  > Por Robert Sinton.
  • Observați că acest lucru face nu rezolva de fapt întrebarea posterei originale. Posterul original deja a folosit git revert -m 1 <commit>. Problema este că acest lucru nu șterge fuziunea accidentală pe care a făcut-o (și pe care nu a apăsat-o încă). Celelalte răspunsuri care implică resetări bruște sunt mai bune pentru problema posterei originale. – utilizator456814
  • Aceasta este o resursă excelentă direct de pe Github: Cum să anulezi (aproape) orice cu Git –  > Por jasonleonhard.
odinho – Velmont

Este ciudat că cea mai simplă comandă lipsea. Majoritatea răspunsurilor funcționează, dar anularea fuziunii pe care tocmai ai făcut-o, aceasta este calea cea mai ușoară și sigură:

git reset --merge ORIG_HEAD

Ref. ORIG_HEAD va arăta către confirmarea originală de dinaintea fuziunii.

(În cazul în care --merge nu are nimic de-a face cu fuziunea. Este la fel ca git reset --hard ORIG_HEAD, dar mai sigur, deoarece nu atinge modificările neangajate).

Comentarii

    17

  • Dacă v-ați murdărit arborele de lucru de la, git reset --merge ORIG_HEAD păstrează aceste modificări. –  > Por yingted.
  • Acesta este singura răspuns corect (nu spun că acesta este cel mai bun răspuns – rețineți diferența). Să spunem că, pe master, am făcut 3 comenzi la t1, t3 și t5. Să spunem că, pe branch1, am făcut 3 comentarii la t2, t4 și t6 (presupunem că t1, t2, t3, t4, t5 și t6 sunt în ordine cronologică). Orice comandă similară cu git reset --hard HEAD~5 va reseta doar HEAD (poate elimina comenzi atât în master, cât și în branch1). Doar comanda --merge îndepărtează merge. –  > Por Manu Manjunath.
  • @Manu The --merge nu înlătură de fapt fuziunea, puteți folosi opțiunea --hard va funcționa, de asemenea, bine. Este referința ORIG_HEAD care este indiciul aici, este setată înainte de a face o fuziune la locul în care vă aflați în acel moment. 🙂 –  > Por odinho – Velmont.
  • @yingted ce vrei să spui prin „Dacă ai murdărit arborele de lucru de atunci, git reset –merge ORIG_HEAD păstrează acele modificări.” Te-ai referit la modificarea fișierelor după fuziune ? Oricum, am făcut fuziunea și apoi am făcut o parte din rezolvarea conflictelor. Dar apoi am vrut să resetez fuziunea și am făcut așa cum este indicat în acest răspuns. Totul a fost în regulă și nu a păstrat modificările mele făcute după fuziune. Repo-ul meu local este doar similar cu poziția de dinainte de a face fuziunea. –  > Por Samitha Chathuranga.
  • git reset --hard ORIG_HEAD a funcționat perfect în cazul meu – poate că a fost ajutat de faptul că nu am făcut alte modificări în depozit după ce am făcut modificarea locală. git merge pe care încercam să le anulez. Comanda pur și simplu a resetat starea depozitului la cum era înainte de fuziune. Mulțumesc pentru acest sfat minunat! –  > Por bluebinary.
Travis Reeder

Cu versiunile mai noi de Git, dacă nu ați confirmat încă fuziunea și aveți un conflict de fuziune, puteți face pur și simplu:

git merge --abort

De la man git merge:

[Acest lucru] poate fi rulat numai după ce fuziunea a dus la conflicte. git merge --abort va întrerupe procesul de fuziune și va încerca să reconstruiască starea anterioară fuziunii.

Comentarii

  • Fuziunea lui este confirmată, dar nu este împinsă (vezi titlul), el a fuzionat deja, comanda ta funcționează numai atunci când este încă în mijlocul unei fuziuni –  > Por JBoy.
MBO

Ar trebui să resetați la confirmarea anterioară. Acest lucru ar trebui să funcționeze:

git reset --hard HEAD^

Sau chiar HEAD^^ pentru a inversa acea confirmare de inversare. Puteți da întotdeauna o referință completă SHA dacă nu sunteți sigur câți pași înapoi ar trebui să faceți.

În cazul în care aveți probleme și ramura principală nu a avut nicio modificare locală, puteți reseta la origin/master.

Comentarii

  • Cel mai bun răspuns, IMHO, îl încorporează pe cel al lui OP (presupunând doar un singur pas pentru a reveni, ceea ce părea a fi cazul în Q), precum și pe cel al scurtăturii lui randomguy3 (care funcționează atunci când „ramura principală nu a avut modificări locale”) –  > Por inger.
  • Voi, comentatorilor, @Inger și @Konstantin, de ce? Ați venit aici după ce a fost creat răspunsul meu, iar acesta este mai corect. Doar urcând HEAD cu un singur pas este adesea greșit, și ar trebui să numărați efectiv cât de sus trebuie să urcați. Git stabilește deja ORIG_HEAD pentru tine, de ce să nu-l folosești? –  > Por odinho – Velmont.
  • va reseta și modificările locale ? #PleaseUpdate. –  > Por CoDe.
  • Acest lucru a funcționat perfect pentru mine, resetarea capului ca asta are mult mai mult sens decât jumătate din răspunsurile de aici. –  > Por Varda Elentári.
  • HEAD^ este egal cu commit-ul anterior lui HEAD? și ^^ este cu două commit-uri înainte? Presupunând că nu va funcționa cu fuziuni rapide înainte? –  > Por Marcus Leon.
Parris

În ultima vreme, am folosit git reflog pentru a vă ajuta în acest sens. Acest lucru funcționează în mare parte numai dacă fuziunea s-a întâmplat ÎNCĂ o dată și a fost pe mașina ta.

git reflog ar putea returna ceva de genul:

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

Prima linie indică faptul că a avut loc o fuziune. A doua linie este ora de dinaintea fuziunii mele. Pur și simplu git reset --hard 43b6032 să forțez această ramură să urmărească de dinainte de fuziune și să continue.

Comentarii

  • Un răspuns excelent, vă mulțumesc! Aveam nevoie să anulez o fuziune, dar celelalte răspunsuri au dat-o în bară și mai mult, folosind reflog pentru a obține SHA și a o trece în git reset a funcționat. –  > Por utilizator692942.
  • Mulțumesc mult 🙂 mi-a salvat ziua. –  > Por Jivan.
Martin G

Cu Git modern, puteți:

git merge --abort

Sintaxa mai veche:

git reset --merge

Vechea școală:

git reset --hard

Dar, de fapt, merită să observați că git merge --abort este echivalent doar cu git reset --merge având în vedere că MERGE_HEAD este prezent. Acest lucru poate fi citit în ajutorul Git pentru comanda merge.

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

După o fuziune eșuată, atunci când nu există MERGE_HEAD, fuziunea eșuată poate fi anulată cu git reset --merge, dar nu neapărat cu git merge --abort, deci nu sunt doar o sintaxă veche și una nouă pentru același lucru.

Personal, consider că git reset --merge mult mai puternică și mai utilă în munca de zi cu zi, așa că aceasta este cea pe care o folosesc întotdeauna.

Comentarii

  • A funcționat foarte bine pentru mine. Fiecare alt post spune că este atât de complicat, dar acest lucru a făcut exact ceea ce se așteaptă. Presupun că a funcționat doar pentru că au existat conflicte, ceea ce nu răspunde exact la întrebarea inițială. –  > Por Jeremy.
  • Acest răspuns nu se concentrează pe situația lui OP și omite un context important. –  > Por Ben Wheeler.
Matt Huggins

Bine, răspunsurile pe care mi le-au dat alte persoane de aici au fost apropiate, dar nu a funcționat. Iată ce am făcut eu.

Făcând asta…

git reset --hard HEAD^
git status

…mi-a dat următoarea stare.

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

Apoi a trebuit să tastez aceeași git reset comandă de mai multe ori. De fiecare dată când am făcut asta, mesajul s-a schimbat cu unul, după cum puteți vedea mai jos.

> 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.

În acest moment, am văzut că mesajul de stare s-a schimbat, așa că am încercat să fac un git pull, și asta a părut să funcționeze:

> 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

Deci, pe scurt, comenzile mele se rezumau la asta:

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

Comentarii

    19

  • sau ai fi putut folosi HEAD^^^^ –  > Por hasen.
  • 17

  • poate chiar să se reseteze la origin/master 😉 –  > Por hasen.
CodeWizard

Trebuie să schimbi HEAD, Nu al tău, desigur, ci git HEAD….

Deci, înainte de a răspunde, să adăugăm niște informații de fond, explicând ce este acest lucru HEAD.

First of all what is HEAD?

HEAD este pur și simplu o referință la confirmarea curentă (cea mai recentă) pe ramura curentă.
Nu poate exista decât un singur HEAD la un moment dat. (cu excepția git worktree)

Conținutul lui HEAD este stocat în interiorul .git/HEAD și conține cei 40 de octeți SHA-1 ai confirmării curente.


detached HEAD

Dacă nu vă aflați pe ultima confirmare – ceea ce înseamnă că HEAD indică o confirmare anterioară în istoric, se numește detached HEAD.

Pe linia de comandă, va arăta astfel – SHA-1 în loc de numele ramurii, deoarece HEAD nu indică spre vârful ramurii curente.

Câteva opțiuni pentru a recupera un HEAD detașat:


git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

Aceasta va verifica o nouă ramură care să arate spre confirmarea dorită.
Această comandă va face checkout către o anumită confirmare.
În acest moment, puteți crea o ramură și puteți începe să lucrați din acest punct.

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

Puteți utiliza întotdeauna comanda reflog de asemenea.
git reflog va afișa orice modificare care a actualizat HEAD iar verificarea intrării de reflog dorite va seta HEAD înapoi la această confirmare.

De fiecare dată când HEAD este modificat, va exista o nouă intrare în fișierul reflog

git reflog
git checkout [email protected]{...}

Acest lucru vă va duce înapoi la confirmarea dorită


git reset --hard <commit_id>

„Mutați” HEAD înapoi la confirmarea dorită.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.
  • Notă: (Începând cu Git 2.7)
    puteți utiliza, de asemenea, funcția git rebase --no-autostash de asemenea.

git revert <sha-1>

„Anulați” comiterea sau intervalul de comitere dat.
Comanda de resetare va „anula” toate modificările efectuate în confirmarea dată.
O nouă confirmare cu patch-ul de anulare va fi confirmată, în timp ce confirmarea originală va rămâne și ea în istoric.

# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

Această schemă ilustrează ce comandă face fiecare.
După cum puteți vedea, există reset && checkout modifică HEAD.

Comentarii

  • Aceasta este comoara –  > Por Jawand Singh.
stephjang

Ați putea folosi git reflog pentru a găsi checkout-ul anterior. Uneori este o stare bună la care vrei să te întorci.

În mod concret,

$ git reflog
$ git reset --hard [email protected]{0}

Comentarii

  • Vă mulțumim! Mi-ați salvat o jumătate de zi de muncă. Cu toate acestea, nu am putut ieși din modul reflog cu nicio comandă. –  > Por Katarzyna.
  • @Katarzyna folosiți tasta „q” pentru a ieși din reflog –  > Por Amjed Baig.
llioor

Dacă vă aflați în mijlocul unei fuziuni, puteți oricând să o întrerupețigit merge --abort

Comentarii

  • mulțumesc frate și eram pe cale să fac chestia aia înfricoșătoare răspuns corect. noroc că am derulat în jos. vreau doar să șterg capul de fuziune –  > Por Nyuu.
Ralph Ritoch

Am reușit să rezolv această problemă cu o singură comandă care nu implică căutarea unui id de commit.

git reset --hard remotes/origin/HEAD

Răspunsul acceptat nu a funcționat pentru mine, dar această comandă a obținut rezultatele pe care le căutam.

Comentarii

  • Exact! Îți resetează modificările la HEAD al ramurii! Nu face una câte una –  > Por Carlos Zinato.
  • nu a funcționat pentru mine. de fapt, a sfârșit prin a trimite ramura locală înapoi cu o lună sau două. Din fericire, totul este local, așa că pot distruge oricând ramura și să o recuperez din nou. Am vrut doar să subliniez asta în cazul în care alții au încercat acest lucru. –  > Por Matt Pengelly.
  • @MattPengelly această metodă este în mare parte nedocumentată și, de obicei, funcționează dacă ramura dvs. este sincronizată cu ramura de la distanță înainte de a face fuziunea. Au trecut luni de zile de când ramura dvs. a fost sincronizată cu ramura de la distanță? –  > Por Ralph Ritoch.
  • @MattPengelly depinde, de asemenea, de ramura către care este îndreptat HEAD. Folosesc gitflow pe unul dintre proiectele mele și, chiar dacă mă aflu pe ramura develop, remotes/origin/HEAD este îndreptat către origin/master, așa că, dacă aș avea nevoie să anulez o fuziune, probabil ar trebui să resetez la remotes/origin/develop –  > Por Ralph Ritoch.
Amit Kaneria

Se poate face în mai multe moduri.

1) Abandonați fuziunea

Dacă vă aflați între două fuziuni proaste (realizate din greșeală cu o ramură greșită) și ați dorit să evitați fuziunea pentru a vă întoarce la ultima ramură, după cum urmează:

git merge --abort

2) Resetați HEAD la ramura de la distanță

Dacă lucrați de pe ramura de dezvoltare la distanță, puteți reseta HEAD la ultima confirmare de pe ramura la distanță, după cum urmează:

git reset --hard origin/develop

3) Ștergeți ramura curentă și efectuați din nou checkout din depozitul la distanță

Având în vedere că lucrați pe ramura de dezvoltare din repo-ul local, care se sincronizează cu ramura de la distanță/dezvoltare, puteți proceda după cum urmează:

git checkout master 
##to delete one branch, you need to be on another branch, otherwise you will fall with the branch :) 

git branch -D develop
git checkout -b develop origin/develop

Comentarii

  • că „1) Abort Merge” a fost destul de suficient. Upvoting. –  > Por CodeToLife.
  • Aveți grijă! git merge –abort „poate fi rulat numai după ce fuziunea a dus la conflicte. git merge –abort va întrerupe procesul de fuziune și va încerca să reconstruiască starea de dinaintea fuziunii” –  > Por Pedro García Medina.
  • git reset --hard origin/develop asta era ceea ce căutam, vă mulțumesc! –  > Por Mattisdada.
Idealmind

Dacă nu l-ați comis încă, puteți folosi doar

$ git checkout -f

Aceasta va anula fuziunea (și tot ceea ce ați făcut).

Comentarii

  • Am încercat acest lucru și de fapt a crescut numărul de comenzi pe care ramura mea locală este înainte. –  > Por barclay.
leanne

Ajuns la această întrebare, de asemenea, căutând să revină la originea de potrivire (adică, NU există nici un commit înainte de origine). Cercetând în continuare, am aflat că există o reset comandă pentru exact acest lucru:

git reset --hard @{u}

Notă: @{u} este o prescurtare pentru origin/master. (Și, bineînțeles, aveți nevoie de acel depozit la distanță pentru ca acest lucru să funcționeze).

Harsha

Cel mai simplu răspuns este cel dat de odinho – Velmont

Mai întâi faceți git reset --merge ORIG_HEAD

Pentru cei care caută să reseteze după ce modificările sunt împinse, faceți acest lucru(Pentru că aceasta este prima postare văzută pentru orice întrebare de fuziune git reset)

git push origin HEAD --force

Acest lucru va reseta în așa fel încât să nu mai primiți modificările fuzionate înapoi după pull.

Matheus Abreu

Puteți utiliza doar două comenzi pentru a inversa o fuziune sau pentru a reporni după un anumit commit:

  1. git reset --hard commitHash (trebuie să folosiți commit-ul pe care doriți să-l reporniți, de exemplu 44a587491e32eafa1638aca7738)
  2. git push origin HEAD --force (Trimiterea noii ramuri master locale către origin/master)

Mult noroc și mergeți înainte!

Damien Byrne

Doar pentru o opțiune suplimentară la care să vă uitați, am urmat în mare parte modelul de ramificare descris aici: http://nvie.com/posts/a-successful-git-branching-model/ și, ca atare, am fuzionat cu --no-ff (fără fast forward) de obicei.

Tocmai am citit această pagină, deoarece din greșeală am fuzionat o ramură de testare în loc de ramura de lansare cu master pentru desfășurare (site-ul web, master este ceea ce este live). Ramura de testare are alte două ramuri fuzionate la ea și totalizează aproximativ șase comenzi.

Deci, pentru a inversa întreaga confirmare, aveam nevoie doar de un singur lucru git reset --hard HEAD^ și a fost anulată întreaga fuziune. Deoarece fuziunile nu au fost rapid înaintate, fuziunea a fost un bloc și un pas înapoi este „branch not merged”.

Stephan

Dacă fuziunea ta și comenzile corespunzătoare nu au fost încă împinse, poți oricând să treci la o altă ramură, să o ștergi pe cea originală și să o recreezi.

De exemplu, am fuzionat din greșeală o ramură de dezvoltare în master și am vrut să anulez acest lucru. Folosind următorii pași:

git checkout develop
git branch -D master
git branch -t master origin/master

Voila! Master se află în același stadiu cu origin, iar starea ta de fuziune greșită este ștearsă.

Comentarii

  • Notă: Acest lucru nu anulează doar fuziunea, ci și orice comenzi locale care au fost făcute de la ultimul push către origin. –  > Por Martijn Heemels.
bunny patel

Dacă ramurile sunt fuzionate și nu sunt împinse, atunci comanda git reset dată mai jos va funcționa pentru a anula fuziunea:git reset –merge ORIG_HEAD

inger

Dacă doriți o soluție în linie de comandă, vă sugerez să mergeți doar cu răspunsul lui MBO.

Dacă sunteți începător, s-ar putea să vă placă abordarea grafică:

  1. Lansare gitk (din linia de comandă, sau faceți clic dreapta în browserul de fișiere dacă aveți așa ceva)
  2. Puteți identifica cu ușurință angajamentul de fuziune acolo – primul nod de sus cu doi părinți
  3. Urmați link-ul către primul părinte/părintele din stânga (cel de pe ramura dvs. curentă înainte de fuziune, de obicei roșu pentru mine)
  4. Pe comiterea selectată, faceți clic dreapta pe „Reset branch to here”, alegeți resetarea dură de acolo

pyb

Strategie: Creați o nouă ramură de unde totul era bun.

Raționament: Anularea unei fuziuni este dificilă. Există prea multe soluții, care depind de mulți factori, cum ar fi dacă ați confirmat sau ați împins fuziunea sau dacă au existat noi confirmări de la fuziune. De asemenea, trebuie să aveți încă o înțelegere relativ profundă a git pentru a adapta aceste soluții la cazul dumneavoastră. Dacă urmați orbește unele instrucțiuni, puteți ajunge la o „fuziune goală” în care nimic nu va fi fuzionat, iar încercările ulterioare de fuziune vor face ca Git să vă spună „Already up to date”.

Soluție:

Să spunem că doriți să fuzionați dev în feature-1.

  1. Găsiți revizuirea care doriți să primească fuziunea:

    git log --oneline feature-1
    a1b2c3d4 Merge branch 'dev' into 'feature-1' <-- the merge you want to undo
    e5f6g7h8 Fix NPE in the Zero Point Module <-- the one before the merge, you probably want this one
    
  2. Verificați-o (mergeți înapoi în timp):

    git checkout e5f6g7h8
    
  3. Creați o nouă ramură de acolo și verificați-o:

    git checkout -b feature-1
    

Acum puteți reporni fuziunea:

  1. Unificare: git merge dev

  2. Rezolvați conflictele de fuziune.

  3. Trimiteți: git commit

  4. Când sunteți mulțumit de rezultate, ștergeți vechea ramură: git branch --delete feature-1

gdbdable

Doar creați o nouă ramură, apoi selectați comenzile dorite pentru ea.

Este mai simplu și mai simplu decât resetarea descrisă în multe răspunsuri de mai sus.

Comentarii

  • Sunt de acord cu această sugestie, mai ales dacă nu vă simțiți pe deplin confortabil cu comenzile git enumerate. Acest lucru poate fi mai lent, cu mai multă „trudă”, dar dacă nu apare prea mult și sunteți îngrijorat de pierderea muncii dvs. merită efortul. –  > Por Greg.
tychoish

Cred că puteți face git rebase -i [hash] [branch_name] unde [hash] este hash-ul de identificare pentru oricât de departe în urmă doriți să derulați înapoi plus unu (sau oricât de multe comisioane înapoi doriți să mergeți) și apoi ștergeți liniile pentru comisioanele din editor pe care nu le mai doriți. Salvați fișierul. Ieșiți. Rugați-vă. Și ar trebui să fie derulat din nou. S-ar putea să trebuiască să faceți un git reset --hard, dar ar trebui să fie bine în acest moment. De asemenea, puteți folosi acest lucru pentru a scoate anumite comenzi dintr-o stivă, dacă nu doriți să le păstrați în istoric, dar acest lucru poate lăsa depozitul într-o stare pe care probabil nu o doriți.

Dorian

Dacă ați confirmat fuziunea:

git reset HEAD~1
# Make sure what you are reverting is in fact the merge files
git add .
git reset --hard

kenorb
  1. În primul rând, asigurați-vă că ați confirmat totul.

  2. Apoi, resetați depozitul la starea de lucru anterioară:

    $ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36
    

    sau folosind --hard (acest lucru va elimina toate modificările locale, care nu au fost confirmate!):

    $ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36 --hard
    

    Folosiți hash-ul care a existat înainte de a fi comasat greșit.

  3. Verificați care dintre confirmări doriți să le re-commiteți deasupra versiunii corecte anterioare prin:

    $ git log 4c3e23f529b581c3cbe95350e84e66e3cb05704f
    
    commit 4c3e23f529b581c3cbe95350e84e66e3cb05704f
    
    ...
    
    commit 16b373a96b0a353f7454b141f7aa6f548c979d0a
    
    ...
    
  4. Aplicați comiterile corecte pe partea de sus a versiunii corecte a depozitului dvs. prin:

    • Utilizând cherry-pick (modificările introduse de unele comisioane existente).

          git cherry-pick ec59ab844cf504e462f011c8cc7e5667ebb2e9c7
      
    • Sau prin cherry-picking intervalul de comenzi prin:

      • Verificând mai întâi modificările corecte înainte de a le unifica:

        git diff 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
        
      • Verificând mai întâi modificările corecte înainte de a le unifica:

        git cherry-pick 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
        

        unde acesta este intervalul de modificări corecte pe care le-ați comis (excluzând fuzionările greșite).

Siva Kumar
  1. git stash

  2. git branch -d the_local_branch

  3. git checkout -t <name of remote>

  4. git stash apply

Acest lucru a funcționat pentru mine…!!!

binecuvântat

Răspunzând la întrebarea „Anularea unei fuziuni Git care nu a fost încă împinsă

Puteți folosi git reset --hard HEAD~1

Luați în considerare următoarea situație în care există 2 ramuri master și feature-1:


$ git log --graph --oneline --all

Faceți o fuziune Git

$ git merge feature-1

$ git log --graph --oneline --all

Anulează fuziunea Git

$ git reset --hard HEAD~1

$ git log --graph --oneline --all

Daniel Dut

Dacă observați că trebuie să reveniți imediat după fuziune și nu ați făcut nimic altceva după încercarea de fuziune, puteți lansa această comandă:git reset --hard [email protected]{1}.

În esență, fuziunea dvs. sha va fi îndreptată către [email protected]{0} dacă nu a fost confirmat nimic altceva după fuziune și astfel [email protected]{1} va fi punctul precedent înainte de fuziune.

Luis

Cea mai simplă dintre cele mai simple șanse, mult mai simplă decât tot ce s-a spus aici:

Scoateți ramura locală (locală, nu de la distanță) și trageți-o din nou. În acest fel vei anula modificările de pe ramura principală și oricine va fi afectat de modificarea pe care nu vrei să o împingi. Începeți-o din nou.

Nesha Zoric

În acest caz, veți dori să vă resetați ramura cu git reset --hard <branch_name>. Dacă doriți să vă salvați modificările înainte de a le reseta, asigurați-vă că creați o nouă ramură și git checkout <branch_name>.

Puteți reseta starea la un anumit commit cu git reset --hard <commit_id> de asemenea.

Dacă modificările au fost împinse, puteți folosi git revert <branch_name> în loc de . Nu uitați să verificați cum se utilizează git revert și git checkout și în alte scenarii.

NebuSoft

Puteți folosi comanda git-reset.

git-reset – Resetează HEAD-ul curent la valoarea

starea specificată. git reset [–mixed |

–soft | –soft | –hard | –merge] [-q] [] git reset [-q] []

[–] … git reset –patch

[] [–] […]

GIT-Reset

Comentarii

  • Am încercat git reset, git reset --merge, și git reset --hard, dar tot mă trezesc cu același mesaj despre faptul că sunt cu 5 comenzi înaintea origin/master. –  > Por Matt Huggins.