Strumenti del professionista e risoluzione dei problemi

Finora abbiamo considerato lo scenario ideale: scrivi codice, fai commit, crei un Pull Request. Ma nella vita reale spesso qualcosa va storto: puoi fare un errore nel codice, fare un commit con un messaggio sbagliato o semplicemente renderti conto che stai andando nella direzione sbagliata. In questa lezione vedremo come risolvere i problemi più comuni.

1. Rollback — annullare le modifiche prima del commit

Scenario: hai modificato un file, ma capisci che tutte le tue correzioni sono sbagliate e vuoi tornare rapidamente al file come era dopo l'ultimo commit.

Usa la funzione Rollback:

1. Apri la scheda Commit.
2. Trova nella lista il file modificato che vuoi "rollbackare".
3. Fai clic con il tasto destro su di esso e seleziona Rollback.

L'IDE ti avvertirà che le modifiche andranno perse. Conferma, e il file tornerà istantaneamente alla versione salvata più recente in Git. Questo è il modo più semplice e sicuro per annullare modifiche locali.

2. Reset — rimuovere commit locali

Scenario: hai fatto uno o più commit, ma non hai ancora fatto push. Ti rendi conto che quei commit sono sbagliati e vuoi rimuoverli completamente, come se non fossero mai esistiti.

Usa la funzione Reset:

1. Apri la scheda Git -> Log per vedere la cronologia dei commit.
2. Trova l'ultimo commit "buono" su cui vuoi tornare (quello che era prima degli errati).
3. Fai clic con il tasto destro su di esso e seleziona Reset Current Branch to Here....

Nella finestra aperta 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, oltre a tutte le modifiche nel codice presenti in quei commit. Usala con grande cautela e solo per commit che nessuno ha ancora visto (cioè non sono stati inviati su GitHub).

3. Che fare dopo il Push?

Scenario: hai fatto push e solo dopo ti accorgi di un errore.

Non appena un commit arriva sul server remoto, diventa parte della storia condivisa del progetto. Tentare di riscrivere questa storia può creare grossi problemi ai colleghi. Immagina che abbiano già scaricato le tue modifiche e iniziato a lavorare su di esse.

Soluzione corretta e sicura:

Fai semplicemente un nuovo commit che corregga l'errore e invialo. È una pratica assolutamente normale. In questo modo la cronologia resta onesta e comprensibile per tutti.

4. Guardare indietro: lavoro avanzato con il log

Conosciamo già la scheda Git -> Log, ma non è solo una lista di commit, è uno strumento potente per investigazioni.

• Hash del commit (Commit Hash): avrai notato nella log una stringa di lettere e numeri, per esempio a1b2c3d. Questo hash è unico e permette di riferirsi con precisione a qualsiasi punto della storia del progetto. Raramente dovrai usarlo manualmente, ma è importante sapere che è l'identificatore unico di ogni "snapshot" del codice.
• Puoi filtrare la cronologia per branch, autore, data o anche per una 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 specifica riga di codice? Nella finestra Log c'è un campo di ricerca che cerca non solo nei messaggi, ma anche nel contenuto delle modifiche.
• Fai clic con il tasto destro sulle aree dell'editor di codice e seleziona Annotate with Git Blame. L'IDE mostrerà accanto a ogni riga chi l'ha modificata l'ultima volta e in quale commit. È estremamente utile per capire perché il codice è scritto in quel modo.

5. Zona pericolosa: Force Push

Quindi, abbiamo stabilito che modificare commit già inviati è una cattiva idea. Ma cosa succede se hai comunque riscritto la tua storia locale (per esempio con Reset) e ora è divergente dalla storia sul server? Cercando di fare un normale push, Git ti darà un errore per proteggere la storia condivisa da riscritture.

Per questi casi esiste l'opzione — force push (invio forzato). Questo comando dice al server: "Dimentica tutto ciò che avevi. La mia versione locale della storia è l'unica corretta. Sostituisci la tua storia con la mia".

ATTENZIONE! Nel 99% dei casi usare il force push nei progetti di squadra è una catastrofe. Può cancellare in modo irreversibile commit che i colleghi hanno già scaricato e su cui stanno lavorando. È come strappare pagine da un libro condiviso in biblioteca e incollarne di tue.

Quando è assolutamente vietato usare il force push:

• Su qualsiasi branch condiviso: main, develop, master. Mai.
• Su qualsiasi branch su cui lavora qualcun altro oltre a te.

L'unico scenario accettabile:

Stai lavorando sulla tua feature-branch personale, che nessuno ha ancora visto o usato. Hai fatto qualche commit "sporco", li hai inviati al server, e poi hai deciso di "ripulirli" con Reset. In questo caso puoi fare un force push per aggiornare la tua branch sul server prima di aprire il Pull Request.

Nell'IDE questa opzione di solito è nascosta dietro il pulsante Push. Gli sviluppatori delle IDE lo fanno apposta per evitare click accidentali.

Se non sei sicuro al 100% di quello che stai facendo — non usare mai il 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 un nuovo task. Questo ti salverà da molti futuri conflitti di merge e garantirà che inizi a lavorare con la versione di codice più aggiornata.