Git reset vs git revert: quale usare? Che differenza c’è fra i due? In questo articolo scoprirai quale usare a seconda delle tue necessità e soprattutto, ti guiderò a capire le differenze fra i due!
Tra le varie cose messe a disposizione da git non possiamo non menzionare due comandi atti ad alterare la storia del tuo repository in “negativo”. Dunque a cancellare o comunque annullare le modifiche all’interno dello stesso.
Entrambi i comandi di cui sto parlando offrono due approcci diversi e dunque insomma la domanda è: quale usare fra “git reset” e “git revert”? Che differenze ci sono fra i due? Ci arriviamo un passo per volta, ma prima è giusto presentarsi!
Mi chiamo Lorenzo Neri e sono un informatico: articoli come quello che stai leggendo derivano dalle mie esperienze in campo professionale che ho deciso di condividere e mettere Neri su bianco all’interno di questo blog. Quale modo migliore se non offrire una soluzione ad un problema che ho avuto e magari stai avendo proprio tu che mi stai leggendo?
Iniziamo!
Git reset vs git revert: che differenze ci sono fra i due?
Partiamo dalle differenze sostanziali fra i due comandi: perchè è importante partire da esse, ma è giusto farlo con un esempio terra-terra.
Partiamo da una situazione come questa:
Un repository tanto semplice quanto snello: in sintesi ho aggiunto una seconda riga ad un file nominato “file1.txt” e fin qua nulla di strano, se non fosse che ad un certo punto, mi viene fatto presente che quella riga non è necessaria.
Allora l’opzione a cui penseresti pure tu è: “Beh, annulliamo gli effetti del commit: eliminiamolo!”.
Giusto, di fatto, quello che possiamo fare è sfruttare il comando “git reset“ con un piccolo flag al fine di eliminare il commit:
git reset --hard HEAD^
L’effetto è il seguente: la seconda riga dal file non sarà più lì, ma non ci sarà più nemmeno il commit nella storia:
Come vedi, è sparito tutto.
Capiamo dunque che “git reset” elimina dalla storia.
Ripristiniamo la situazione di prima, dunque ci troviamo di nuovo con entrambi i commit ed entrambe le righe all’interno del “file1.txt”.
Ci sarà mai il modo di togliere quella seconda riga dal file senza far fuori il commit?
Eh già, si può.
Come? A dir poco così:
git revert HEAD
Noterai che l’output a terminale di git sarà il seguente:
[master df939f0] Revert "aggiungo seconda riga"
1 file changed, 1 deletion(-)
Tuttavia, come ti avevo promesso prima, la storia del repository, un po’ come la categoria del blog legata a git, non si restringe. No, viene preservata ed allungata:
Come vedi, la prima differenza fra “git reset” e “git revert” è che i commit non vengono eliminati, ma ciò che viene eliminato sono gli effetti del commit su cui agisce il revert: non per nulla io gli ho detto di agire su HEAD ma potevo inserirgli anche l’hash del commit.
La sintesi sulla differenza fra questi due comandi, è che anziché eliminare il commit di cui si vogliono annullare gli effetti, ne viene creato uno a seguito del punto corrente della storia che riporta la situazione della codebase al commit desiderato.
Capita la differenza sostanziale… Ce l’avranno qualcosa in comune?
I punti in comune quali sono?
Usati a livello di commit, il punto comune fra i due comandi è eliminare le modifiche effettuate sui file all’interno del repository.
Fine, niente di trascendentale.
Di fatto se mai andassi dentro i file di quel repo ti posso giurare su ciò che vuoi che la seconda riga nel file non c’è, davvero!
Ma… In tutto questo, forse forse ti starai ancora chiedendo…
Quando usare git reset e quando usare git revert?
Se gli effetti sono simili, quale mai sarà il senso di usare “git revert” piuttosto che usare “git reset”?
Abbiamo capito come agiscono a livello di storia, questo penso sia chiaro (se così non fosse, i commenti sono laggiù apposta!), ma quale mai sarebbe il senso di annullare una modifica ma preservarne la presenza a livello di storia?
Metti caso che fra 45 anni torni a lavorare su questa codebase: sì, so che forse non succederà, ma mettiamo caso!
Ad un certo punto ti rendi conto che sì, hai eliminato quella benedetta seconda riga da quel file, solo che… Non c’è traccia di commit che ne giustifichi l’eliminazione.
Dunque perdi traccia integralmente dell’eliminazione, mentre ciò che fa “git revert” è sì applicare le eliminazioni, ma le preserva a livello di storia.
Delle volte, può tornare comodo a posteriori capire perché c’è stata un’eliminazione e dunque tenerne traccia in questo modo.
