Ecco tutti i comandi di Git che ho usato nell'ultima settimana, e cosa fanno.

Articolo originale: Here are all the Git commands I used last week, and what they do.

by Sam Corcos

Come molti principianti, ho iniziato cercando comandi Git su StackOverflow e copia-incollando risposte senza davvero capire cosa facessero.

Ricordo di aver pensato, "Non sarebbe simpatico se ci fosse una lista dei comandi Git più comuni con la spiegazione di a cosa servono?"

Beh, eccomi anni dopo che compilo io una tale lista, e metto per iscritto alcune delle pratiche migliori che perfino sviluppatori ad un livello intermedio-avanzato dovrebbero trovare utili.

Per tenere le cose pratiche, sto basando questa lista sui comandi che ho usato questa ultima settimana.

Quasi tutti gli sviluppatori usano Git, e abbastanza probabilmente GitHub. Ma lo sviluppatore medio probabilmente usa solo questi tre comandi il 99% delle volte:

git add --all
git commit -am "<messaggio>"
git push origin master

E questo va bene finché stai lavorando in un team di una persona sola, un hackathon, o una app di prova, ma quando la stabilità e la manutenzione iniziano a diventare una priorità, pulire i commit, avere una strategia di branching, e scrivere messaggi di commit coerenti diventa importante.

Inizierò con una lista dei comandi più usati per rendere più facile capire ai principianti cosa è possibile con Git, poi passerò a funzionalità più avanzare e migliori pratiche.

Comandi usati regolarmente

Per inizializzare Git in un repository (repo), devi solo eseguire il seguente comando. Se non inizializzi Git, non puoi usare altri comandi Git nel repo.

git init

Se stai usando GitHub e stai facendo push del codice a un repo GitHub salvato online, stai usando un repo remoto. Il nome di default (noto anche come alias) per un repo remoto è origin. Se hai copiato un progetto da GitHub, ha già un origin. Puoi vedere quell'origine con il comando git remote -v che mostrerà l'URL del repo remoto.

Se hai inizializzato il tuo repo Git e vuoi associarlo a un repo su GitHub, dovrai crearne uno su GitHub, copiare l'URL dato, e usare il comando git remote add origin <URL>, con l'URL dato che sostituisce "<URL>". Dopo questo, puoi usare i comandi add, commit e push per il tuo repo remoto.

L'ultimo è usato per quando devi cambiare il repo remoto. Diciamo che hai copiato un repo da qualcun altro e vuoi cambiare il repo remoto da quello originale al tuo account GitHub. Segui lo stesso processo di git remote add origin, tranne che devi usare set-url per cambiare il repo remoto.

git remote -v
git remote add origin <url>
git remote set-url origin <url>

Il modo più comune per copiare un repo è usare git clone, seguito dall'URL del repo.

Tieni a mente che il repo remoto sarà legato all'account da cui hai clonato il repo. Quindi se cloni un repo che è di qualcun altro non sarai in grado di fare push a GitHub fino a che non cambi origin usando il comando sopra.

git clone <url>

Ti ritroverai in fretta a usare rami, o branch. Se non capisci cosa sono i branch ci sono altri tutorial che sono molto più approfonditi, e dovresti leggere quelli prima di procedere (eccone uno).

Il comando git branch elenca tutti i branch sulla tua macchina locale. Se vuoi creare un nuovo branch, puoi usare git branch <nome> con <nome> che rappresenta il nome del branch, ad esempio "master".

Il comando git checkout <nome> ti sposta a un branch esistente. Puoi anche usare git checkout -b <nome> per creare un nuovo branch e immediatamente spostarti a quello. La maggior parte delle persone usano quest'ultimo invece di comandi separati per creare il branch e poi muoversi su di esso.

git branch

git branch <nome>
git checkout <nome>

git checkout -b <nome>

Se hai fatto un sacco di cambiamenti a un branch, diciamo che si chiama "develop", e vuoi unire quel branch al tuo branch principale, usi il comando git merge <branch>. Devi spostarti prima sul branch principale con checkout, poi usi il comando git merge develop per unire il branch develop con il tuo branch principale.

git merge <branch>

Se stai lavorando con più persone, ti troverai nella situazione in cui un repo è stato aggiornato su GitHub, ma non hai quei cambiamenti localmente. Se questo è il caso, puoi usare git pull origin <branch> per recuperare i cambiamenti più recenti dal branch remoto.

git pull origin <branch>

Se sei curioso di vedere quali file sono stati cambiati e cosa sta venendo tracciato, puoi usare git status. Se vuoi vedere quanto ogni file è stato cambiato, puoi usare git diff per vedere il numero di righe cambiate in ogni file.

git status
git diff --stat

Comandi avanzati e pratiche migliori

Presto raggiungi un punto in cui vuoi che i tuoi commit siano carini e consistenti. Potresti anche voler fare un po' di cambiamenti alla tua storia dei commit per rendere i tuoi commit più facili da capire o invertire un cambiamento che ha accidentalmente fatto smettere di funzionare qualcosa.

Il comando git log ti fa vedere la tua storia dei commit. Vorrai usare questo per vedere la storia dei tuoi commit.

I tuoi commit hanno un messaggio e un hash, che è una serie casuale di numeri e lettere. Un esempio di hash potrebbe essere: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Diciamo che hai fatto push di qualcosa che ha fatto smettere di funzionare la tua app. Invece di sistemarlo e fare un nuovo push, faresti meglio ad andare indietro di un commit e provare di nuovo.

Se vuoi andare indietro nel tempo e fare checkout della tua app da un commit precedente, puoi farlo usando l'hash come nome del branch. Questo distacca la tua app dalla versione corrente (perché stai facendo modifiche da un record della storia, invece che dalla versione corrente).

git checkout c3d88eaa1aa4e4d5f

Poi, se vuoi fare cambiamenti dal branch storico e vuoi fare di nuovo push, dovrai fare un push a forza.

Attenzione: fare push a forza è pericoloso e dovrebbe essere fatto solo se assolutamente necessario. Riscrive la storia della tua app e perdi tutto quello che è accaduto dopo.

git push -f origin master

A volte non è pratico tenere tutto in un commit. Potresti voler salvare i tuoi progressi prima di provare qualcosa di potenzialmente rischioso, o forse hai fatto un errore e vuoi risparmiarti l'imbarazzo di avere un errore nella storia di versione. Per quello, abbiamo git rebase.

Diciamo che hai 4 commit nella tua storia locale (non in remoto) in cui hai fatto avanti e indietro. I tuoi commit appaiono trascurati e indecisivi. Puoi fare rebase per combinare tutti i commit in un singolo commit più conciso.

git rebase -i HEAD~4

Il comando sopra aprirà l'editor di codice di default del tuo computer (che è Vim a meno che tu non lo abbia cambiato), con varie opzioni per come puoi cambiare i tuoi commit. Apparirà tipo il codice sotto:

pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message

Per combinare questi, dovrai cambiare "pick" in "fixup" (come dice la documentazione sotto il codice) per unire i commit e scartare i messaggi di commit. Nota che in vim, devi premere a o i per essere in grado di modificare il testo, e per salvare e uscire devi usare esc seguito da shift + z + z. Non chiedermi perché, è fatto così.

pick 130deo9 oldest commit message
fixup 4209fei second oldest commit message
fixup 4390gne third oldest commit message
fixup bmo0dne newest commit message

Questo unirà tutti i con il messaggio "oldest commit message".

Il prossimo step è cambiare il tuo messaggio di commit. Questo step è del tutto una questione di opinioni, ma finché segui uno schema coerente, qualsiasi cosa decidi di fare va bene. Suggerisco di usare la guida per i commit pubblicata da Google per Angular.js.

Usa il flag amend per cambiare il messaggio del commit.

git commit --amend

Questo pure aprirà vim, e le regole per modificare il testo e salvare sono le stesse di sopra. Per dare un esempio di un buon messaggio di commit eccone uno che segue le regole della guida:

feat: add stripe checkout button to payments page

- add stripe checkout button
- write tests for checkout

Un vantaggio di usare i type elencati nella guida è che permette di scrivere i log dei cambiamenti (change log) più facile. Puoi pure includere informazioni nel footer (ancora, specificato nelle linee guida) che fa riferimento ad un issue.

Nota: dovresti evitare di fare rebase e squash dei tuoi commit se stai collaborando ad un progetto e fai push del tuo codice su GitHub. Se inizi a cambiare la storia della versione sotto il naso delle persone potresti rendere la vita di tutti più difficle con bug che sono difficili da trovare.

C'è un numero quasi infinito di comandi possibili con Git, ma questi comando sono probabilmente i soli che avrai bisogno di conoscere per i tuoi primi anni da programmatore.

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.