Finora abbiamo considerato lo scenario ideale: scrivi il codice, fai i commit, crei una Pull Request. Ma nella vita reale spesso qualcosa va storto: puoi commettere un errore nel codice, fare un commit con un messaggio errato o semplicemente renderti conto di aver preso una direzione sbagliata. In questa lezione vedremo come risolvere i problemi più comuni.
1. Rollback — annullamento delle modifiche prima del commit
Scenario: hai modificato un file, ma ti sei accorto che tutte le tue revisioni non sono corrette e vuoi riportare rapidamente il file allo stato in cui era dopo l’ultimo commit.
Usa la funzione Rollback:
- Apri la scheda
Commit. - Trova nell’elenco il file modificato che vuoi «ripristinare».
- Fai clic su di esso con il tasto destro e scegli
Rollback.
L’IDE ti avviserà che le modifiche andranno perse. Conferma, e il file tornerà immediatamente alla sua ultima versione salvata in Git. È il modo più semplice e sicuro per annullare le modifiche locali.
2. Reset — eliminazione dei commit locali
Scenario: hai fatto uno o più commit, ma non hai ancora eseguito il push. Hai capito che questi commit sono sbagliati e vuoi eliminarli completamente, come se non fossero mai esistiti.
Usa la funzione Reset:
- Apri la scheda
Git -> Logper vedere la cronologia dei commit. - Trova l’ultimo commit «buono» su cui vuoi tornare (quello che era prima di quelli errati).
- Fai clic su di esso con il tasto destro e scegli
Reset Current Branch to Here....
Nella finestra che si apre ti verrà chiesto di scegliere la modalità di reset. La più drastica — Hard.
Attenzione! La modalità Hard elimina in modo irreversibile tutti i commit successivi a quello selezionato, nonché tutte le modifiche nel codice contenute in quei commit. Usala con grande cautela e solo per commit che nessuno ha ancora visto (quelli che non sono stati inviati su GitHub).
3. Cosa fare dopo il push?
Scenario: hai fatto il push e solo dopo hai notato un errore.
Non appena un commit arriva sul server remoto, diventa parte della cronologia condivisa del progetto. Tentare di riscrivere questa cronologia può creare enormi problemi per i tuoi colleghi. Immagina che abbiano già scaricato le tue modifiche e iniziato a lavorare sulla loro base.
La soluzione corretta e sicura:
Semplicemente crea un nuovo commit che corregge l’errore e invialo. È una pratica assolutamente normale. In questo modo la cronologia rimane onesta e chiara per tutti.
4. Uno sguardo al passato: uso avanzato del log
Conosciamo già la scheda Git -> Log, ma non è solo un elenco di commit: è un potente strumento per le indagini.
- Hash del commit (Commit Hash): avrai sicuramente notato nel log una stringa di lettere e numeri, per esempio
a1b2c3d. Questo hash è univoco e permette di riferirsi con precisione a qualsiasi punto nella cronologia del progetto. Raramente dovrai usarlo manualmente, ma è importante sapere che è l’identificatore univoco di ogni «istantanea» del tuo codice.![]()
- Puoi filtrare la cronologia per branch, autore, data o anche per parola nel messaggio del commit. Questo aiuta a trovare rapidamente chi e quando ha lavorato su una parte specifica della funzionalità.
- Vuoi trovare il commit in cui è stata aggiunta o rimossa una riga specifica di codice? Nella finestra
Logc’è un campo di ricerca che cerca non solo nei messaggi, ma anche nel contenuto delle modifiche stesse. - Fai clic con il tasto destro nei margini dell’editor di codice e seleziona
Annotate with Git Blame. L’IDE mostrerà accanto a ogni riga chi e in quale commit l’ha modificata l’ultima volta. È incredibilmente utile per capire perché il codice è scritto proprio così.
5. Zona pericolosa: force push
Abbiamo stabilito che modificare i commit già inviati è una cattiva idea. Ma cosa succede se hai comunque modificato la tua cronologia locale (per esempio con Reset) e ora non coincide con la cronologia sul server? Quando provi a fare un normale push, Git restituirà un errore per proteggere la cronologia condivisa dalla riscrittura.
Per questi casi esiste l’opzione — force push (invio forzato). Questo comando dice al server: «Dimentica tutto quello che avevi. La mia versione locale della cronologia è l’unica corretta. Sostituisci la tua cronologia con la mia».
ATTENZIONE! Nel 99 % dei casi l’uso di force push nei progetti di team è una catastrofe. Può eliminare irreversibilmente commit che i tuoi colleghi hanno già scaricato e su cui stanno lavorando. È l’equivalente di strappare pagine da un libro di biblioteca condiviso e incollarci le proprie.
Quando è categoricamente VIETATO usare force push:
- Su qualsiasi branch condiviso:
main,develop,master. Mai. - Su qualsiasi branch su cui lavora qualcuno oltre a te.
L’unico scenario ammissibile:
Stai lavorando in una tua personale branch feature che nessuno ha ancora visto né usato. Hai fatto alcuni commit «sporchi», li hai inviati al server e poi hai deciso di «metterli in ordine» con Reset. In questo caso puoi fare un force push per aggiornare la tua branch sul server prima di creare la Pull Request.
Nell’IDE questa opzione è di solito nascosta dietro il pulsante Push. Gli sviluppatori dell’IDE l’hanno fatto intenzionalmente per evitare che tu la prema per sbaglio.
Se non sei sicuro al 100 %, non usare mai force push. È più sicuro creare un nuovo commit con le correzioni.
6. Aggiornare il progetto
Premi sempre Update Project sul branch main prima di iniziare a lavorare su una nuova attività. Questo ti eviterà molti futuri conflitti di merge e garantirà che tu inizi a lavorare con la versione più aggiornata del codice.
GO TO FULL VERSION