Padroneggiare Git Stage e Commit: I Tuoi Primi Cambiamenti

Padroneggiare le basi di Git stage e commit è il primo vero passo per usare Git con sicurezza. Lo staging ti permette di scegliere esattamente cosa includere nel prossimo snapshot, e il commit registra quello snapshot con un messaggio che i futuri lettori possano capire.

Se tratti ogni commit come una piccola unità di lavoro revisionabile, Git diventa molto più facile da usare. Puoi ispezionare le modifiche, separare modifiche non correlate e recuperare dagli errori senza panico.

Come Funziona l'Area di Staging

Git non committa automaticamente ogni file che modifichi. Separa il tuo lavoro nell'albero di lavoro, l'area di staging e la cronologia dei commit.

L'albero di lavoro è la cartella del tuo progetto. Questi sono i file che modifichi nel tuo editor.

L'area di staging è la lista di controllo di Git per il prossimo commit. Quando esegui git add, non stai ancora salvando la cronologia. Stai selezionando le modifiche per il prossimo commit.

La cronologia del repository è la sequenza di commit già registrati.

Inizia controllando lo stato:

git status

Git mostrerà i file non tracciati, i file modificati, le modifiche in staging e il tuo ramo corrente. Questo comando è sicuro da eseguire in qualsiasi momento e dovrebbe diventare un'abitudine.

Per mettere in staging un file nuovo o modificato:

git add README.md

Per mettere in staging tutte le modifiche nella directory corrente:

git add .

Questo comando è comodo, ma usalo con cautela. Può mettere in staging file non correlati, configurazioni locali o output generati se il tuo .gitignore è incompleto.

Per una revisione più sicura, ispeziona prima il diff:

git diff

Poi metti in staging solo ciò che appartiene insieme:

git add src/app.js
git add README.md

Dopo lo staging, controlla cosa verrà committato:

git diff --staged

Questo mostra esattamente lo snapshot in staging. Se qualcosa sembra sbagliato, correggilo prima di committare.

Fare il Tuo Primo Commit

Una volta che le modifiche giuste sono in staging, crea un commit:

git commit -m "Aggiungi README del progetto"

Il messaggio dovrebbe descrivere la modifica, non l'azione che hai compiuto. "Aggiungi README del progetto" è più utile di "modifiche" o "aggiorna file".

Un buon commit di solito ha uno scopo chiaro. Ad esempio, supponi di aggiornare uno script di deployment e anche di correggere un errore di battitura in una pagina di documentazione. Queste sono modifiche separate. Mettile in staging e committale separatamente:

git add scripts/deploy.sh
git commit -m "Aggiungi controllo di integrità del deployment"

git add docs/setup.md
git commit -m "Correggi errore di battitura nella guida di configurazione"

Questo rende la revisione più facile. Rende anche più facile il rollback se la modifica al deployment causa un problema ma la correzione della documentazione è ok.

Se esegui git commit senza -m, Git apre il tuo editor. Questo è utile quando hai bisogno di un messaggio più lungo:

Aggiungi controllo di integrità del deployment

Verifica l'endpoint del servizio prima di segnare il deployment come completato.
Questo aiuta a individuare avvii falliti prima nel processo di rilascio.

La prima riga dovrebbe essere breve e diretta. Il corpo può spiegare perché la modifica era necessaria o menzionare compromessi.

Per vedere i commit recenti:

git log --oneline -5

Questo ti dà una vista compatta della cronologia recente.

Mettere in Staging Parti di un File

A volte un file contiene più modifiche non correlate. Git può mettere in staging solo una parte di un file con la modalità patch:

git add -p src/config.js

Git mostra ogni blocco di modifica e chiede cosa fare. Le scelte comuni sono:

• y: metti in staging questo blocco.
• n: non mettere in staging questo blocco.
• s: dividi il blocco in pezzi più piccoli se possibile.
• q: esci dalla modalità patch.

Il patch staging è utile quando stai pulendo prima di un commit. Ad esempio, potresti avere un file in cui hai aggiunto una nuova impostazione di timeout e anche riformattato un commento. Metti in staging la modifica del timeout per un commit, poi metti in staging la pulizia del commento per un altro.

Se hai messo in staging qualcosa per errore, rimuovilo dallo staging senza scartare il tuo lavoro:

git restore --staged src/config.js

Il tuo file rimane modificato nell'albero di lavoro. Viene semplicemente rimosso dall'area di staging.

Se vuoi scartare le modifiche non in staging in un file, fai attenzione:

git restore src/config.js

Questo comando butta via le modifiche locali in quel file. Esegui prima git diff in modo da sapere cosa stai perdendo.

Per altri modelli di recupero, vedi come annullare gli errori di Git.

Igiene dei Commit per il Lavoro Quotidiano

I commit piccoli e mirati sono più facili da revisionare, testare e annullare. Rendono anche strumenti come git bisect più utili quando devi trovare dove è iniziato un bug.

Usa queste abitudini:

• Esegui git status prima dello staging.
• Revisiona git diff prima di git add.
• Revisiona git diff --staged prima di committare.
• Tieni le modifiche non correlate in commit separati.
• Scrivi messaggi che spiegano cosa è cambiato.
• Evita di committare file generati a meno che il progetto non li richieda.
• Non committare mai segreti, chiavi private o valori .env locali.

Un flusso di lavoro pratico potrebbe essere così:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Gestisci risposta di controllo di integrità mancante"
git status

Questa sequenza non è appariscente, ma cattura la maggior parte degli errori dei principianti. Sai cosa è cambiato, cosa è in staging, cosa è stato committato e cosa rimane.

Se il tuo team usa hook pre-commit o formattazione automatica, un commit potrebbe fallire finché non correggi la formattazione o i test. Leggi il messaggio di errore, esegui il comando suggerito, metti in staging le modifiche risultanti e committa di nuovo.

Quando Chiedere Aiuto

Chiedi aiuto se hai accidentalmente messo in staging o committato segreti, se hai committato sul ramo sbagliato, o se non sei sicuro se emendare, revertare, resettare o fare un nuovo commit. Queste scelte hanno effetti diversi, specialmente dopo un push.

Dovresti anche chiedere prima di riscrivere commit che altre persone potrebbero aver scaricato. Una semplice pulizia locale può trasformarsi in un problema di squadra se modifica la cronologia condivisa.

Lo staging e il commit sono il ciclo principale di Git. Revisiona le tue modifiche, metti in staging intenzionalmente, committa in pezzi mirati e scrivi messaggi che abbiano senso tra un mese.