Similmente al precedente, il comando git reset in Git permette di annullare commit di un repository, ma lo fa in maniera distruttiva. In particolare, git reset può operare sulla history dei commit, quindi permette di alterare la history di un determinato branch. È un comando da usare con attenzione se non si vuole perdere parte del proprio lavoro.
Infatti, il comando è descritto ufficialmente come git-reset – Reset current HEAD to the specified state e in base all’effettivo utilizzo permette di effettuare il “reset” di diverse situazioni. Infatti, oltre che sulla history dei commit, ha effetto anche sulla staging area e sulla working directory a seconda della modalità con cui viene eseguito (soft, mixed o hard).
La versione estesa del comando è la seguente:
git reset [--soft|--mixed|--hard] [<REFERENCE>]
in particolare, se non indicati, viene usata di default la modalità mixed e viene usata la HEAD attuale come reference.
Le tre modalità differiscono nel seguente modo:
- soft – non tocca le modifiche in staging area, non tocca le modifiche nella working directory
- mixed – togliere le modifiche dalla staging aree e le riporta nella working directory, non tocca le altre eventuali modifiche nella working directory
- hard – annulla le modifiche in staging area, annulla le modifiche in working directory (cioè rimuove per sempre ogni modifica non salvata come commit)
$ git log --oneline * 517c168 (HEAD -> master) Revert "improve performance on first feature" * 1e6ed4a add second feature * cc7f96f improve performance on first feature * 1e1bf33 add first feature * f6a76e4 initialize project $ git add second.py $ git status --short M first.py M second.py
Se supponiamo che il nostro repository ha una certa history e che abbiamo alcune modifiche in corso, sia nella working directory che nella staging area, e che non siamo in uno stato “detached”, indicando solo la modalità avremmo come risultato che:
- soft -> praticamente invariato
- mixed -> pulisce la staging area
- hard -> rimuove tutte le modifiche e torna allineato con HEAD
Se però indicassimo come reference a cui fare reset uno dei commit:
$ git reset --hard cc7f96f HEAD is now at cc7f96f improve performance on first feature $ git log --oneline cc7f96f (HEAD -> master) improve performance on first feature 1e1bf33 add first feature f6a76e4 initialize project $ git status --short ?? second.py
In questo caso, sono stati rimossi dalla history locale del branch tutti i commit successivi a quello indicato nel comando git reset. Il file second.py è tornato ad essere untracked, poiché non esisteva in quella versione del progetto. In pratica, siamo passati da questa situazione:
[a]<--[b]<--[c]<--[d]<--[e]::{main}
|
HEAD
a una situazione in cui i commit successivi a quello a cui si è fatto il reset non fanno più parte del branch:
[d]<--[e]
[a]<--[b]<--[c]::{main}
|
HEAD
A cosa può essere utile il comando git reset in Git?
In generale, è utile ad annullare modifiche locali che non sono mai state pubblicate su una origin condivisa. Rimuovere un commit da un repository su cui altri web developers possono aver continuato a sviluppare crea seri problemi alla collaborazione. I casi d’uso possibile possono, quindi, essere i seguenti:
- git reset –hard: rimuove ogni propria modifica e riporta la working directory in sync con l’ultimo commit
- git reset: “pulisce” la staging area, mantenendo ogni differenza con l’ultimo commit nella working directory
- git reset <FILE>: come sopra, ma solo per uno specifico file e non per tutte le modifiche
- git reset –hard <COMMIT>: nel caso in cui ci accorgessimo che a partire da un certo commit in poi, e solo nel caso in cui tali commit sono rimasti sul proprio clone locale, il lavoro è completamente da scartare senza remore, riporta il progetto a tale commit “buono”, buttando via il resto
