Cum pot elimina o confirmare pe GitHub? [duplicat] (Programare, Git, Github, Git Commit)

hectorsq a intrebat.

Am împins „din greșeală” un commit pe GitHub.

Este posibil să înlătur acest commit?

Vreau să-mi restabilesc depozitul GitHub așa cum era înainte de acest commit.

Comentarii

    193

  • Cuvânt de precauție: Nu faceți niciodată acest lucru atunci când aveți o mulțime de oameni care vă urmăresc depozitul, veți face ca depozitul lor local să nu mai fie sincronizat dacă au preluat cele mai recente modificări. Dacă este vorba de o greșeală, puteți face o altă confirmare care să anuleze greșeala. Dacă este vorba despre o parolă, ar fi mai bine să schimbați parola și nu vă grăbiți să ștergeți acest lucru. Forțarea lucrurilor nu este lipsită de dezavantaje. –  > Por Tamara Wijsman.
  • 148

  • Cuvânt de precauție 2: Confirmarea poate fi în continuare accesibilă direct prin SHA1. Force push nu șterge confirmarea, ci creează una nouă și mută pointerul de fișier la aceasta. Pentru a șterge cu adevărat o confirmare, trebuie să ștergeți întregul repo. –  > Por Gustav.
  • 19

  • Mulțumesc, că WOC2 m-a ajutat să-mi recuperez codul prețios de la o ștergere greșită!!! Mulțumesc! –  > Por kR105.
  • 24

  • @Gustav „… trebuie să ștergeți întregul repo.” – Sau doar forțați colectarea gunoiului să intre în acțiune. –  > Por IQAndreas.
  • Versiunea Bitbucket a acestei întrebări. –  > Por naught101.
21 răspunsuri
Can Berk Güder

Notă: vă rugăm să vedeți o alternativă la git rebase -i în comentariile de mai jos-

git reset --soft HEAD^

În primul rând, eliminați comiterea pe depozitul local. Puteți face acest lucru utilizând git rebase -i. De exemplu, dacă este vorba de ultima dvs. confirmare, puteți face git rebase -i HEAD~2 și să ștergeți a doua linie din fereastra editorului care apare.

Apoi, forțați împingerea către GitHub folosind git push origin +branchName --force

Consultați Git Magic Capitolul 5: Lecții de istorie – și încă ceva pentru mai multe informații (de exemplu, dacă doriți să eliminați comenzi mai vechi).

Oh, și dacă arborele tău de lucru este murdar, trebuie să faci un git stash mai întâi și apoi un git stash apply după.

Comentarii

  • Mai exact, trebuie /trebuie/ să faci stash, deoarece git rebase -i nu te va lăsa dacă ai un arbore murdar. –  > Por Otto.
  • 23

  • Rețineți că acest lucru va lăsa în continuare comiterea în reflog. Dacă aveți date sensibile acolo, este posibil să trebuiască să ștergeți repo-ul în întregime. –  > Por troelskn.
  • 121

  • Sunt confuz. De ce nu este posibil să nu se facă uncommit cu git reset --soft HEAD^ și apoi să faceți git push origin +master? De ce folosim git rebase -i HEAD^^ în acest caz? –  > Por Dennis.
  • 52

  • @Dennis pentru că nu eram familiarizat cu reset --soft 3,5 ani în urmă. =) –  > Por Can Berk Güder.
  • 35

  • Toată lumea să fie atentă. Vezi comentariul lui subutux de mai jos. Chiar și după ce forțezi împingerea pe GitHub, GH încă mai păstrează în cache confirmarea ta. De la help.github.com/articles/remove-sensitive-data : „Danger: Odată ce confirmarea a fost împinsă, ar trebui să considerați că datele sunt compromise. Dacă ați comis o parolă, schimbați-o! Dacă ați comis o cheie, generați una nouă.” –  > Por Patrick.
Dustin
git push -f origin HEAD^:master

Acest lucru ar trebui să „anuleze” push-ul.

Comentarii

    34

  • Și asta a funcționat bine! Îndepărtează push-ul de pe github, dar îmi lasă depozitul local intact. Mulțumesc! –  > Por hectorsq.
  • Ei bine, da. Face doar ceea ce ai cerut. 🙂 Depozitul dvs. și depozitul de la distanță nu trebuie să aibă referințe identice. –  > Por Dustin.
  • 35

  • Rețineți, totuși, că acest lucru mută doar indicatorul de ramură. Confirmarea împinsă accidental este încă prezentă în repo-ul de la distanță. În cazul GitHub, acest lucru înseamnă că poate fi în continuare văzut dacă cunoașteți hash-ul SHA-1 (din istoricul activității utilizatorului, de exemplu). –  > Por Thiago Arrais.
  • 84

  • faceți: git push -f origin HEAD^^^:master pentru a inversa ultimele 2 modificări, funcționează de n ori –  > Por ianj.
  • 22

  • @ianj Rețineți că HEAD cu n ^-uri poate fi înlocuit cu HEAD~n, de exemplu, HEAD~3 în loc de HEAD^^^^. –  > Por Mark Reed.
CodeWalrus

Pentru o revenire ușoară, dacă este doar o greșeală (poate că ați făcut un fork la un repo, apoi ați ajuns să faceți push la original în loc de unul nou), iată o altă posibilitate:

git reset --hard 71c27777543ccfcb0376dcdd8f6777df055ef479

În mod evident, schimbați numărul respectiv cu numărul de confirmare la care doriți să reveniți.

Tot ceea ce s-a întâmplat de atunci va fi șters odată ce faceți push din nou. Pentru a face asta, următorul pas ar fi:

git push --force

Comentarii

  • AVERTISMENT: Acest lucru vă va rescrie istoricul, veți pierde confirmarea și, în general, nu este un lucru foarte plăcut de făcut într-un mediu colaborativ. –  > Por Oliver.
  • Da, acesta a fost cel mai simplu și cel mai bun pentru mine. Furculița mea dev trebuia să fie reversată înainte de a putea trimite un PR pentru altceva. Ar fi trebuit să-mi pun modificările într-o ramură pentru început. –  > Por Web și flux.
  • Acest lucru funcționează pe ramurile neprotejate. Dacă ramura Github este protejată, push-ul forțat va eșua. –  > Por Adarsha.
  • Sau: || git reset –hard HEAD^1 || (1 este ultimul commit) –  > Por Marian07.
  • Pentru că nu am putut edita, mai adaug un comentariu, în cazul în care cineva face această prostie fără să se gândească înainte, la fel ca mine, puteți reveni cu un „git reflog” și apoi un „git reset –hard xxx” unde xxx este ultimul commit pe care l-ați făcut înainte de resetarea accidentală… –  > Por Fjallbacka.
kate
  1. git logpentru a afla ce commit doriți să redați

  2. git push origin +7f6d03:masterîn timp ce 7f6d03 este confirmarea de dinaintea confirmării împinse greșit.+ a fost pentru force push

Și asta e tot.

Aici este un ghid foarte bun care îți rezolvă problema, ușor și simplu!

Comentarii

  • Îți recomand acest ghid, super util în acest sens. –  > Por tfantina.
  • Cel mai bun răspuns! Ce se întâmplă este atât de clar -.  > Por Naramsim.
  • Acest lucru funcționează pentru mine pentru ștergerea câtorva din ultimele comenzi publicate dintr-o ramură. –  > Por Sir iPad Newton.
  • După câteva momente încercând să descopere de ce această comandă nu funcționa, ați indicat în mod clar aici pentru a introduce ultima comitere de dorit. Și am încercat să fac primul commit, motiv pentru care am primit mesajul că era deja actualizat. –  > Por Luis Febro.
  • Acesta ar trebui să fie răspunsul acceptat, deoarece întrebarea nu a specificat ce commit să fie șters. Răspunsul acceptat șterge doar ultimul ultima confirmare. Acest răspuns șterge orice comitere. –  > Por Dominic Cerisano.
Loukan ElKadi

În cazul în care doriți să păstrați modificările de confirmare după ștergere:

Rețineți că această soluție funcționează dacă confirmarea care urmează să fie eliminată este ultima confirmată.


1 – Copiați din jurnal referința de confirmare la care doriți să vă întoarceți:

git log

2 – Resetați git la referința de confirmare:

 git reset <commit_ref>

3 – Stash/stocați modificările locale de la confirmarea greșită pentru a le folosi mai târziu după împingerea la distanță:

 git stash

4 – Împingeți modificările în depozitul de la distanță (-f sau –force):

git push -f

5 – Recuperați modificările stocate în depozitul local:

git stash apply

7 – În cazul în care aveți fișiere noi/neînregistrate în modificări, trebuie să le adăugați la git înainte de a le confirma:

git add .

6 – Adăugați orice modificări suplimentare de care aveți nevoie, apoi confirmați fișierele necesare, (sau folosiți un punct „.” în loc să indicați numele fiecărui fișier, pentru a confirma toate fișierele din depozitul local:

git commit -m "<new_commit_message>" <file1> <file2> ...

sau

git commit -m "<new_commit_message>" .

Comentarii

  • Vă mulțumim! Eram doar fericit că am revenit la 5. Apoi am putut să lucrez cu modificările în github desktop. –  > Por user2568374.
  • Asta era exact ceea ce voiam să fac și a funcționat perfect! –  > Por Luigi.
  • acesta este cel mai bun răspuns adecvat pentru întrebare! –  > Por joe-khoa.
  • Tocmai mi-ai salvat viața 🙂 –  > Por Koga.
subutux

Va trebui să vă ștergeți memoria cache pentru a o șterge complet. această pagină de ajutor de la git vă va ajuta. (pe mine m-a ajutat)http://help.github.com/remove-sensitive-data/

Comentarii

  • +1: în timp ce eliminați comiterea din ramura dvs., este încă disponibilă pe GitHub dacă știți URL-ul/SHA-1. Singura modalitate de a elimina confirmarea din cache este să contactați asistența GH (consultați secțiunea „Cached Data on Github” din acel link –  > Por Patrick.
  • Vreau să remarc faptul că poate ar fi fost o idee mai bună să explici de fapt ce se află pe pagină și să citezi secțiunile relevante. Din ghidul de ajutor, se spune: „Legăturile către resurse externe sunt încurajate, dar vă rugăm să adăugați un context în jurul linkului, astfel încât colegii dvs. utilizatori să aibă o idee despre ce este și de ce se află acolo. Citați întotdeauna partea cea mai relevantă a unui link important, în cazul în care site-ul țintă nu poate fi accesat sau este permanent offline.” Regula de bază: pretindeți că linkul nu există sau că nu pot da clic pe el. –  > Por Jeremy Rodi.
  • Există o altă modalitate de a șterge memoria cache: Ștergeți depozitul, apoi recreați-l și faceți push. Deși acest lucru s-ar putea să nu fie posibil pentru toată lumea, pentru mulți este mult mai ușor și mai rapid decât să contacteze serviciul de asistență Github (și poate că nu doriți să indicați unei terțe părți [Github] că ați împins date sensibile). –  > Por Juliane Holzt.
Ekambaram E

Ștergeți cea mai recentă confirmare, păstrând munca pe care ați făcut-o:

git reset --soft HEAD~1

Ștergeți cea mai recentă confirmare, distrugând munca pe care ați făcut-o:

git reset --hard HEAD~1

Comentarii

  • cum rămâne cu push-ul de după? –  > Por user2568374.
Jyoti Prakash

Utilizați git revert pentru a vă anula push-ul.

git-revert – Revocă unele comenzi existente

git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
git revert --continue
git revert --quit
git revert --abort

Revertiți modificările pe care le introduc patch-urile aferente și înregistrați niște commits noi care le înregistrează. Acest lucru necesită ca arborele dvs. de lucru să fie curat (fără modificări față de confirmarea HEAD).

Comentarii

  • Aceasta este modalitatea recomandată pentru a evita ruperea clonelor altor persoane. Se creează o nouă confirmare care anulează o confirmare anterioară. Cu toate acestea, nu răspunde la întrebare, care era de a elimina o confirmare din „istoric”. –  > Por joeytwiddle.
  • multe dintre celelalte răspunsuri sunt bune, dar aceasta este singura modalitate care pare să funcționeze dacă nu puteți face forțarea push-urilor către master. –  > Por Christopher Hunter.
Hilen
1. git reset HEAD^ --hard
2. git push origin -f

Acest lucru funcționează pentru mine.

Comentarii

  • Spune „Totul este actualizat” când confirmarea este deja împinsă pe GitHub… –  > Por Benny Neugebauer.
  • Dacă comiterea A este cea de sus, B este a doua. Care confirmare doriți să o resetați? –  > Por Hilen.
  • A este cea mai recentă și aș dori să mă întorc la B. –  > Por Benny Neugebauer.
  • git reset B --hard apoi git push origin -f –  > Por Hilen.
  • Acest lucru a funcționat cel mai bine pentru mine atunci când am vrut să șterg o confirmare dintr-o ramură la care lucram. –  > Por LeraA.
george mano

Pentru a șterge confirmarea din depozitul la distanță:

 git push -f origin last_known_good_commit:branch_name

Pentru a șterge confirmarea din depozitul local:

git reset --hard HEAD~1

link

Benny Neugebauer

Trebuie să știți hash-ul de confirmare din confirmarea la care doriți să reveniți. Îl puteți obține de la o adresă URL GitHub, cum ar fi: https://github.com/your-organization/your-project/commits/master

Să presupunem că hash-ul de la commit (unde doriți să vă întoarceți) este „99fb454” (versiunea lungă „99fb45413eb9ca4b3063e07b40402b136a8cf264”), atunci tot ce trebuie să faceți este:

git reset --hard 99fb45413eb9ca4b3063e07b40402b136a8cf264
git push --force

Comentarii

  • IMHO acesta este cel mai bun răspuns aici –  > Por 1000Gbps.
  • De acord, funcționează ca prin minune. Acesta este un răspuns foarte subestimat. –  > Por harshithdwivedi.
orb

Găsește pe Github specificația de ref. a commit-ului pe care vrei să fie capul ramurii tale și folosește următoarea comandă:

git push origin +[ref]:[branchName]

În cazul tău, dacă vrei să te întorci doar cu o singură confirmare, găsește începutul referinței pentru acea confirmare, să spunem că, de exemplu, este 7f6d03, și numele ramurii pe care vrei să o schimbi, să spunem că, de exemplu, este master, și fă următoarele:

git push origin +7f6d03:master

Caracterul plus este interpretat ca fiind --force, , care va fi necesar deoarece rescrieți istoricul.

Rețineți că de fiecare dată când --force o confirmare puteți rescrie istoricul altor persoane care fuzionează ramura dumneavoastră. Cu toate acestea, dacă sesizați rapid problema (înainte ca altcineva să fuzioneze ramura dvs.), nu veți avea probleme.

goncalopp

Dacă faceți acest lucru pentru că aveți date sensibile într-un commit, folosirea celorlalte răspunsuri de aici nu este sigură (cu excepția răspunsului lui subutux, pe care îl voi dezvolta).

Site-ul ghidul github în acest sens recomandă utilizarea unui instrument extern, dar eu prefer să-l folosesc pe cel încorporat.

În primul rând, faceți o copie de rezervă a depozitului dvs.. Apoi:

git filter-branch --force --index-filter 
'git rm --cached --ignore-unmatch PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA' 
--prune-empty --tag-name-filter cat -- --all

După aceasta, asigurați-vă că depozitul se află în starea dorită.. Este posibil să doriți să faceți o comparație cu copia de rezervă.

Dacă sunteți sigur că este corect, atunci:

#get rid of old unreferenced commits (including the data you want to remove)
git gc --prune=now
git push origin --force --all

S-ar putea să doriți să păstrați copia de rezervă locală pentru o vreme, pentru orice eventualitate.

Comentarii

  • Related: stackoverflow.com/questions/872565/… Cred că această metodă nu este suficientă, datele sunt încă accesibile prin intermediul confirmării. –  > Por Ciro Santilli新疆棉花TRUMP BAN BAD.
Kent Aguilar

Rulați această comandă pe terminal.

git reset HEAD~n

Puteți elimina ultimele n comenzi din repo-ul local, de exemplu, HEAD~2. Continuați cu force git push pe depozitul dvs.

git push -f origin <branch>

Sper că vă ajută!

Carlos Mafla

Pentru a păstra structura de ramificare și fuziune este important să utilizați --preserve-merges atunci când faceți rebase:

git rebase --preserve-merges -i HEAD^^

user456814

Comentarii

  • Notă: nu este recomandat să folosiți --preserve-merges și --interactive împreună. Consultați opțiunea secțiunea BUGS privind rebase –  > Por galath.
M_R_K

Pentru GitHub

  • Resetează-ți comenzile (HARD) în depozitul tău local
  • Creați o nouă ramură
  • Împingeți noua ramură
  • Ștergeți ramura OLD (Faceți-o pe cea nouă ca ramură implicită dacă ștergeți ramura master)

Деян Добромиров

Salvați mai întâi modificările locale undeva în lateral ( backup )

Puteți răsfoi comenzile dvs. recente, apoi selectați un hash de confirmare făcând clic pe butonul „Copy the full SHA” pentru a-l trimite în clipboard.

Dacă ultimul dvs. hash de confirmare este, să spunem g0834hg304gh3084gh ( de exemplu )

Trebuie să rulați:

git push origin +g0834hg304gh3084gh:master

Folosind hash-ul pe care l-ați copiat mai devreme pentru a face din el revizuirea „HEAD”.

Adăugați modificările locale dorite. Gata 😉

Mohideen bin Mohammed

dacă doriți să eliminați, faceți rebase interactiv,

git rebase -i HEAD~4

4 represents total number of commits to display count your commit andmodificați-o în consecință

și ștergeți commit-ul pe care îl doriți din listă…

salvați modificările prin Ctrl+X(ubuntu) sau :wq(centos)

A doua metodă, faceți revert,

git revert 29f4a2 #your commit ID

acest lucru va inversa o anumită confirmare

Keith

În GitHub Desktop puteți face clic dreapta pe confirmare și să o anulați, ceea ce va crea o nouă confirmare care va anula modificările.

Trimiterea accidentală va fi în continuare în istoricul tău (ceea ce poate fi o problemă dacă, de exemplu, ai trimis din greșeală o cheie API sau o parolă), dar codul va fi anulat.

Aceasta este cea mai simplă și mai ușoară opțiune, răspunsul acceptat este mai cuprinzător.

Comentarii

  • Am văzut că acest lucru cauzează probleme cu git flow. Exemplu, ați fuzionat accidental develop în master pentru o caracteristică care nu a fost încă lansată. Dacă pur și simplu inversați acea fuziune, atunci când fuzionați din nou master în develop, caracteristica va fi eliminată de acolo. –  > Por pumpkinthehead.
vivek_ganesan

Nu este foarte bine să rescrieți istoricul. Dacă folosim git revert <commit_id>, , se creează un reverse-commit curat al id-ului de commit menționat.

În acest fel, istoricul nu este rescris, în schimb, toată lumea știe că a existat o revenire.

Comentarii

  • Acest răspuns mai vechi îi spune deja utilizatorului git revert. – utilizator456814
  • Asta nu îndeplinește această cerință: „Vreau să revin la depozitul meu GitHub așa cum era înainte de această confirmare” –  > Por Steve Bennett.
Chirag Thakar

Adăugați/eliminați fișiere pentru a obține lucrurile așa cum doriți:

git rm classdir
git add sourcedir

Apoi modificați confirmarea:

git commit --amend

Confirmarea anterioară, eronată, va fi editată pentru a reflecta noua stare a indexului – cu alte cuvinte, va fi ca și cum nu ați fi făcut niciodată greșeala de la început

Rețineți că ar trebui să faceți acest lucru numai dacă nu ați făcut încă push. Dacă ați făcut-o, atunci va trebui să trimiteți o corecție în mod normal.

Comentarii

  • Acest lucru va crea o revizuire suplimentară … fără modificări…  > Por Деян Добромиров.