Abbiamo detto più volte che lo scopo principale di Git è quello di evitare la perdita in una modifica committata (cioè salvata nella history). D’altro canto Git è anche pensato per offrire il controllo più completo sul proprio workflow di sviluppo, ivi inclusa la possibilità di definire esattamente la history del proprio progetto.
Prendiamo,ad esempio, questa cronologia di commit di un repository:
$ git log --oneline 5dd0865 make variable names more clear 35dec0e increase version af75ac9 update indentation for checks from linter edb709f profile mostly works, missing phone number b2b95ad wip - unfinished 447cbfe (tag: v0.1.0) chore: release 0.1.0 67b2fd8 feat: implement login 66c8a99 feat: implement signup 8305e6c chore: init project
I commit successivi a quello con tag v0.1.0 sono stati fatti man mano che parti del lavoro venivano completate, per non perdere alcuni avanzamenti funzionanti. A distanza di mesi o anni, non tutti quei commit sarebbero interessanti da mantenere come “istantanea” del progetto.
Per situazioni come queste, Git offre dei comandi per poter riscrivere la history, rendendo però esplicito che l’uso di tali comandi può portare alla perdita di contenuto (anche se, in verità molto rara e molto raramente dovuta a Git stesso).
Git offre due possibili “ambiti” di riscrittura della history:
l’ultimo commit appena creato (tramite l’opzione –amend del comando git commit) oppure uno qualsiasi dei commit nella history (tramite il comando git amend)
Scopriamo come rendere la history d’esempio di sopra qualcosa di simile al seguente:
$ git log --oneline 9b23ede (tag: v0.2.0) chore: release 0.2.2 7a250a0 feat: implement profile page 447cbfe (tag: v0.1.0) chore: release 0.1.0 67b2fd8 feat: implement login 66c8a99 feat: implement signup 8305e6c chore: init project
Git commit –amend in Git
L’opzione –amend del comando git commit in Git è una scorciatoia che ci permette di unire nuove modifiche presenti nella staging area all’ultimo commit appena salvato.
In linea con la filosofia di Git, le nuove modifiche non vengono “aggiunte” al commit esistente, ma viene creato un nuovo commit che include tutte le modifiche.
[...] $ git commit -m "implement send email button" $ git log -n 2 --oneline cc7f96f (HEAD -> main) implement new feature a3478b1 fix a bug in old feature $ git add public/icons/send_email_button.png $ git commit --amend --no-edit $ git log -n 2 --oneline e34a234 (HEAD -> main) implement new feature a3478b1 fix a bug in old feature
Nella sequenza di comandi qui sopra è stato incluso un file all’ultimo commit effettuato. Il file da includere è stato aggiunto alla staging area (git add) e poi è stato eseguito git commit –amend. In questa situazione, in cui si è semplicemente dimenticato di includere un file in un commit (l’intero file o modifiche a file già sotto controllo di versione), è d’aiuto anche l’opzione –no-edit che istruisce Git a mantenere l’esistente messaggio di commit.
Notare l’output di git log prima e dopo dell’amend: l’id dell’ultimo commit è cambiato, per Git si tratta di una nuovo snapshot che sostituisce il precedente.
Se non si indica l’opzione –no-edit, il comando git commit –amend può anche essere utile per correggere eventuali errori o mancanza nel solo messaggio di commit.
