Git commits verwijderen

[Matthijz98]

Beste Tweakers.

Ik ben helemaal nieuw in het gebruik van github en git.
Na even rond geklooid te hebben heb ik nu een repo met 6 commits en twee branches (geen idee hoe dat zo is gekomen ).

Nu wil ik deze zo samenvoegen dat alleen de twee laatste(groene) blijven bestaan en de commits daar voor worden toegekend aan de op een laatsten.
Op het internet kwam ik heel veel info tegen over rebase en hard en soft reset maar snap het verschil nog niet helemaal. Misschien kan iemand mij uitleggen wat het verschil is tussen rebase en reset en hoe ik mijn probleem het best kan verhelpen.

Alvast bedankt Matthijz98

[NMe]

Waarom wil je dat? Wat maakt het uit als je wat meer historie hebt? Het eindresultaat is hetzelfde, je hebt alleen meer punten waar je naartoe zou kunnen restoren.

[Matthijz98]

NMe schreef op dinsdag 31 mei 2016 @ 11:55:
Waarom wil je dat? Wat maakt het uit als je wat meer historie hebt? Het eindresultaat is hetzelfde, je hebt alleen meer punten waar je naartoe zou kunnen restoren.

Omdat het het niet werkende punten zijn omdat de helft van de bestanden er niet bij zitten.

[Pizzalucht]

Matthijz98 schreef op dinsdag 31 mei 2016 @ 11:58:
[...]

Omdat het het niet werkende punten zijn omdat de helft van de bestanden er niet bij zitten.

Dan blijft zijn vraag nog steeds staan. Commit history zie ik gewoon als een lijst van gebeurtenissen in de code, dat de code ergens tussenin kapot is maakt niet uit.
Zolang je geen tag aanmaakt op die commits en vervolgens deployed is er niet zoveel aan de hand toch?

[NMe]

De enige echt valide reden om een commit terug te draaien die ik tot dusverre gezien heb is wanneer een merge misgelopen is en daardoor de huidige versie van de code gesloopt is. Dan is het inderdaad zinnig om de commit helemaal weg te halen. Een "kapotte" commit tussendoor is niet erg als die fouten inmiddels in dezelfde branch al gefixt zijn.

[ACM]

Er zijn meerdere voorkeuren rond git en de geschiedenis aanpassen...

Maar in master dingen wijzigen is niet enorm gebruikelijk.

Je feature-branch "opschonen voor je merged" wordt wel vrij vaak gedaan. Dat kan met interactive rebase (git rebase -i master vanuit je branch). Vervolgens kan je je commits daarin nog aanpassen of samen laten voegen (squash of ammend).
Let wel op dat je daarmee je history aanpast en ook je branch kan slopen. Als je dat voor het eerst doet is het wel slim om te zorgen dat je branch goed ergens 'veilig' staat. Bijvoorbeeld op een remote-omgeving, via een losse branch of domweg een kopie van je git-repository (ja, je kan het terughalen als je weet hoe het moet... maar een backup is makkelijker ).

De reacties hiervoor geven al aan dat dat er ook tegenstanders van deze methode zijn

Je master-branch aanpassen is een stuk lastiger en veel minder verstandig, maar in theorie kan je doen wat je wilt met git... uiteindelijk met een force push pas je dan ook je remote wel aan.

[raptorix]

Ik vind het hard verwijderen van commits in GIT ook een security flaw, juist op gebied van code wil je niet dat mensen zomaar commits kunnen verwijderen zonder dat dit zichtbaar is.Zelf enige maanden terug meegemaakt tijdens een hackaton, ik zie in mijn commit dat ik een file toegevoegd heb, een paar commits later is mijn file weg, maar nergens in de commits daartussen zie ik dat mijn file is verwijderd....

[Barryvdh]

raptorix schreef op dinsdag 31 mei 2016 @ 13:06:
Ik vind het hard verwijderen van commits in GIT ook een security flaw, juist op gebied van code wil je niet dat mensen zomaar commits kunnen verwijderen zonder dat dit zichtbaar is.Zelf enige maanden terug meegemaakt tijdens een hackaton, ik zie in mijn commit dat ik een file toegevoegd heb, een paar commits later is mijn file weg, maar nergens in de commits daartussen zie ik dat mijn file is verwijderd....

In Github kan je overigens force push uitschakelen, zodat het niet zomaar mogelijk is om commits te verwijderen met interactive rebase: https://github.com/blog/2...nd-required-status-checks

[ Voor 55% gewijzigd door Barryvdh op 31-05-2016 13:39 . Reden: Quote toegevoegd ]

[jeroen3]

Git is zo gemaakt dat je ook niet zomaar commits kan verwijderen, ze blijven achter als dangling commit tot git gc. Volgens mij moet je ook de gehele singly linked list herschrijven als je commits wil wissen, ook niet erg gewenst als je met remotes werkt.

Deze gozer legt precies uit hoe git onder water werkt. En waarom sommige dingen wel en niet kunnen.
YouTube: Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith
^{(Hij is van de github concurrent Atlassian, bekend van SourceTree)}

[ Voor 7% gewijzigd door jeroen3 op 31-05-2016 13:45 ]

[DJMaze]

Je kan je commits verwijderen:

1. Niet pushen naar remote
2. Local verwijderen
3. Pull remote

En voila, al je commits van na de push zijn foetsie!

[ Voor 4% gewijzigd door DJMaze op 31-05-2016 15:39 ]

[Hydra]

DJMaze schreef op dinsdag 31 mei 2016 @ 15:39:
Je kan je commits verwijderen:

1. Niet pushen naar remote
2. Local verwijderen
3. Pull remote

En voila, al je commits van na de push zijn foetsie!

Of je doet een hard reset naar de laatste goeie commit?

raptorix schreef op dinsdag 31 mei 2016 @ 13:06:
Ik vind het hard verwijderen van commits in GIT ook een security flaw

Wat bedoel je precies met hard verwijderen? Zelfs met een hard reset en force push staan die commits nog steeds in de reflog. De situatie die jij schetst, dat een file deleted is, moet je toch echt in de history terug kunnen vinden. Ik vermoed dat een teamgenoot van je gewoon een merge verknald heeft. De commit van jou voor die merge zou de file nog moeten hebben.

[ Voor 45% gewijzigd door Hydra op 31-05-2016 16:15 ]

[BCC]

NMe schreef op dinsdag 31 mei 2016 @ 12:04:
De enige echt valide reden om een commit terug te draaien die ik tot dusverre gezien

Wat ook nog wel eens voorkomt is dat iemand credentials incheckt die je ECHT eruit wil hebben.

[Ventieldopje]

Gewoon een hard reset doen en dan force pushen. Github heeft alleen standaard de master branch beveiligd tegen force pushes. Gitlab en Bitbucket (ook gratis) zijn daar wat flexibeler mee. Github begint aardig wat ouderdomskwaaltjes te vertonen vind ik

[gekkie]

raptorix schreef op dinsdag 31 mei 2016 @ 13:06:
Ik vind het hard verwijderen van commits in GIT ook een security flaw, juist op gebied van code wil je niet dat mensen zomaar commits kunnen verwijderen zonder dat dit zichtbaar is.Zelf enige maanden terug meegemaakt tijdens een hackaton, ik zie in mijn commit dat ik een file toegevoegd heb, een paar commits later is mijn file weg, maar nergens in de commits daartussen zie ik dat mijn file is verwijderd....

Uiteindelijk kun je toch niet wijzigen zonder dat de hashes veranderen?

Als iemand toegang heeft tot je tree kan hij in principe best je history wijzigen, dat is op zich toch geen security-flaw ? Hij had ook je hele repo kunnen deleten.

Het gaat erom dat het niet geheel ongezien en onverifieerbaar kan en dat kan bij mijn weten niet (behalve met een briljante sha1 collisions dan)

[Ventieldopje]

raptorix schreef op dinsdag 31 mei 2016 @ 13:06:
Ik vind het hard verwijderen van commits in GIT ook een security flaw, juist op gebied van code wil je niet dat mensen zomaar commits kunnen verwijderen zonder dat dit zichtbaar is.Zelf enige maanden terug meegemaakt tijdens een hackaton, ik zie in mijn commit dat ik een file toegevoegd heb, een paar commits later is mijn file weg, maar nergens in de commits daartussen zie ik dat mijn file is verwijderd....

Hoezo een security flaw? Je kan prima mensen rechten geven om bepaalde dingen te doen d.m.v. hooks. Als je een hard reset doet moet je force pushen, als je dat verbied is er niks aan de hand en kan dit niet optreden.

Als je doodleuk iedereen toegang geeft tot je repo is het wachten op problemen natuurlijk

[ACM]

Hydra schreef op dinsdag 31 mei 2016 @ 16:13:
Wat bedoel je precies met hard verwijderen? Zelfs met een hard reset en force push staan die commits nog steeds in de reflog. De situatie die jij schetst, dat een file deleted is, moet je toch echt in de history terug kunnen vinden. Ik vermoed dat een teamgenoot van je gewoon een merge verknald heeft. De commit van jou voor die merge zou de file nog moeten hebben.

De reflog is nou niet echt een parel van gebruiksvriendelijkheid... Git biedt best wat manieren om e.e.a. te verpesten of te laten verdwijnen uit de history. En het is ook - in mijn ervaring - vrij goed in dat transparant doen. Fast-forward merges, rebase's met conflicten die je oplost, interactive rebases, rebases op oude versies van branches (hoe stom het ook is om een pull of fetch te vergeten) die je dan force pushed (waar ze de obscure '--force-with-lease' vlag voor hebben verzonnen om te voorkomen).

En in theorie kan je veel van die scenario's terugdraaien via de reflog, maar dan moet je wel weten hoe dat werkt (en dat het bestaat).

Daarnaast kan git dingen ook nog wel meer mis doen, zo heb ik al een paar merges meegemaakt waarbij een file of directory gemoved werd en in een andere branch aanpassingen kreeg en dat git dat niet door had.

File-moves zijn geen handeling in git, dat is slechts een combinatie van een delete en een add die toevallig voldoende op elkaar lijken... Als je dat 'veilig' wil doen, moet je de move los committen van de eventuele changes.
Directories zijn uberhaupt geen entiteit in git, waardoor moves/renames daarvan niet bekend zijn. Iedere file heeft dan een eigen move.
Als er in een andere branch dan een nieuwe file bijkomt in die directory, dan zal die file doodleuk in de 'oude' directory blijven na de merge. En changes in files die ook gemoved zijn en later in een andere branch worden verwijderd zijn ook spannend (vziw ook geen conflict, want er zijn twee gelijke deletes en een change in een nieuwe file).
Bij svn leverde dat soort dingen dan meestal een tree-conflict op. Daar kon je ook niet altijd even makkelijk wat aan doen, maar je werd in ieder geval gewaarschuwd

Wat al dat soort dingen betreft is het niet zo gek als mensen dan wat voorzichtig met het aanpassen van de historie zijn

[paul_db]

Als je net begint met git, lees dan eerst eens rustig door de tutorial op https://www.atlassian.com/git/tutorials

Heel nuttig, en heel helder

[Ramon]

Ik denk dat het een slecht idee is om deze user - die klaarblijkelijk net met git bezig is - te leren hoe je commits moet verwijderen. Niet in het minst omdat ik zelf, als iemand die al sinds 2009 met git werkt, nog nooit een commit heb verwijderd. Het is dus niet iets wat je nodig hebt. Als je wijzigingen wil doen maak je gewoon een nieuwe changeset die je netjes weer commit.

[Caelorum]

Voor zijn situatie is het misschien niet nodig, maar zelf toch ook wel eens nodig gehad. Zonder dat ik het door had was een bestand ingechecked met behoorlijk gevoelige informatie. Dat brak ook de MDA die ik had getekend. Dat soort bestanden wil je ook niet in de historie terug zien. Die moeten gewoon totaal uit de repository verwijdert zijn en niet terug te halen zijn.
Met git is dat overigens kwestie van een minuut of 5, gelukkig.

[raptorix]

Ventieldopje schreef op dinsdag 31 mei 2016 @ 17:35:
[...]


Hoezo een security flaw? Je kan prima mensen rechten geven om bepaalde dingen te doen d.m.v. hooks. Als je een hard reset doet moet je force pushen, als je dat verbied is er niks aan de hand en kan dit niet optreden.

Als je doodleuk iedereen toegang geeft tot je repo is het wachten op problemen natuurlijk

Uiteraard, maar het gaat erom dat het niet zichtbaar is zoals dat met een revert wel het geval is.

[XWB]

Het komt zelden voor dat ik het moet doen maar dit is mijn werkwijze op de command line:

- git stash (indien je gewijzigde files hebt die je nog niet wil committen)
- git log (zoek de hash van de commit die net één entry voor de commit staat die je wil verwijderen)
- git rebase -i <hash> (tekstedtior zal openen, bijvoorbeeld vim)
- verwijder de regel met de commit die je weg wil hebben
- opslaan en sluiten (:wq in vim)
- git push -f origin (in geval van remote)
- git stash pop (om je laatste stash terug te halen)

[Ventieldopje]

raptorix schreef op woensdag 01 juni 2016 @ 15:13:
[...]

Uiteraard, maar het gaat erom dat het niet zichtbaar is zoals dat met een revert wel het geval is.

Daar zijn dus zoals hier beschreven goede redenen voor waarom sommige dingen wel gewist kunnen worden (zoals per ongeluk credentials inchecken). Om dat te voorkomen moet je je flow aanpassen en bijv. eerst automated tests draaien voordat het desastreuze gevolgen kan hebben, dit kun je dus afdwingen met hooks.

Dat het kan wil niet zeggen dat het altijd 'zomaar' kan (wat wel een security flaw zou zijn imho).