Aggiungere un file alla staging area di Git

Nella lezione precedente abbiamo inizializzato la nostra directory di Git con il comando git init. Ora è giunto il momento di creare qualche file e iniziare a salvare le modifiche dalla git directory alla staging area.

Perché non nella git directory? Il concetto di salvataggio in Git differisce da quello alla quale comunemente pensiamo quando si parla di "salvare un file".

In Git il salvataggio è associato al termine commit, che vedremo meglio nella prossima lezione. Tra l’altro commit non è nemmeno l’unico meccanismo di salvataggio di Git, perché esiste anche stash, un’area dove i cambiamenti non ancora pronti per essere salvati possono essere memorizzati temporaneamente. Ne parleremo, anche in questo caso, più avanti. Andiamo per gradi.

Per fare la commit è necessario fare un altro passaggio prima e cioè includere i file da salvare nella staging area. In questo modo gli diremo quali file o directory siamo intenzionati a salvare con il comando di commit. Il comando per “promuovere” i file e le directory è:

1$ git add [<file>,<directory>]

Eseguendo il comando i file o le directory indicati saranno aggiunti alla staging area e saranno pronti per essere salvati nel database di versionamento.

Tutto qui? Beh di base sì, ma che lezione di Manuel sarebbe senza un ulteriore approfondimento?

Patch dei file con git add

Una flag (o parametro) del comando git add che mi ha sempre in qualche modo affascinato è -p o --patch. Quello che ci permette di fare questo parametro è di vedere le modifiche che sono state fatte e decidere se eventualmente mettere in staging area solo una parte.

Sotto al cofano patch è una scorciatoia che ci fa andare direttamente all’opzione patch della modalità interattiva (attivabile usando il flag -i o --interactive).

Ci verranno mostrati quindi uno o più hunk (o chunk, o pezzi) sulla quale possiamo scegliere tra varie opzioni, nello specifico:

• y: inserisce nella staging area la modifica
• n: non inserisce nella staging area la modifica
• q: esce dalla modalità interattiva senza aggiungere niente alla staging area
• a: mette in staging la modifica e tutte quelle successive
• d: non mette in staging la modifica e tutte quelle successive
• e: modifica manualmente il pezzo corrente
• s: separa le modifiche in pezzi più piccoli
• g: vai ad un hunk specifico
• /: cerca un hunk specifico attraverso l’uso di espressioni regolari
• j: lascia il pezzo come “indeciso”, vai al prossimo “indeciso”
• J: lascia il pezzo come “indeciso”, vai al prossimo hunk
• k: lascia il pezzo come “indeciso”, vai al precedente “indeciso”
• K: lascia il pezzo come “indeciso”, vai al precedente hunk
• ?: vi mostra la descrizione delle lettere se vi dimenticate

Le opzioni non vengono visualizzate tutte insieme, dipende da cosa avete da salvare nella staging area.

Se si sceglie e (equivalente di git add -e) si potrà modificare manualmente il pezzo corrente e qui le regole di modifiche sono molto semplici:

• Rimuovendo "-" sostituendolo con uno spazio si eviterà che la linea venga rimossa
• Rimuovendo le linee con il "+" si eviterà l’aggiunta
• Le linee con il # verranno rimosse.

Se le modifiche fatte saranno corrette il pezzo verrà immediatamente inserito in staging area, altrimenti potrete editarlo di nuovo.

Altre flag interessanti

Oltre a patch, ci sono altre flag interessanti da sperimentare, tra queste troviamo:

• -v (--verbose): il comando mostrerà più informazioni rispetto alle attività che sta svolgendo o ha svolto.
• -f (--force): permette di inserire in staging area file altrimenti ignorati
• -i (--interactive): attiva la modalità interattiva dove è possibile:
  • Vedere le modifiche tra HEAD e l’indice (ciò che verrà salvato se faremo git commit)
  • Selezionare le modifiche e inserirle nella staging area
  • Riporta il file alla sua versione nella HEAD. I file alla quale è stato aggiunto un indice ritornano untracked
  • Aggiungere tutti i file untracked
  • Modificare, mettere in staging ed ispezionare i pezzi di codice modificati (uguale a fare -p)
  • Vedere ciò che verrà salvato
• -e (--edit): menzionato prima, apre l’editor e permette di modificare le differenze con l’indice

Conclusioni

Ora che il file è nella staging area è pronto per la commit (vi prego non dite mai "pronto per essere committato", mi ferite). Nella prossima lezione vedremo meglio questo nuovo interessante comando.