Mentre lavori su un repository in Git, potresti avere necessità di estrarre uno specifico file da un branch e spostarlo in un altro branch (in gergo, eseguire il checkout di un file in un altro branch).

Fortunatamente, Git offre molti possibili modi per fare questa attività rapidamente. Una delle soluzioni più semplici è usare il comando git checkout con un file specifico come argomento.

In questo articolo, analizzeremo differenti soluzioni a questo problema e approfondiremo le procedura che dovrai seguire per ciascuna.

Partiamo! 😎.

Casi d'uso di git checkout

Stai lavorando su un branch, chiamato feature/A, contenente un file denominato utils.js.

Hai anche un altro branch, chiamato feature/B con un file aggiornato utils.js.

Vuoi effettuare il checkout di questo file e portarlo dal branch chiamato feature/B al branch chiamato feature/A.

Ci sono tre possibili soluzioni per questo compito.

Soluzione 1: Usare il comando git checkout

Il comando git checkout offre un modo semplice per prendere un file o una cartella da un altro branch.

Qui viene riportato il codice per eseguire il checkout di un file da un altro branch:

git checkout <nome-altro-branch> -- percorso/del/file/

Ecco la procedura da seguire:

1. Esegui il checkout del branch dove vuoi copiare il file.

git checkout feature/A

2. Una volta che sei nel branch corretto, copia il file.

git checkout feature/B -- utils.js

3. Usa il comando git status per assicurarti che il file sia stato copiato.

4. Esegui il commit e il push a un branch remoto.

Quando usi il comando checkout, puoi anche ottenere:

• Una cartella da un altro branch.
• File multipli specificando ciascuno di questi.

Inoltre, considera che puoi anche estrarre un file/cartella dallo stash.

Soluzione 2: Usa il comando git restore

Un'altra opzione è utilizzare il comando git switch insieme al comando git restore.

Se non hai mai sentito di questi due comandi, è tutto a posto. Sono relativamente nuovi. Git li ha introdotti nella versione 2.23 del 2019.

La funzione di questi due comandi è separare le responsabilità del comando git checkout per semplificarne l'utilizzo per gli utenti.

Il comando git restore ripristina l'albero di lavoro.

Il comando git switch passa da un branch all'altro.

Questa è la procedura da seguire per prendere un file da un altro branch:

1. Passa al branch dove vuoi inserire il file.

git switch feature/A

2. Prendi il file dall'altro branch.

git restore --source feature/B -- utils.js

3. Esegui il commit e il push dei cambiamenti.

Soluzione 3: Usa il comando git show

Per ultimo, possiamo usare il comando git show .

Qui è riportata la procedura da seguire:

1. Passa al branch di lavoro.

git switch feature/A

2. Prendi il file dall'altro branch

git show feature/B:path/utils.js > path/utils.js

3. Esegui il commit e il push dei cambiamenti.

Nota: questa volta devi specificare il percorso relativo dalla root della tua directory.

Considerazioni finali

Come puoi vedere, prendere un file da un altro branch non è così complicato.

Quando devo farlo nella mia vita di tutti i giorni, di solito uso il comando git checkout.

Visita il mio blog se sei interessato a scoprire di più su Git o sulle tecnologie usate nello sviluppo Web, come TypeScript.

Grazie per aver letto questo articolo.

Mentre realizzi un progetto, a volte potresti avere necessità di rinominare un branch locale. Ma come puoi farlo in Git?

In questo articolo, ti fornirò due metodi per rinominare i branch locali in Git.

Come rinominare un branch in Git – Metodo n° 1

Step 1: assicurati di essere nella cartella root del tuo progetto

Per prima cosa dovrai aprire il tuo terminale e quindi cambiare directory  (cd) nella cartella root del tuo progetto.

Per esempio, questo è come appare il comando se ti trovi nella tua home directory e vuoi spostarti nel progetto collocato nel Desktop.

cd Desktop/nome-progetto

Questo è un esempio di come spostarsi nella cartella di un progetto denominato Happy_Messages_Bot.

Step 2: vai sul Branch che vuoi rinominare

Puoi usare il comando git checkout per passare a un altro branch.

git checkout nome-branch

In questo esempio, voglio passare al branch denominato test-branch che ho creato.

Step 3: usa il flag -m per cambiare il nome al branch

Questo è la sintassi del comando per cambiare nome al branch:

git branch -m nuovo-nome-branch

In questo esempio, voglio cambiare il nome del mio branch da test-branch a test-branch2.

git branch -m test-branch2

Puoi usare git status per vedere il nuovo nome del branch.

Come rinominare un branch in Git – Metodo n° 2

Possiamo rinominare il branch locale con un solo comando senza dover usare git checkout.

Step 1: assicurati di trovarti sul branch master/main

Per controllare se ti trovi sul branch master/main, lancia git status:

Se non ti trovi sul branch master/main , allora devi lanciare git checkout master oppure git checkout main.

Step 2: usa il flag -m per cambiare il nome al Branch

Puoi usare questa sintassi per rinominare il branch esistente:.

git branch -m vecchio-nome nuovo-nome

Ecco come cambiare il nome di test-branch in test-branch2.

git branch -m test-branch test-branch2

Per vedere il nuovo nome del branch, puoi lanciare git branch, che mostrerà la lista di tutti i tuoi branch.

Questi appena esposti sono due metodi per rinominare dei branch locali in Git.

Cambiare branch è un'operazione di cui avrai bisogno spesso in Git.

Per farlo, puoi usare il comando git checkout.

Come creare un nuovo branch in Git

Per creare un nuovo branch in Git, puoi usare il comando git checkout e passare il flag -b seguito da un nome.

Questo creerà un nuovo branch partendo da quello corrente. La cronologia del nuovo branch inizierà con la posizione corrente del branch da cui hai lanciato il comando.

Assumendo di trovarsi sul branch chiamato master:

(master)$ git checkout -b my-feature
Switched to a new branch 'my-feature'
(my-feature)$

Qui puoi vedere un nuovo branch appena creato chiamato my-feature, che è stato generato come ramificazione a partire da master.

Come passare a un branch esistente in Git

Per passare a un branch esistente, puoi usare il comando git checkout (senza il flag  -b) e passare il nome del branch che vuoi raggiungere:

(my-feature)$ git checkout master
Switched to branch 'master'
(master)$

Esiste anche una pratica scorciatoia per ritornare al branch su cui ti trovavi precedentemente, passando - al comando git checkout invece del nome del branch:

(my-feature)$ git checkout -
Switched to branch 'master'
(master)$ git checkout -
Switched to branch 'my-feature'
(my-feature)$

Come eseguire il checkout di uno specifico commit

Per eseguire il checkout o passare ad un commit specifico, puoi anche usare  git checkout e passare come parametro lo SHA del commit invece del nome del branch.

Dopotutto, i branch sono effettivamente solo puntatori e rilevatori di specifici commit nella cronologia di Git.

Come trovare lo SHA di un commit

Un modo per trovare lo SHA di un commit è guardare nel log di Git.

Puoi visualizzare il log utilizzando il comando git log:

(my-feature)$ git log
commit 94ab1fe28727b7f8b683a0084e00a9ec808d6d39 (HEAD -> my-feature, master)
Author: John Mosesman <johnmosesman@gmail.com>
Date:   Mon Apr 12 10:31:11 2021 -0500

    This is the second commmit message.

commit 035a128d2e66eb9fe3032036b3415e60c728f692 (blah)
Author: John Mosesman <johnmosesman@gmail.com>
Date:   Mon Apr 12 10:31:05 2021 -0500

    This is the first commmit message.

Sulla prima riga di ciascun commit, dopo la parola commit si trova una lunga stringa di caratteri e di numeri: 94ab1fe28727...

Si tratta dello SHA, un identificatore unico che viene generato per ogni commit.

Per eseguire il checkout di un commit specifico, devi solo passare lo SHA del commit come parametro al comando git checkout:

(my-feature)$ git checkout 035a128d2e66eb9fe3032036b3415e60c728f692
Note: switching to '035a128d2e66eb9fe3032036b3415e60c728f692'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 035a128 a
((HEAD detached at 035a128))$

Nota: generalmente avrai bisogno di usare solo i primi caratteri dello SHA, poichè i primi quattro o cinque caratteri della stringa sono molto probabilmente unici in tutto il progetto.

Cosa vuol dire detached HEAD state?

Effettuare il checkout di uno specifico commit ti pone in un cosiddetto "detached HEAD state" (stato HEAD separato).

Dalla documentazione:

[detached HEAD state] significa semplicemente che HEAD si riferisce a uno specifico commit, invece che riferirsi a un branch con un nome.

Fondamentalmente, l'HEAD (uno dei puntatoti interni di Git che rileva dove ci si trova nella cronologia di Git) risulta separato dai branch conosciuti, così le modifiche, da questo punto, formeranno un nuovo percorso nella cronologia di Git.

Git vuole assicurarsi che questo stato HEAD separato sia quello che realmente vuoi ottenere, pertanto ti fornisce uno "spazio libero" per ogni sorta di modifica sperimentale - come descritto nell'output:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

Traduzione: "Sei in uno 'stato HEAD separato'. Puoi dare un'occhiata in giro, fare cambiamenti sperimentali e salvarli in commit, e puoi cancellare qualsiasi commit che hai fatto in questo stato, senza alcun impatto sui branch, tornando indietro su un branch esistente"

Da questo posizione hai due opzioni:

• Sperimentare e poi buttare via le tue modifiche tornato al branch precedente
• Lavorare da qui ed iniziare un nuovo branch da questo punto

Puoi usare il comando  git switch - per annullare qualsiasi modifica che hai apportato e tornare al tuo branch precedente.

Se invece vuoi mantenere i tuoi cambiamenti e continuare da qui, puoi usare il comando git switch -c <nome-nuovo-branch> per creare un nuovo branch da questo punto.

Conclusioni

Il comando git checkout è utile e ha molteplici usi.

Puoi usarlo per creare nuovi branch, spostarti su un branch, eseguire il checkout di uno specifico commit, e molto altro.

Se ti è piaciuto questo tutorial, parlo di argomenti come questi su Twitter e ne scrivo sul mio sito.

Il Branching (la ramificazione dello sviluppo di un progetto) è una parte essenziale di Git, in quanto ti permette di lavorare senza manomettere il codice già in produzione.

Quando finisci di lavorare con un branch diverso da main, vuoi unirlo con il ramo main con un commit di merge,  in modo che le nuove feature o i bug risolti che hai appena inserito diventino effettivi e possano essere mostrati.

Ma cosa succede se finisci di effettuare il merge e ti accorgi di aver dimenticato di fare una cosa? Oppure cosa succede se accidentalmente effettui il merge quando non sei ancora pronto?

Puoi annullare quasi qualsiasi azione in Git. Così, in questo articolo, ti mostrerò come annullare un merge in Git, in modo da ripristinare la situazione precedente all'ultimo commit che hai effettuato.

Come annullare un commit di merge in Git

Puoi usare il comando Git reset per annullare un merge.

Come prima cosa, è necessario controllare l'hash (o id) del commit, da usare per tornare al commit precedente.

Per controllare l'hash, usa il comando git log oppure git reflog. git reflog è una opzione migliore perché le informazioni sono più leggibili con questo comando.

Quando ottieni l'hash del commit a cui vuoi tornare, lancia git reset --hard commit-prima-del-merge:

Dovresti vedere alcuni elementi essere rimossi dal tuo editor di codice quando lanci il comando.

Se non sei sicuro dell'hash dell'ultimo commit, puoi lanciare il comando git reset --hard HEAD~1  per tornare al commit precedente al merge:

Nota che quando utilizzi il flag  --hard per annullare un merge, qualsiasi cambiamento non salvato in un commit viene annullato.

Un modo migliore per annullare un merge in Git

Dato che i metodi discussi precedentemente annullano le modifiche non salvate in un commit, Git fornisce un flag più sicuro, denominato  --merge.

Per annullare un merge con il flag  --merge, lancia  git reflog per vedere gli hash dei commit, quindi lancia  git reset --merge commit-precedente:

Si può anche usare la keyword HEAD con il flag  --merge lanciando git reset --merge HEAD~1:

N.B.: Se non ottieni una risposta da questo comando quando usi il flag  --merge, non preoccuparti, funziona.

Conclusione

In questo articolo, hai imparato come annullare un merge in Git, e adesso potrai annullare un merge non voluto o errato e lavorare in Git con maggiore efficienza.

Qui ci sono i punti principali da tenere a mente con i flag  --hard e --merge quando si usano per annullare un merge: il flag  --hard rimuove le modifiche non salvate in un commit, mentre il flag  --merge mantiene le modifiche non salvate in un commit.

Grazie per aver letto questo articolo!

Molti di noi usano git quotidianamente. Ma quanti di noi sanno cosa succede dietro le quinte?

Per esempio, cosa succede quando usiamo git commit? Cosa viene conservato dopo ogni commit? Sono solo le differenze tra il commit attuale e quello precedente? In questo caso come sono codificate le differenze? Oppure viene salvata un'istantanea del repository ogni volta? Cosa succede veramente quando usiamo git init?

Molti di coloro che usano git non conoscono le risposte alle domande poste qui sopra. Ma ha davvero importanza?

Innanzitutto, come professionisti, dovremmo impegnarci a capire gli strumenti che usiamo, specialmente così di frequente, come git.

Ma soprattutto, ho scoperto che capire come funziona effettivamente git è utile in molte situazioni, sia che si tratti di risolvere conflitti di merge, che si cerchi di eseguire un rebase interessante, o anche solo quando qualcosa va leggermente storto.

Potrai trarre vantaggio da questo post se hai già abbastanza esperienza con git per sentirti a tuo agio con comandi come git pull ,git push ,git add oppure git commit.

Ciononostante, inizieremo con uno sguardo d'insieme per essere sicuri di essere tutti allo stesso livello per quanto riguarda la conoscenza dei meccanismi di git, e in particolare con i termini che verranno usati in questo post.

Ho anche caricato su YouTube una serie che tratta degli argomenti trattati in questo post e che ti invito a guardare qui.

Cosa aspettarsi da questo tutorial

Avremo una approfondita comprensione di ciò che accade dietro le quinte durante le operazioni che facciamo quasi quotidianamente con git.

Inizieremo trattando gli oggetti —  blob, tree (alberi) e commit. Discuteremo quindi brevemente dei branch e di come vengono implementati. Analizzeremo i dettagli della directory di lavoro, dell'area di stage e del repository.

Ci assicureremo anche di capire come questi termini si relazionano rispetto ai comandi git che conosciamo e utilizziamo per creare un nuovo repository.

Successivamente, creeremo un repository da zero , senza usare git init, git add o git commit. Questo ci consentirà di approfondire la nostra comprensione di ciò che avviene dietro le quinte quando lavoriamo con git.

Creeremo anche nuovi branch, ci sposteremo tra di essi e creeremo ulteriori commit, tutto senza usare git branch o git checkout.

Alla fine di questo post, ti sentirai di aver capito git. Sei pronto per farlo?😎

Oggetti Git: blob, alberi (tree) e commit

È molto utile pensare a git come alla gestione di un file system, e in particolare a "istantanee" di un file system in un dato momento.

Un file system inizia con una directory radice (root directory), nei sistemi basati su Unix, /, che in genere contiene altre directory (per esempio /usr o /bin). Queste directory possono contenere altre directory e/o file (per esempio /usr/1.txt).

In git, il contenuto dei file viene conservato in oggetti chiamati blob (binary large objects – grandi oggetti binari).

La differenza tra blob e file è che i file contengono anche metadati. Per esempio un file "ricorda" quando è stato creato, quindi se lo sposti in un'altra directory, la sua data di creazione rimane la stessa.

I blob, diversamente, hanno solo contenuto, flussi binari di dati. Un blob non registra la sua data di creazione, il suo nome o qualsiasi altra cosa diversa dal suo contenuto.

Ogni blob in git viene identificato dal suo hash SHA-1. Gli hash SHA-1 sono di 20 byte e rappresentano in genere 40 caratteri in formato esadecimale. In questo post talvolta mostreremo solo i primi caratteri di questo hash.

In git, l'equivalente di una directory è un albero (tree). Un albero in pratica è un elenco del contenuto di una directory, che può essere costituito da dei blob così come da altri alberi.

Anche gli alberi sono identificati dal loro hash SHA-1. Per riferirsi a questi oggetti, siano blob o alberi, si usa il loro hash SHA-1.

Osserva l'albero CAFE7 che  contiene il  blob F92A0 che rappresenta pic.png. In un altro albero, quello stesso blob potrebbe avere un altro nome.

Il diagramma qui sopra equivale a un file system con una directory radice che ha un file, /test.js, e una directory chiamata /docs nella quale ci sono due file: /docs/pic.png e /docs/1.txt.

Ora è tempo di prendere un'istantanea di quel file system e conservare tutti i file al momento esistenti, assieme al loro contenuto.

In git, un'istantanea è un commit. Un oggetto commit include un puntatore all'albero principale (la directory radice), e anche altri metadati come il l'esecutore del commit (committer), un messaggio di commit, e la marca temporale del commit.

In molti casi, un commit ha anche uno o più commit genitori, vale a dire le istantanee precedenti. Naturalmente anche gli oggetti commit sono identificati dal loro hash SHA-1. Questi sono gli hash mostrati quando usiamo git log.

Ogni commit contiene l'intera istantanea, non solo le differenze rispetto ai commit precedenti.

Come può funzionare? Non significa che dovremo conservare un gran volume di dati ad ogni commit?

Esaminiamo cosa succede se modifichiamo il contenuto di un file. Diciamo che vogliamo modificare 1.txt, aggiungendo un punto esclamativo, cioè modifichiamo il contenuto da HELLO WORLD a HELLO WORLD!.

Bene, questa modifica significa avere un nuovo blob, con un nuovo hash SHA-1. Ha senso, visto che sha1("HELLO WORLD") è diverso da sha1("HELLO WORLD!").

Poiché abbiamo un nuovo hash, allora anche il contenuto dell'albero dovrebbe cambiare, dopo tutto il nostro albero non punta più al blob 73D8A, ma al blob 62E7A . Quando modifichiamo il contenuto di un albero cambiamo anche il suo hash.

Ora, visto che l'hash dell'albero è diverso, dobbiamo cambiare anche l'albero genitore, visto che non punta più all'albero CAFE7, ma all'albero 24601. Ne consegue che anche l'albero genitore avrà un nuovo hash.

Siamo quasi pronti per creare un nuovo oggetto commit, e sembra che andremo a salvare un gran volume di dati, l'intero file system, ancora una volta! È davvero necessario?

In realtà, alcuni oggetti, blob nello specifico, non sono cambiati rispetto al commit precedente, il  blob F92A0 è rimasto invariato, e anche il  blob F00D1.

Ecco il trucco, fintanto che un oggetto non cambia, non lo salviamo nuovamente. In questo caso non dobbiamo salvare nuovamente i blob F92A0 e blob F00D1. Dobbiamo solo riferirci a essi usando i loro valori di hash. Quindi possiamo creare il nostro oggetto commit.

Visto che questo commit non è il primo commit, ha un genitore, il  commit A1337.

Per ricapitolare, abbiamo introdotto tre oggetti git:

• blob — il contenuto di un file.
• tree (albero)  — il contenuto di una directory (di blob e alberi).
• commit — un'istantanea dell'albero di lavoro.

Prendiamo un attimo in considerazione gli hash di questi oggetti. Supponiamo che io abbia scritto la stringa git is awesome! e da essa abbia creato un blob. Tu hai fatto lo stesso sul tuo sistema. Avremo lo stesso hash?

La risposta è  sì. Visto che i blob contengono gli stessi dati, avranno gli stessi valori di hash SHA-1.

Cosa succede se io creo un albero che fa riferimento al blob git is awesome!, e gli do nome e metadati specifici, e tu fai esattamente la stessa cosa sul tuo sistema. Avremo lo stesso hash?

Ancora una volta la risposta è sì. Visto che gli oggetti alberi sono uguali, avranno lo stesso hash.

Se creo un commit di quell'albero con il messaggio di commit Hello, e tu fai lo stesso nel tuo file system. Avremo gli stessi hash?

In questo caso la risposta è negativa. Anche se i nostri oggetti commit fanno riferimento allo stesso albero, hanno dettagli di commit diversi, la marca temporale, l'esecutore del commit, e così via.

Branch in Git

Un branch (ramo) è semplicemente un riferimento nominativo a un commit.

Possiamo sempre fare riferimento a un commit in git tramite il suo hash SHA-1, ma noi umani in genere preferiamo altri modi per denominare gli oggetti. Un branch è un modo di referenziare un commit, ma è semplicemente questo.

Nella maggior parte dei repository, la linea principale di sviluppo viene implementata in un branch chiamato master. È semplicemente un nome, creato quando usiamo git init, pertanto largamente usato. Tuttavia non riveste un significato particolare, e si potrebbe usare un qualsiasi altro nome ci vada a genio.

Tipicamente, il branch punta all'ultimo commit nella linea di sviluppo sulla quale stiamo attualmente lavorando.

Per creare un altro branch, in genere usiamo il comando git branch. Facendo questo creiamo in realtà un altro puntatore. Quindi se creiamo un branch chiamato test, usando il comando git branch test, stiamo in realtà creando un altro puntatore direzionato verso lo stesso commit del branch nel quale ci troviamo attualmente.

Come fa git a sapere su quale branch ci troviamo attualmente? Mantiene un puntatore speciale, detto HEAD. In genere HEAD punta a un branch, che a sua volta punta a un commit. In alcuni casi, HEAD può anche puntare direttamente a un commit, ma non ci focalizzeremo su questo.

Per rendere attivo il branch test, possiamo usare il comando git checkout test. Possiamo già indovinare cosa fa questo comando in realtà: cambia semplicemente il puntamento di HEAD verso test.

Possiamo anche usare  git checkout -b test prima di creare il branch test, che equivale a eseguire git checkout test, per far puntare HEAD al nuovo branch.

Cosa succede se eseguiamo qualche modifica e creiamo un nuovo commit con git commit? A quale branch verrà aggiunto il nuovo  commit?

La risposta è il branch test, visto che è il branch attivo (quello su cui punta HEAD). Successivamente, il puntatore di test verrà spostato verso il nuovo commit aggiunto. Nota che HEAD punta ancora a test.

Quindi se riattiviamo master eseguendo git checkout master, facciamo in modo che HEAD punti nuovamente a master .

Ora se creiamo un altro commit, verrà aggiunto al branch master (e il suo genitore sarà il commit B2424).

Come registrare le modifiche in Git

In genere, quando lavoriamo sul nostro codice, lo facciamo da una directory di lavoro (working dir). Una directory di lavoro o albero di lavoro, è una qualsiasi directory nel nostro file system che ha un repository associato. Contiene le cartelle e i file del nostro progetto, e una directory chiamata .git, che esamineremo più approfonditamente in seguito.

Dopo aver fatto alcune modifiche, vogliamo registrarle nel nostro repository. Un repository (repo in breve) è una collezione di commit, ciascuno dei quali rappresenta un archivio di quello che era l'albero di lavoro in una data precedente, sia sulla nostra macchina che su quella di qualcun altro.

Un repository include anche altre cose oltre ai nostri file che contengono il codice, come  HEAD, branch, e così via.

A differenza di altri strumenti simili che potresti avere usato, git non inserisce le modifiche effettuate dall'albero di lavoro direttamente nel repository. Viceversa le modifiche sono prima registrate in qualcosa chiamato indice (index) o area di stage (staging area).

Entrambi questi termini fanno riferimento alla stessa cosa e sono spesso usati nella documentazione di git. Useremo questi termini in modo intercambiabile all'interno di questo post.

Quando attiviamo (checkout) un branch, git popola l'indice con tutti i contenuti dei file che erano presenti l'ultima volta nella nostra directory di lavoro e come apparivano quando sono stati originariamente verificati. Quando usiamo git commit, il commit viene creato in base allo stato dell'indice.

L'uso dell'indice ci consente di preparare con cura ogni commit. Per esempio potremmo avere due file con modifiche rispetto al nostro ultimo commit nella nostra directory di lavoro. Potremmo volere aggiungere solo uno di essi all'indice (usando git add), quindi usare git commit per registrare solo quelle modifiche.

I file nella nostra directory di lavoro possono trovarsi in uno di due stati: tracciato (tracked) o non tracciato (untracked).

I file tracciati sono quelli che git conosce. Potrebbero trovarsi nell'ultima istantanea (commit) oppure essere stati portati nell'area di stage adesso.

I file non tracciati, sono tutto il resto, qualunque file o directory nella nostra directory di lavoro che non compariva nella nostra ultima istantanea (commit) e che non si trova attualmente nell'area di stage.

Come creare un repository nel modo convenzionale

Assicuriamoci di capire in che modo i termini che abbiamo introdotto si riferiscono al procedimento di creazione di un repository. Questa è solo una rapida panoramica di alto livello, prima di immergerci molto più a fondo in questo processo.

Nota:  la maggior parte delle videate con i comandi di shell mostra i comandi UNIX. Fornirò comandi sia per Windows che per UNIX, con schermate da Windows, per coprire i sistemi operativi più diffusi. Quando i comandi saranno esattamente gli stessi, li fornirò solo una volta.

Inizializzeremo un nuovo repository usando git init repo_1, quindi ci sposteremo nella directory di quel repository usando cd repo_1. Digitando tree /f .git possiamo vedere che l'esecuzione di git init ha prodotto parecchie sottodirectory all'interno di .git. (L'opzione del comando tree  /f include anche i file nel risultato dell'esecuzione del comando).

Creiamo un file all'interno della directory repo_1 (versione Windows):

Sui sistemi Linux e macOS:

Questo file si trova all'interno della nostra directory di lavoro. Tuttavia, visto che non è ancora stato inserito nell'area di stage, attualmente risulta non tracciato (untracked). Verifichiamolo con il comando git status:

Ora possiamo aggiungere questo file all'area di stage con il comando git add new_file.txt. Possiamo verificare che il file si trova nell'area di stage eseguendo git status:

Ora possiamo creare un commit con git commit:

È cambiato qualcosa nella directory .git? Eseguiamo tree /f .git per verificare:

Sembra che siano cambiate parecchie cose. È ora di esaminare approfonditamente la struttura di .git e capire cosa succede dietro le quinte quando eseguiamo git init, git add oppure git commit.

Ora di andare alle fondamenta

Fino ad ora abbiamo trattato alcuni degli aspetti base di Git, ora siamo pronti per andare davvero a fondo.

Per capire a fondo come funziona git, dovremo creare un repository, questa volta però lo faremo partendo da zero.

Non useremo git init, git add o git commit, il che ci consentirà di ottenere una migliore comprensione pratica del procedimento.

Come impostare .git

Creiamo una nuova directory, portiamoci all'interno di essa ed eseguiamo git status:

Va bene, git non sembra contento visto che non ha trovato nessuna cartella .git. La cosa naturale da fare sarebbe semplicemente crearla, poi rieseguire git status:

Apparentemente, non è sufficiente creare una cartella .git . Ci serve qualche cosa da immettere in quella directory.

Un repository git ha due componenti principali:

1. Una collezione di oggetti — blob, alberi, e commit.
2. Un sistema di denominazione di quegli oggetti, o riferimenti (references).

Un repository potrebbe anche contenere altre cose, come gli hook di git, ma come minimo deve includere oggetti e riferimenti.

Creiamo quindi una directory per gli oggetti, .git\objects e una per i riferimenti,  .git\refs (sui sistemi UNIX .git/objects e .git/refs, rispettivamente).

Un tipo di riferimento sono i branch. Internamente, git chiama i branch con il nome head. Quindi andremo a creare una directory apposita, .git\refs\heads.

Lo stato non cambia ancora eseguendo git status:

Come fa git a sapere dove iniziare a cercare un commit nel repository? Come spiegato in precedenza, cerca HEAD, che punta al branch attivo corrente (o commit in taluni casi).

Quindi dobbiamo creare HEAD, che è semplicemente un file che si trova in ./git/HEAD. Per farlo eseguiamo:

Su Windows: > echo ref: refs/heads/master > .git\HEAD

Su sistemi UNIX: $ echo "ref: refs/heads/master" > .git/HEAD

⭐ Adesso sappiamo come viene implementato HEAD, è semplicemente un file e il suo contenuto descrive verso quale oggetto puntare.

Dopo l'esecuzione dei comandi qui sopra, git status sembra cambiare idea:

Ora git crede che siamo nel branch chiamato master, anche se non abbiamo creato questo branch. Come detto prima,  master è solo un nome. Avremmo potuto far credere a  git di essere su un branch chiamato banana se avessimo voluto:

Per il resto di questo post torneremo a master, semplicemente per conformarci alla normale convenzione.

Ora che la nostra directory .git è pronta, possiamo iniziare le operazioni per creare un commit (come già detto, senza usare git add oppure git commit).

I comandi in Git, idraulica vs. ceramica

A questo punto sarebbe utile fare una distinzione tra due tipi di comando in git: idraulici e in ceramica. La definizione è presa in prestito da termini usati dagli idraulici quando si parla di tazza (già, questa — 🚽), che tradizionalmente è fatta di ceramica mentre l'infrastruttura (tubi e scarichi) costituisce l'idraulica.

Mantenendo l'analogia, possiamo dire che la ceramica fornisce all'utente un'interfaccia amichevole per accedere a tubature e scarichi. La maggior parte delle persone ha a che fare con la ceramica. Tuttavia, quando succede qualcosa di veramente brutto, e qualcuno vuole capirne il motivo, deve rimboccarsi le maniche e controllare le tubature e gli scarichi. (Nota: questi termini non sono miei, sono usati in modo estensivo in git).

git usa questa terminologia come analogia per distinguere i comandi di basso livello che in genere gli utenti non usano direttamente (i comandi idraulici che agiscono su tubi e scarichi) dai comandi di alto livello più amichevoli per gli utenti (comandi in ceramica).

Fino a ora abbiamo avuto a che fare con i comandi in ceramica, git init, git add o git commit. Di seguito passeremo ai comandi idraulici.

Come creare oggetti in Git

Partiamo creando un oggetto e scrivendolo nel database degli oggetti di git, che si trova in .git\objects. Troveremo un valore di hash SHA-1 per un blob usando il nostro primo comando di basso livello (idraulico), git hash-object, in questo modo:

Su Windows:

> echo git is awesome | git hash-object --stdin

Su sistemi UNIX:

$ echo "git is awesome" | git hash-object --stdin

Usando --stdin diciamo a git hash-object di prendere i suoi dati dallo standard input. Questo ci fornirà il relativo valore hash valido.

Per scrivere effettivamente quel blob nel database degli oggetti di git possiamo semplicemente aggiungere l'opzione -w a git hash-object. Successivamente possiamo verificare il contenuto della cartella .git e vedere cosa è cambiato.

Adesso possiamo vedere che l'hash del nostro blob è 54f6...36. Possiamo anche vedere che è stata creata una sottodirectory in .git\objects chiamata 54, il file è stato chiamato f6...36.

Quindi git in realtà prende i primi due caratteri dell'hash SHA-1 e li usa come nome di una directory. I restanti caratteri dell'hash vengono usati come nome del file che contiene il blob.

Come mai? Immagina un repository piuttosto grande, uno che abbia 300.000 oggetti (blob, alberi, e commit) nel suo database. Può servire molto tempo per cercare un hash in una lista di 300.000 elementi. Per questo git divide semplicemente il problema per 256.

Per cercare l'hash qui sopra, git per prima cosa cerca una directory chiamata 54 all'interno di .git\objects, che potrebbe avere fino a 256 directory (da 00 a FF). Poi cerca in quella directory, restringendo la ricerca mano a mano che la stessa progredisce.

Torniamo al nostro procedimento per generare un commit. Ora che abbiamo creato un oggetto, di che tipo è? Possiamo usare un altro comando di basso livello, git cat-file -t (-t sta per “tipo”), per verificarlo:

Non c'è da sorprendersi, questo oggetto è un blob. Possiamo anche usare  git cat-file -p (-p sta per “pretty-print” - bella stampa) per vederne il contenuto:

Il procedimento di creazione di un blob in genere si verifica quando aggiungiamo qualcosa nell'area di stage, vale a dire quando usiamo git add.

Ricorda che git crea un blob dell'intero file portato in area di stage. Anche se viene modificato un solo carattere (come nell'esempio di prima quando abbiamo aggiunto un !), il file avrà un nuovo blob con un nuovo hash.

Vedremo modifiche se verifichiamo lo stato del repository usando git status?

Apparentemente no. Aggiungere un oggetto blob al database interno di git non modifica lo stato, visto che git non sa in questa fase quali file siano tracciati o meno.

Dobbiamo tracciare questo file, aggiungendolo all'area di stage. A questo scopo possiamo usare il comando di basso livello git update-index, così: git update-index --add --cacheinfo 100644 <blob-hash> <nomefile>.

Nota: cacheinfo è un file in modalità 16-bit conservato da git, seguendo le direttive di tipi e modalità POSIX. Questo va oltre lo scopo di questo post.

Eseguendo il comando qui sopra otterremo una modifica nel contenuto di .git:

Riesci a identificare le modifiche? È stato creato un nuovo file chiamato index . Eccolo, il famoso indice (o area di stage), è praticamente un file che si trova nella directory .git.

Adesso che il nostro blob è stato aggiunto all'indice, ci aspettiamo che il risultato di git status sia diverso, come questo:

Interessante! Sono successe due cose.

La prima, possiamo vedere che my_file.txt è visualizzato in verde nella sezione Changes to be committed (modifiche da portare in commit). Questo perché l'indice ora contiene my_file.txt, in attesa di essere portato in un commit.

La seconda, osserviamo che my_file.txt viene visualizzato in rosso, poiché git crede che my_file.txt sia stato eliminato e il fatto che il file sia stato eliminato non è stato registrato in area di stage.

Questo succede in quanto abbiamo aggiunto un blob con il contenuto git is awesome al database degli oggetti, e abbiamo detto all'indice che my_file.txt ha il contenuto di quel  blob, ma in realtà non abbiamo mai veramente creato quel file.

Possiamo facilmente risolvere prendendo il contenuto del blob e scrivendolo nel nostro file system, in un file chiamato my_file.txt:

Ne consegue che my_file.txt non appare più in rosso nel risultato di  git status:

È ora di creare un oggetto commit dalla nostra area di stage. Come spiegato sopra, un oggetto commit ha un riferimento a un albero, quindi dobbiamo crearlo.

Lo possiamo fare con il comando git write-tree, che registra il contenuto dell'indice in un oggetto albero. Naturalmente possiamo usare git cat-file -t per verificare che in effetti si tratti di un albero:

Possiamo usare git cat-file -p per vedere il contenuto:

Grande, abbiamo creato un albero, e ora ci serve creare un oggetto commit che faccia riferimento a questo albero. Per farlo possiamo usare git commit-tree <hash-albero> -m <messaggio_di_commit>:

Ora dovresti essere a tuo agio con i comandi usati per verificare il tipo di oggetto creato, e per stamparne il contenuto:

Osserva che questo commit non ha un genitore, visto che è il primo commit. Quando aggiungeremo un altro commit, dovremo dichiarare il suo genitore, lo faremo più tardi.

L'ultimo hash che abbiamo ottenuto,  80e...8f è l'hash di un commit. Questi hash ci devono essere piuttosto familiari, ci abbiamo a che fare tutte le volte. Nota che un commit detiene un oggetto albero, con un proprio hash, che raramente specifichiamo esplicitamente.

Qualcosa è cambiato nel risultato di  git status?

Niente 🤔.

Come mai? Bene, per sapere che il nostro file è stato portato in commit, a git serve conoscere il nostro ultimo commit. Come ci riesce? Legge HEAD:

HEAD punta a master, ma cos'è master? Non l'abbiamo ancora creato.

Come spiegato in precedenza, un branch è semplicemente un riferimento nominativo a un commit. In questo caso, vorremmo che master facesse riferimento al commit con hash 80e8ed4fb0bfc3e7ba88ec417ecf2f6e6324998f.

Possiamo farlo creando semplicemente un file master in  \refs\heads, con questo hash come contenuto, così:

⭐ Alla fine, un branch è semplicemente un file all'interno di .git\refs\heads, che contiene un hash del commit al quale si riferisce.

Ora, finalmente, git status e git log sembrano apprezzare i nostri sforzi:

Abbiamo creato con successo un commit senza usare i comandi di alto livello (quelli in ceramica)! Forte, non è vero? 🎉

Come lavorare con i branch in Git: dietro le quinte

Proprio come abbiamo creato un  repository e un commit senza usare git init, git add o git commit, ora possiamo creare e spostarci tra i branch senza usare i comandi di primo livello (quelli in ceramica), git branch o git checkout.

È perfettamente legittimo che tu sia eccitato, lo sono anche io 🙂

Iniziamo:

Finora abbiamo solo un branch, che si chiama master. Per crearne un altro che chiameremo test (l'equivalente di git branch test), dobbiamo semplicemente creare un file chiamato test all'interno di .git\refs\heads, e il contenuto di quel file sarà lo stesso hash del commit al quale master punta.

Se usiamo git log, possiamo vedere che questo è in effetti il caso, sia master che test puntano a questo commit:

Ora spostiamoci nel nostro branch appena creato (l'equivalente di git checkout test). A questo scopo, dovremo modificare HEAD per farlo puntare al nostro nuovo branch:

Come possiamo vedere, sia git status che git log confermano che HEAD ora punta a  test, che è, di conseguenza, il branch attivo.

Ora possiamo avvalerci dei comandi già usati per creare un altro file e aggiungerlo all'indice:

Con i comandi qui sopra, abbiamo creato un file chiamato test.txt, che contiene la parola Testing, creato il blob corrispondente, e lo abbiamo aggiunto all'indice. Abbiamo anche creato un albero che rappresenta l'indice.

Adesso creiamo un commit che fa riferimento a questo albero. Questa volta, dovremmo anche specificare il genitore di questo commit, che sarà il commit precedente. Specifichiamo il genitore usando l'opzione -p per  git commit-tree:

Abbiamo appena creato un commit, con albero e un genitore, come possiamo vedere:

Il risultato di git log ci mostrerà il nuovo commit?

git log non ci mostra nulla di nuovo, come puoi vedere. Perché?🤔 Ricorda che git log traccia i branch per trovare commit rilevanti da mostrare. Adesso ci mostra test e il  commit a cui punta, e ci mostra anche master, che punta allo stesso commit.

Esatto, dobbiamo modificare  test per farlo puntare al nostro nuovo commit. Lo facciamo modificando semplicemente il contenuto di  .git\refs\heads\test:

Ha funzionato! 🎉🥂

git log passa per HEAD, che gli dice di andare al branch test, che a sua volta punta al commit 465...5e, il quale fa riferimento nuovamente al suo commit genitore 80e...8f.

Meraviglioso, non è vero? 😊

Riepilogo

Questo post ti ha introdotto ai meccanismi interni di git. Abbiamo iniziato trattando gli oggetti di base, blob, alberi e commit.

Abbiamo appreso che un blob conserva il contenuto di un file. Un albero è un elenco di directory contenente blob e/o sottoalberi. Un blob è un'istantanea della nostra directory di lavoro, con alcuni metadati come la marca temporale e il messaggio di commit.

Abbiamo quindi discusso dei branch e spiegato che non sono altro che un riferimento nominativo a un commit.

Abbiamo continuato descrivendo la directory di lavoro, una directory a cui è associato un repository, l'area di stage (indice) che contiene l'albero per il commit successivo e il repository, che è una raccolta di commit.

Abbiamo chiarito come questi termini si relazionano ai comandi git che conosciamo creando un nuovo repository ed eseguendo il commit di un file utilizzando i ben noti comandi git init, git add e git commit.

Quindi ci siamo immersi senza paura in git. Abbiamo smesso di usare comandi di alto livello (in ceramica) e siamo passati a comandi di basso livello (idraulici).

Usando echo e comandi di basso livello come git hash-object, siamo stati in grado di creare un blob, aggiungerlo all'indice, creare un albero dell'indice e creare un oggetto commit che punta a quell'albero.

Siamo stati anche in grado di creare e passare da un branch all'altro. Complimenti a quelli di voi che l'hanno provato da soli!👏

Spero che dopo aver seguito questo post sentirai di aver approfondito la tua conoscenza di ciò che accade dietro le quinte quando lavori con git.

Grazie per aver letto! Se ti è piaciuto questo articolo, puoi leggere di più su questo argomento sul blog swimm.io.

Omer Rosenbaum, Chief Technology Officer per Swimm. Esperto di cyber training e fondatore di Checkpoint Security Academy. Autore di Computer Networks (in Ebraico).

Visita il mio Canale YouTube

Risorse addizionali

Molto è stato scritto e detto su git. In particolare, ho trovato utili queste risorse (in lingua inglese - n.d.t.):

• La playlist di YouTube Git Internals — di Brief
• La lezione di Tim Berglund  “Git From the Bits Up”
• Git from the Bottom Up ,  di John Wiegley
• as promised, docs: git for the confused
• Git Internals — Git Objects , dal libro Pro Git book, di Scott Chacon e Ben Straub

Uno degli strumenti più potenti che uno sviluppatore può avere nella propria cassetta degli attrezzi è git rebase. Eppure è noto per essere complesso e frainteso.

La verità è che se capisci cosa fa realmente, git rebase è uno strumento molto elegante e diretto per ottenere tante cose diverse in Git.

Nei post precedenti, hai capito come funziona git diff, cosa sia un'azione di merge, come git risolve i conflitti di merge. In questo post, capirai cos'è il comando rebase di Git, perché è diverso da merge e come utilizzare git rebase con sicurezza 💪🏻

Prima di iniziare

1. Ho creato anche un video che tratta il contenuto di questo post. Se desideri guardarlo mentre stai leggendo, puoi trovarlo qui.
2. Se vuoi fare esperimenti con il repository che ho usato e provare da solo i comandi, puoi trovarlo qui.
3. Sto lavorando a un libro su Git! Ti interessa leggere la versione iniziale e darmi un feedback? Mandami una email: gitting.things@gmail.com

OK, sei pronto?

Breve riepilogo - Cos'e Git Merge? 🤔

Dietro le quinte, git rebase e git merge sono cose molto, molto diverse. Allora come mai la gente continua a confrontarli tutte le volte?

La ragione è il loro utilizzo. Quando si lavora con Git in genere si lavora su branch diversi, nei quali si introducono delle modifiche.

Nel tutorial precedente, ho fornito un esempio dove John e Paul (dei Beatles) scrivevano a 4 mani una nuova canzone. Avevano iniziato entrambi dal branch main poi ognuno di loro ha preso una strada diversa, modificando le parole, quindi confermando le loro modifiche.

Poi entrambi volevano integrare i loro cambiamenti, il che è qualcosa che succede molto frequentemente quando lavori con Git.

Ci sono due modi principali per integrare modifiche introdotte in branch diversi in Git, oppure, in altre parole, diversi commit e diverse cronologie di commit. Questi sono merge e rebase.

In un tutorial precedente, abbiamo imparato a conoscere git merge molto bene. Abbiamo visto come eseguire un merge, abbiamo creato il merge di un commit – dove il contenuto di questo commit è una combinazione di due branch, e aveva anche due genitori, uno in ciascun branch.

Quindi, diciamo che sei sul branch john_branch (ipotizzando la cronologia descritta nell'immagine qui sopra) ed esegui git merge paul_branch. Arriverai a questo stato – dove su john_branch, c'è un nuovo commit con due genitori. Il primo sarà il commit su john_branch dove HEAD stava puntando prima di eseguire il merge, in questo caso - "Commit 6". Il secondo sarà il commit puntato da paul_branch, "Commit 9".

Osserva nuovamente il grafico della cronologia: hai creato una cronologia divergente. Puoi in effetti vedere dove sono stati ramificati e integrati nuovamente.

Quindi quando usi git merge, non riscrivi la cronologia – piuttosto aggiungi un commit alla cronologia esistente. E, nello specifico, un commit che crea cronologie divergenti.

In che modo git rebase è diverso da git merge? 🤔

Quando si usa git rebase, succede qualcosa di diverso. 🥁

Partiamo dal quadro generale: se sei su paul_branch, ed esegui git rebase john_branch, Git va all'antenato comune per i branch di John e Paul. Poi prende le modifiche introdotte nei commit del branch di Paul e applica dette modifiche al branch di John.

In questo caso usi rebase per prendere le modifiche effettuate e confermate (con commit) in un branch – quello di Paul (paul_branch) – e le replichi in un branch diverso – quello di John (john_branch).

Aspetta, cosa significa? 🤔

Ora analizziamo questo concetto un poco per volta, in modo che tu possa capire pienamente cosa sta succedendo sotto il cofano 😎

cherry-pick come base per rebase

È utile pensare a rebase come all'esecuzione di git cherry-pick – un comando che prende un commit, calcola le differenze che questo introduce confrontando il commit del genitore con il commit stesso, e le replica nel branch corrente.

Facciamolo a mano.

Se diamo un'occhiata alle differenze introdotte da "Commit 5" eseguendo git diff main <SHA_DI_COMMIT_5>:

Se vuoi fare esperimenti con il repository che ho usato e provare da solo i comandi, puoi trovare il repository qui.

Puoi notare in questo commit, che John ha iniziato a lavorare a una canzone chiamata "Lucy in the Sky with Diamonds":

Ti ricordo che puoi usare anche il comando git show per ottenere lo stesso risultato:

git show <SHA_DI_COMMIT_5>

Ora se esegui il cherry-pick di questo commit, introdurrai questa specifica modifica, sul branch attivo. Prima portati su main:

git checkout main (oppure git switch main)

Poi crea un altro branch, giusto per essere più chiari:

git checkout -b my_branch (oppure git switch -c my_branch)

Poi esegui il cherry-pick di questo commit:

git cherry-pick <SHA_DI_COMMIT_5>

Esamina questo log (risultato di git lol):

(git lol è un alias che ho aggiunto a Git per vedere chiaramente in modo grafico la cronologia. Puoi trovare il comando che sostituisce qui).

Sembra che tu abbia fatto un copia-incolla di "Commit 5". Ricorda che sebbene abbia lo stesso messaggio di commit e introduca le stesse modifiche, e punti anche allo stesso albero di oggetti  del "Commit 5" originale, in questo caso è comunque un oggetto commit diverso, visto che è stato creato con una diversa marca temporale.

Se osserviamo le modifiche usando git show HEAD:

Sono le stesse di "Commit 5"'.

Naturalmente, se osservi il contenuto del file con un editor (diciamo usando il comando nano lucy_in_the_sky_with_diamonds.md), sarà nello stesso stato nel quale si trovava dopo il "Commit 5" originale.

Forte! 😎

OK, ora puoi eliminare il nuovo branch così che non appaia nella tua cronologia tutte le volte:

git checkout main
git branch -D my_branch

Andare oltre cherry-pick – Come usare git rebase

Puoi considerare git rebase come un modo per eseguire più cherry-pick uno dopo l'altro – vale a dire "replicare" diversi commit. Questa non è la sola cosa che puoi fare con  rebase, ma è un buon punto di partenza per la nostra spiegazione.

È ora di giocare con git rebase! 👏🏻👏🏻

In precedenza, hai integrato  paul_branch in john_branch. Cosa sarebbe successo se avessi eseguito il rebase di paul_branch su john_branch? Avresti ottenuto una cronlogia molto diversa.

In sostanza, sarebbe come se avessimo preso le modifiche introdotte nei commit su paul_branch e le avessimo replicate su john_branch. Il risultato sarebbe stato una cronologia lineare.

Per capire il processo, ti fornirò una visione ad alto livello, poi approfondiremo ogni passaggio. Il processo di rebase di un branch su un altro branch è il seguente:

1. Trova l'antenato comune.
2. Identifica i commit da "replicare".
3. Per ogni commit X, calcola diff(genitore(X), X), e conserva il risultato come patch(X).
4. Sposta HEAD verso la nuova base.
5. Applica le patch generate in ordine sul branch di destinazione. Ogni volta, crea un nuovo oggetto commit con il nuovo stato.

Il processo di creare nuovi commit con lo stesso insieme di modifiche di commit esistenti è detto "replica" di questi commit, un termine che abbiamo già usato.

È ora di provare rebase🙌🏻

Partiamo dal branch di Paul:

git checkout paul_branch

Questa è la cronologia:

Ora veniamo alla parte eccitante:

git rebase john_branch

Osserva la cronologia:

gg è un alias per uno strumento esterno che ho introdotto nel video (è il programma git-graph che puoi trovare in questo repository - n.d.t.).

Pertanto mentre con git merge hai aggiunto alla cronologia, con git rebase hai riscritto la cronologia. Hai creato oggetti commit nuovi. Inoltre il risultato è un grafico di cronologia lineare, non divergente.

In sostanza abbiamo "copiato" i commit che si trovavano in paul_branch, introdotti dopo "Commit 4", e "incollati" in john_branch.

Il comando è chiamato "rebase", in quanto modifica la base di commit del branch dal quale viene eseguito. Nel nostro caso, prima di eseguire git rebase, la base di paul_branch era "Commit 4" – visto che da lì è "nato" il branch (derivato da main). Con rebase, hai chiesto a Git di darti un'altra base, vale a dire: fai finta che paul_branch sia "nato"  da "Commit 6".

Per fare questo Git ha preso quello che era il "Commit 7", e ha "replicato" le modifiche introdotte in questo commit in "Commit 6", poi ha creato un nuovo oggetto commit. Questo oggetto differisce dal "Commit 7" originale in tre aspetti:

1. Ha una marca temporale diversa.
2. Ha un commit genitore diverso – "Commit 6" invece che "Commit 4".
3. L'albero di oggetti a cui punta è diverso - visto che le modifiche sono state introdotte all'albero di oggetti puntato da "Commit 6", non a quello puntato da "Commit 4".

Nota l'ultimo commit qui, "Commit 9'". L'istantanea che rappresenta (cioè l'albero a cui punta) è esattamente la stessa che avresti se avessi integrato i due branch. Lo stato dei file nel tuo repository Git sarebbe stato uguale se avessi usato git merge. Solo che la cronologia è diversa, e l'oggetto commit naturalmente.

Ora puoi semplicemente usare:

git checkout main
git merge paul_branch

Hmm... Cosa succederebbe se eseguissi questo ultimo comando? 🤔 Esamina nuovamente la cronologia dei commit, dopo esserti portato in  main:

Cosa comporta integrare main e paul_branch?

In effetti, Git può semplicemente eseguire un merge fast-forward, visto che la cronologia è perfettamente lineare (se ti serve una rinfrescata su cosa sia un merge fast-forward, dai un'occhiata a  questo post). Come risultato, main e paul_branch ora puntano allo stesso commit:

Rebase avanzato in Git💪🏻

Ora che conosci le basi di rebase, è ora di prendere in considerazione casi più avanzati, laddove torneranno utili opzioni addizionali e argomenti per il comando rebase.

Nell'esempio precedente, quando hai usato rebase senza opzioni aggiuntive, Git ha replicato tutti i commit a partire dall'antenato comune fino all'inizio del branch corrente.

Ma rebase è potentissimo, è un comando possente in grado di riscrivere la cronologia e può tornare utile se vuoi modificare la cronologia e generarne una tua propria.

Annulla l'ultimo merge facendo puntare nuovamente main a "Commit 4":

git reset -–hard <COMMIT 4_ORIGINALE>

Annulla anche il rebase in questo modo:

git checkout paul_branch
git reset -–hard <COMMIT 9_ORIGINALE>

Nota che ora la cronologia è esattamente quella che avevi in precedenza:

Giusto per essere chiari, "Commit 9" non sparisce semplicemente quando non è raggiungibile dall'HEAD corrente. Viceversa è ancora conservato nel database degli oggetti. Visto che hai usato git reset per fare in modo che HEAD punti a questo commit, sei in grado di recuperarlo, assieme ai suoi commit genitori visto che anch'essi sono conservati nel database. Non male, non è vero? 😎

Adesso diamo un veloce sguardo alle modifiche introdotte da Paul:

git show HEAD

Proseguiamo a ritroso nel grafico dei commit:

git show HEAD~

Andiamo indietro di un altro commit:

git show HEAD~2

Quindi, queste modifiche sono buone, ma forse Paul non vuole questo tipo di cronologia. Piuttosto vuole che sembri che le modifiche introdotte in  "Commit 7" e "Commit 8" appaiano come un singolo commit.

Per fare questo, puoi usare un rebase interattivo, aggiungendo l'opzione -i (oppure --interactive) al comando rebase :

git rebase -i <SHA_DI_COMMIT_4>

Oppure, visto che main sta puntando a  "Commit 4", possiamo semplicemente eseguire:

git rebase -i main

Eseguendo questo comando, dici a Git di usare una nuova base, "Commit 4". Pertanto stai chiedendo a Git di tornare a tutti i commit che sono stati introdotti dopo "Commit 4", che sono raggiungibili dall' HEAD corrente, e di replicarli.

Per ogni commit che viene replicato, Git ci chiede come vogliamo agire:

In questo contesto, è utile pensare a un commit come a una modifica. Vale a dire,  "Commit 7" come fosse "la modifica che 'Commit 7' ha introdotto sopra il suo genitore".

Una opzione è usare pick. Questo è il comportamento predefinito, che dice a Git di replicare le modifiche introdotte in questo commit. In questo caso, non devi fare nulla e scegliere (pick)  per tutti i commit – otterrai la stessa cronologia e Git non dovrà neppure creare dei nuovi oggetti commit.

Un'altra opzione è squash. Un commit si definisce squashed (accorpato) quando ha tutto il suo contenuto inserito nel commit precedente. Nel nostro caso Paul vorrebbe accorpare  "Commit 8" in "Commit 7":

Come puoi vedere,  git rebase -i fornisce opzioni aggiuntive, ma non le esamineremo tutte in questo post. Se provi ad eseguire il rebase, ti verrà richiesto di indicare un messaggio per il nuovo commit che sarà creato (vale a dire quello che introdurrà le modifiche sia di "Commit 7" che di "Commit 8"):

Dai un'occhiata alla cronologia:

Esattamente quello che volevamo! Abbiamo su paul_branch "Commit 9" (ovviamente un oggetto diverso rispetto al "Commit 9" originale). Questo punta a "Commits 7+8", che è un singolo commit che contiene le modifiche dei "Commit 7" e "Commit 8" originali. Il genitore di questi commit è  "Commit 4", a cui sta puntando main, che è il genitore di john_branch.

Wow, forte, non è vero? 😎

git rebase ti consente controllo illimitato sulla forma di qualsiasi branch. Puoi usarlo per riordinare i commit, oppure per rimuovere modifiche non corrette, o cambiare una modifica in retrospettiva. In alternativa, potresti spostare la base del tuo branch in un altro commit di tua scelta.

Come usare l'opzione di switch --onto di git rebase

Consideriamo un altro esempio. Andiamo su main nuovamente:

git checkout main

Eliminiamo i puntatori a paul_branch e john_branch in modo che non compaiono più nel grafico della cronologia:

git branch -D paul_branch
git branch -D john_branch

Ora generiamo un nuovo branch da main e ci spostiamo su di esso:

git checkout -b new_branch

Ora facciamo qualche modifica ed eseguiamo il commit:

nano code.py

git add code.py
git commit -m "Commit 10"

Torniamo su main:

git checkout main

Poi introduciamo una modifica:

Adesso eseguiamo il commit queste modifiche:

git add code.py
git commit -m "Commit 11"

Poi effettuiamo un altro cambiamento:

Eseguiamo il commit anche di questa modifica:

git add code.py
git commit -m "Commit 12"

Aspetta, ora mi sono reso conto che avrei voluto apportare le modifiche introdotte nel "Commit 11" in new_branch. Che si può fare adesso? 🤔

Esaminiamo la cronologia:

Quello che voglio è che invece di avere "Commit 10" situato solo sul branch  main, sia anche in new_branch. Visivamente, vorrei spostarlo in fondo al grafico mostrato qui sotto:

Riesci a vedere dove voglio arrivare? 😇

Bene, come sappiamo rebase ci consente in pratica di replicare le modifiche introdotte in new_branch, quelle del "Commit 10",  come se in origine fossero state apportate in "Commit 11" invece che in "Commit 4".

Per fare questo, puoi usare altri argomenti di git rebase. Dovresti dire a Git che vuoi prendere tutta la cronologia introdotta tra l'antenato comune di main e new_branch, che sarebbe "Commit 4", e fare in modo che la nuova base per quella cronologia sia "Commit 11". Per farlo usa:

git rebase -–onto <SHA_DI_COMMIT_11> main new_branch

Ora dai uno sguardo alla nostra meravigliosa cronologia! 😍

Consideriamo un altro caso.

Diciamo che ho iniziato a lavorare su un branch e per errore ho iniziato a lavorare da feature_branch_1, invece che da main.

Per emulare questa situazione crea feature_branch_1:

git checkout main
git checkout -b feature_branch_1

Poi elimina new_branch così che non appaia più nel grafico della cronologia:

git branch -D new_branch

Crea un semplice file Python chiamato 1.py:

Aggiungi a Git questo file ed esegui il commit:

git add 1.py
git commit -m  "Commit 13"

Ora esci (per errore) da feature_branch_1 ed entra in un nuovo branch (feature_branch_2):

git checkout -b feature_branch_2

Poi crea un altro file, 2.py:

Aggiungi anche questo file ed esegui il commit:

git add 2.py
git commit -m  "Commit 14"

Poi inserisci dell'altro codice a 2.py:

Fai il commit anche di queste modifiche:

git add 2.py
git commit -m  "Commit 15"

Fino ad ora dovresti avere questa cronologia:

Ritorna su feature_branch_1 e modifica 1.py:

git checkout feature_branch_1

Fai il commit del file modificato:

git add 1.py
git commit -m  "Commit 16"

La tua cronologia dovrebbe essere questa:

Diciamo che ora ti rendi conto di avere fatto un errore. In realtà avresti voluto far nascere feature_branch_2 da main, invece che da feature_branch_1.

Come puoi rimediare? 🤔

Prova a pensarci tenendo conto del grafico della cronologia e di quello che hai imparato fino ad ora sull'opzione --onto per il comando rebase

Bene, vuoi "sostituire" il genitore del tuo primo commit su feature_branch_2, che è "Commit 14", in modo che sia alla sommità del branch main , in questo caso "Commit 12", invece che all'inizio di feature_branch_1, in questo caso "Commit 13". Pertanto, ancora una volta, andrai a creare una nuova base, questa volta per il primo commit su feature_branch_2.

Come faresti?

Per prima cosa portati su feature_branch_2:

git checkout feature_branch_2

Da qui puoi usare:

git rebase -–onto main <SHA_DI_COMMIT_13>

Come risultato avrai feature_branch_2 con base su main invece che su feature_branch_1:

La sintassi del comando è:

git rebase --onto <nuovo_genitore> <vecchio_genitore>

Come effettuare il rebase su un singolo branch

Puoi anche usare git rebase in relazione alla cronologia di un singolo branch.

Vediamo se mi puoi aiutare.

Diciamo che ho lavorato da feature_branch_2, e nello specifico ho modificato il file code.py. Ho iniziato modificando gli apici singoli che racchiudono le stringhe in apici doppi:

Poi ho eseguito il commit delle modifiche:

git add code.py
git commit -m "Commit 17"

Quindi ho deciso di aggiungere una nuova funzione all'inizio del file:

Ho nuovamente portato nell'area di stage code.py ed eseguito il commit:

git add code.py
git commit -m "Commit 18"

Ora mi sono reso conto che mi sono dimenticato di cambiare gli apici che racchiudono l'istruzione  __main__ da singoli a doppi (come potresti aver notato), pertanto ho fatto anche questo:

Naturalmente ho eseguito il commit anche di questa modifica:

git add code.py
git commit -m "Commit 19"

Ora esamina la cronologia:

Non è molto bella, giusto? Voglio dire, ho due commit (in relazione tra loro), "Commit 17" e "Commit 19" (sostituzione di ' con  "), ma sono separati l'uno dall'altro da un "Commit 18" che non ha niente a che vedere con quelli (ho aggiunto una nuova funzione). Cosa posso fare? 🤔 Puoi aiutarmi?

Andando a intuito, voglio modificare la cronologia qui:

Quindi, cosa dovrei fare?

Hai ragione! 👏🏻

Posso eseguire il rebase della cronologia da  "Commit 17" a "Commit 19", sopra il "Commit 15". Per fare questo:

git rebase --interactive --onto <SHA_DI_COMMIT_15> <SHA_DI_COMMIT_15>

Nota che ho specificato "Commit 15" come inizio del gruppo di commit, escludendo questo commit. Non ho avuto bisogno di specificare  HEAD come ultimo parametro.

Dopo aver seguito il tuo consiglio ed eseguito il comando rebase  (grazie! 😇) mi viene presentata la seguente schermata:

Quindi cosa dovrei fare? Voglio inserire "Commit 19" prima di "Commit 18", in modo che venga appena dopo "Commit 17". Posso proseguire e accorparli, in questo modo:

Ora quando mi viene richiesto di inserire un messaggio per il commit, posso indicare  "Commit 17+19":

Ora guardiamo la nostra stupenda cronologia:

Grazie ancora! 🙌🏻

Altri casi d'uso per rebase + altri esercizi

A questo punto, spero tu sia a tuo agio con la sintassi di rebase. Il modo migliore per comprenderla veramente è considerare varie situazioni e cercare di risolverle da solo.

Per quanto riguarda i casi d'uso che andrò a presentare, ti suggerisco vivamente di interrompere la lettura dopo che ho introdotto ciascun caso e cercare di risolverlo autonomamente.

Come escludere commit

Ipotizziamo che in un altro repository tu abbia questa cronologia:

Prima di iniziare a sperimentare, inserisci un etichetta (tag) per "Commit F", in modo che tu possa poi tornarci più tardi:

git tag original_commit_f

In realtà non vuoi includere le modifiche in "Commit C" e "Commit D". Potresti usare un rebase interattivo come prima ed eliminare quelle modifiche, oppure potresti nuovamente usare  git rebase -–onto. In che modo useresti l'opzione --onto per "rimuovere" quei due commit?

Puoi portare la base di  HEAD sopra a  "Commit B", dove il vecchio genitore era in realtà "Commit D", e ora dovrebbe essere "Commit B". Esamina nuovamente la cronologia:

Effettuare il rebase in modo che "Commit B" costituisca la base di "Commit E", significa "spostare" sia "Commit E" che "Commit F", e dargli un'altra base – "Commit B". Puoi comporre da solo il comando per fare questo?

git rebase --onto <SHA_DI_COMMIT_B> <SHA_OF_COMMIT_D> HEAD

Nota che usando la sintassi qui sopra non viene spostato main per puntare al nuovo commit, pertanto il risultato è un HEAD staccato. Se usi gg (git-graph) o un altro strumento che visualizza la cronologia raggiungibile dai branch potresti essere confuso:

Tuttavia se usi semplicemente git log (oppure il mio alias git lol), vedrai la cronologia desiderata:

Non so tu come la pensi, ma questo tipo di cose mi fanno davvero felice. 😊😇

A proposito, potresti omettere HEAD dal comando precedente poiché questo è il valore predefinito per il terzo parametro. Quindi usando solo:

git rebase --onto <SHA_DI_COMMIT_B> <SHA_DI_COMMIT_D>

otterresti lo stesso risultato. L'ultimo parametro in effetti dice a Git dove si trova la fine della sequenza corrente di commit per i quali effettuare il rebase. Quindi la sintassi git rebase --onto con tre argomenti è:

git rebase --onto <nuovo_genitore> <vecchio_genitore> <fino_a>

Come spostare commit tra branch

Diciamo di avere la stessa cronologia di prima, alla quale torniamo usando il tag applicato nella sezione precedente:

git checkout original_commit_f

Ora voglio che solo "Commit E", sia in un branch basato su "Commit B". Vale a dire, voglio avere un nuovo branch, che si dirama da "Commit B", con solo "Commit E".

Quindi, cosa significa questo in termini di rebase? Osserva l'immagine qui sopra. Quale commit (o quali) dovrebbero essere oggetto di rebase, e quale commit dovrebbe costituire la nuova base?

So che posso contare su di te qui 😉

Quello che voglio è prendere "Commit E", e solo questo commit, e modificare la sua base in  "Commit B". In altre parole, replicare le modifiche introdotte in "Commit E" su "Commit B".

Puoi applicare questa logica alla sintassi di git rebase?

Eccola (questa volta scrivo <COMMIT_B> invece di <SHA_DI_COMMIT_B>, per brevità):

git rebase –-onto <COMMIT_B> <COMMIT_D> <COMMIT_E>

Ora la cronologia risulta questa:

Meraviglioso!

Una nota sui conflitti

Nota che quando esegui un rebase, potresti imbatterti in conflitti, come se stessi facendo un'azione di integrazione con merge. Potresti avere conflitti perché quando si esegue il rebase, stai cercando di applicare modifiche su una base diversa, nella quale forse le modifiche non si applicano.

Per esempio prendi di nuovo il repository precedente e in particolare esamina le modifiche introdotte nel "Commit 12", puntato da main:

git show main

Ho già trattato il formato di git diff in dettaglio in un post precedente, ma come veloce ripasso questo commit dice a Git di aggiungere una riga dopo le due righe:

```
This is a sample file

e prima di queste tre righe:

```
def new_feature():
  print('new feature')

Supponiamo che tu stia tentando di effettuare un rebase di "Commit 12" su un altro commit. Se, per qualche motivo, queste righe non esistono come nella patch sul commit verso il quale stai effettuando il rebase, allora avrai un conflitto. Per saperne di più sui conflitti e su come risolverli, consulta questa guida.

La prospettiva dal quadro generale

All'inizio di questa guida, ho iniziato citando le similitudini tra git merge e git rebase: entrambi sono usati per integrare modifiche introdotte in diverse cronologie.

Tuttavia, come ora sai, le modalità con le quali operano sono molto diverse. Con merge l'integrazione ha come risultato cronologie divergenti, con rebase la cronologia risultante è lineare. I conflitti sono possibili in entrambi i casi. C'è un'ulteriore colonna nella tabella qui sopra (la terza) che richiede una particolare attenzione.

Ora che sai cos'è git rebase e come usare il rebase interattivo oppure  rebase --onto, spero che tu sia d'accordo con me nell'affermare che git rebase sia uno strumento potentissimo. Tuttavia ha un grosso inconveniente se confrontato con l'integrazione via merge.

Git rebase modifica la cronologia.

Ciò significa che non dovresti effettuare il rebase di commit che si trovano al di fuori della tua copia locale del repository, sul quali altre persone potrebbero aver basato i loro commit.

In altre parole, se i commit in oggetto sono solo quelli che tu hai creato localmente, vai pure avanti, usa rebase, scatenati.

Ma se i commit sono stati portati sul repository remoto, si può generare un grosso problema, visto che qualcun altro potrebbe fare affidamento su questi commit, che tu più tardi hai sovrascritto, pertanto tu e gli altri avrete versioni diverse del repository.

Questo è improbabile avvenga con merge in quanto, come abbiamo visto, non modifica la cronologia.

Considera ad esempio l'ultimo caso nel quale abbiamo effettuato un rebase che ha generato questa cronologia:

Ora, supponi che io abbia già portato questo branch nel repository remoto con git push, e dopo aver fatto questo, un altro sviluppatore abbia scaricato il repository derivandolo da "Commit C". L'altro sviluppatore non sa che, nel frattempo, io avevo effettuato localmente il rebase del mio branch e l'avevo successivamente inviato nuovamente al repository remoto.

Ne deriva un'inconsistenza: l'altro sviluppatore lavora da un commit che non è più disponibile sulla mia copia del repository.

Non approfondirò le conseguenze esatte di quanto esposto qui sopra in questa guida, visto che il mio messaggio principale è che dovresti evitare assolutamente queste situazioni. Se ti interessa sapere cosa sarebbe veramente accaduto, ti lascio un link a un'utile risorsa qui sotto. Per ora riepiloghiamo quanto abbiamo trattato.

Riepilogo

In questo tutorial, hai appreso il comando git rebase, uno strumento potentissimo per riscrivere la cronologia in Git. Hai preso in considerazione alcune situazioni dove git rebase può essere di aiuto, e come usarlo con uno, due o tre parametri, con e senza l'opzione --onto.

Spero di essere stato in grado di convincerti che git rebase è potente, tuttavia è piuttosto semplice una volta che hai capito il concetto. È uno strumento per "copiare-incollare" i commit (o più precisamente, le modifiche), ed è utile da avere a tua disposizione.

Riferimenti aggiuntivi

• Git Internals YouTube playlist — by Brief (il mio canale YouTube).
• Un mio post precedente sui meccanismi interni di Git.
• Un mio tutorial su Git UNDO - riscrivere la cronologia con Git.
• Documentazione di Git su rebase
• Branch e la potenza di rebase
• Rebase interattivo
• Git rebase --onto

Notizie sull'autore

Omer Rosenbaum è Chief Technology Officer per Swimm . È l'autore  del canale YouTube Brief. È anche un esperto di cyber training e fondatore della Checkpoint Security Academy. È l'autore di Computer Networks (in Ebraico). Lo puoi trovare su Twitter.

Git è una parte importante dell'attività quotidiana di programmazione (specialmente se lavori in un team) ed è largamente usato nell'industria del software.

Visto che ci sono molti comandi che puoi usare, padroneggiare Git richiede tempo. Tuttavia alcuni comandi sono usati più frequentemente (alcuni quotidianamente). Pertanto in questo post condividerò e spiegherò i 10 comandi Git più usati che ogni sviluppatore dovrebbe conoscere.

Nota: per comprendere questo articolo, dovresti conoscere le basi di Git.

1. git clone

git clone è un comando per scaricare il codice sorgente esistente da un repository remoto (come Github, per esempio). In altre parole, git clone praticamente fa una copia identica dell'ultima versione di un progetto in un repository e la salva sul tuo computer.

Ci sono un paio di modi per scaricare il codice sorgente, ma per lo più preferisco la clonazione tramite https:

git clone <https://link-del-nome-del-repository>

Per esempio, se vuoi scaricare un progetto da Github, tutto quello che devi fare è cliccare sul pulsante verde "Clone or download", copiare l'URL dalla casella di testo e incollarlo dopo il comando "git clone", la cui sintassi ho mostrato qui sopra.

Questo effettuerà una copia del progetto nel tuo spazio di lavoro locale in modo che tu possa iniziare a lavorarci.

2. git branch

I branch sono molto importanti nel mondo Git. Usando i branch, parecchi sviluppatori sono in grado di lavorare in parallelo sullo stesso progetto simultaneamente. Possiamo usare il comando git branch per creare, elencare ed eliminare branch.

Creare un nuovo branch:

git branch <nome-branch>

Questo comando crea un nuovo branch localmente. Per inviare il nuovo branch al repository remoto, devi usare questo comando:

git push -u <remoto> <nome-branch>

Visualizzare i branch:

git branch oppure git branch --list

Eliminare un branch:

git branch -d <nome-branch>

3. git checkout

Anche questo è uno dei comandi git più usati. Per lavorare in un branch, per prima devi spostarti su di esso. Usiamo git checkout principalmente per spostarci da un branch all'altro. Possiamo anche usarlo per verificare file e commit.

git checkout <nome-del-tuo-branch>

Ci sono alcuni passaggi che devi seguire per spostarti con successo tra i branch:

• Devi eseguire l'azione di commit per le modifiche nel tuo branch corrente oppure devi accantonarle (git stash) prima di cambiare branch
• Il branch sul quale vuoi portarti deve esistere localmente

C'è anche una comando scorciatoia che consente di creare e portarsi su un branch allo stesso tempo:

git checkout -b <nome-del-tuo-nuovo-branch>

Questo comando crea un nuovo branch localmente (-b sta per branch) quindi passa ad esso non appena viene creato.

4. git status

Il comando git status fornisce tutte le informazioni necessarie sul branch corrente.

git status

Possiamo raccogliere diverse informazioni, tra le quali:

• se il branch corrente è aggiornato
• se c'è qualcosa da passare a commit, da inviare al repository oppure da ottenere dal repository
• se ci sono file nell'area di stage, non passati all'area di stage oppure non tracciati
• se ci sono file creati, modificati o cancellati

5. git add

Quando creiamo, modifichiamo o cancelliamo un file, queste modifiche hanno luogo localmente e non saranno incluse nel prossimo commit (a meno che non modifichiamo la configurazione).

Dobbiamo utilizzare il comando git add per includere le modifiche di uno o più file nel prossimo commit.

Per aggiungere un file singolo:

git add <file>

Per aggiungere tutto in una volta:

git add -A

Come puoi vedere dalla videata precedente nella sezione 4, ci sono nomi di file in colore rosso, il che significa che questi file che non sono stati contrassegnati per essere inclusi nel prossimo commit.

Per includerli, dobbiamo usare git add:

Importante: Il comando git add non modifica il repository e i cambiamenti non saranno salvati a meno che non usiamo git commit.

6. git commit

Questo è forse il comando di Git maggiormente usato. Una volta che raggiungiamo un certo punto nello sviluppo, vogliamo salvare le nostre modifiche (che probabilmente si riferiscono a un'attività o alla risoluzione di un problema specifico).

git commit è come impostare un punto di controllo nel processo di sviluppo, al quale puoi tornare successivamente se necessario.

Dobbiamo anche scrivere un breve messaggio per spiegare cosa abbiamo sviluppato o modificato nel codice.

git commit -m "messaggio di commit"

Importante: git commit salva le tue modifiche solo localmente.

7. git push

Dopo avere eseguito il commit delle tue modifiche, la prossima cosa che vorrai fare sarà inviare le modifiche al server remoto. git push invia i tuoi commit al repository remoto.

git push <remoto> <nome-branch>

Tuttavia, se il tuo branch è nuovo, dovrai inviare anch'esso con il comando:

git push --set-upstream <remoto> <nome-del-tuo-branch>

oppure

git push -u origin <nome_branch>

Importante: git push invia solo le modifiche che sono state oggetto di commit

8. git pull

Il comando git pull viene usato per ottenere aggiornamenti dal repository remoto. È la combinazione dei comandi git fetch e git merge, il che significa che quando usiamo git pull otteniamo aggiornamenti dal repository remoto (git fetch) e applichiamo immediatamente le ultime modifiche localmente (git merge).

git pull <remoto>

Questa operazione potrebbe causare conflitti che potresti dover risolvere manualmente.

9. git revert

Talvolta dobbiamo annullare modifiche che abbiamo effettuato. Ci sono vari modi per annullare le modifiche, sia localmente che su remoto (a seconda delle necessità), ma dobbiamo essere cauti con questi comandi per evitare cancellazioni indesiderate.

Un modo più sicuro per annullare i nostri commit è l'uso del comando git revert. Per vedere la nostra cronologia di commit, per prima cosa usiamo git log --oneline:

Poi dobbiamo solo specificare il codice hash vicino al commit che vorremmo annullare:

git revert 3321844

A questo punto, verrà aperto l'editor di testo predefinito e vedrai un testo come quello qui sotto. Digita semplicemente il comando per uscire dall'editor oppure modifica e salva il contenuto se vuoi modificare il messaggio di commit:

Il comando git revert annullerà il commit specificato creando un nuovo commit senza eliminare quello vecchio:

Il vantaggio dell'uso di git revert è che non tocca la cronologia dei commit. Questo significa che puoi ancora vedere tutti i commit nella tua cronologia, anche quelli ripristinati.

Un'altra misura di sicurezza qui è che tutto accade localmente a meno che non inviamo (git push) i commit al repository remoto. Ecco perché git revert è più sicuro da usare ed è il modo da preferire per annullare i nostri commit.

10. git merge

Quando hai completato lo sviluppo nel tuo branch, e tutto funziona correttamente, il passo finale è integrare il branch nel suo branch genitore (dev o master). Ciò viene fatto con il comando git merge.

In pratica git merge integra il branch che stai usando con tutti i suoi commit con il branch dev (o master). È importante ricordare che prima devi portarti nel branch nel quale vuoi effettuare l'integrazione.

Per esempio, quando vuoi integrare un tuo branch nel branch dev:

Prima portati nel branch dev:

git checkout dev

Prima dell'integrazione, dovresti aggiornare il tuo branch dev locale:

git fetch

Alla fine, puoi integrare il tuo branch nel branch dev:

git merge <nome-branch>

Suggerimento: Assicurati che il tuo branch dev sia aggiornato all'ultima versione, prima di effettuare il merge, altrimenti potresti avere dei conflitti o altri problemi indesiderati.

Questi sono i 10 comandi git più usati durante la programmazione quotidiana. Ci sono molte altre cose da imparare su Git e le spiegherò successivamente in altri articoli.

Se vuoi saperne di più sullo sviluppo web, puoi seguirmi su Youtube!

Grazie per la lettura!

Potresti già sapere che Git è come un sistema di punti di salvataggio. Quello che in genere impari con Git all'inizio è come salvare le tue modifiche ed eseguire un'azione di commit verso un repository remoto. Ma come fare per ripristinare una modifica e tornare a uno stato precedente?

È ciò che andremo a trattare all'interno di questo articolo.

Il contenuto di questo articolo è anche esposto in un video (risorsa in inglese) se preferisci imparare guardando invece che leggendo.

Locale contro Remoto

È più complicato ripristinare qualcosa che si trova già su remoto. Ecco perché vorrai mantenere le cose sulla tua macchina locale fino a quando sei praticamente sicuro che vadano bene.

Quattro scenari comuni

Tratteremo i quattro scenari seguenti:

1. Eliminare modifiche locali
2. Correggere il commit precedente
3. Ripristinare lo stato del codice a un commit precedente
4. Ripristinare un commit che è stato inviato al repository remoto

Nota: Nelle videate che seguono, ho usato il client Git Fork for Mac OS.  Puoi fare altrettanto in altri client Git simili.

Scenario 1: Eliminare modifiche locali

In questo primo scenario ipotizziamo che hai effettuato alcune modifiche che non sono ancora state oggetto di commit, e vuoi eliminarle.

Diciamo di voler creare una nuova funzionalità. Aggiungeremo un poco di HTML e CSS al progetto:

<!--Nel file index.html-->
<div class="feature"></div>

/* Nel file CSS */
.feature {
  font-size: 2em; 
  /* Altri stili */
}

Per eliminare queste modifiche:

1. Vai all'area di staging
2. Seleziona i file dai quali vuoi eliminare le modifiche
3. Click destro sui file
4. Seleziona "Discard changes"

Scenario 2: Correggere il commit precedente

In questo caso hai creato un commit ma hai dimenticato di aggiungere alcune modifiche e vuoi aggiungere dette modifiche nel messaggio di commit precedente.

1. Vai all'area di staging
2. Porta i file da inserire nel commit nell'area di staging
3. Clicca sulla casella di spunta "Amend"
4. Modifica il tuo messaggio di commit
5. Esegui il commit

Scenario 3: Ritornare a un commit precedente

Hai già effettuato alcuni commit nel tuo repository locale. Decidi che non vuoi più questi commit e vuoi "caricare" i tuoi file da uno stato precedente.

1. Vai a "Git History"
2. Click destro sul commit verso il quale vuoi ritornare
3. Seleziona "Reset nome-branch to here"

Nota: Puoi ritornare solo a commit che non sono stati ancora inviati al repository remoto.

Scenario 4: Annullare un commit che è stato inviato a un remoto

In questo caso hai un commit che è stato già inviato a un repository remoto e vuoi annullarlo.

Annullarlo significa ripristinare la situazione precedente creando un nuovo commit "al contrario". Se hai aggiunto una riga, questo commit la eliminerà. Se hai eliminato una riga, questo commit la aggiungerà nuovamente.

Per fare questo:

1. Vai a Git history
2. Click destro sul commit che vuoi annullare
3. Seleziona "Revert commit"
4. Assicurati che  "commit the changes" sia spuntato.
5. Click su Revert

Altri scenari

GitHub ha un utile articolo che ti mostra come puoi ripristinare praticamente qualsiasi cosa con Git. Ti sarà utile qualora dovessi fronteggiare altre situazioni. Leggilo qui (risorsa in inglese).

Grazie per la lettura. Questo articolo ti è stato d'aiuto in qualche modo? In questo caso mi auguro che tu lo voglia condividere. Potresti aiutare qualcuno. Grazie!

Questo articolo è stato originariamente pubblicato sul mio blog.
Iscriviti alla mia newsletter se vuoi più articoli che ti aiutino a diventare uno sviluppatore migliore.

La prima parte di questa serie ha esaminato il funzionamento interno di Git e ti ha mostrato come non aver paura di lavorare con Git.

Ora che abbiamo capito come funziona Git, passiamo alla sostanza: come sfruttare ciò che sappiamo nei nostri progetti.

Integrazione (merge)

Merge integra il tuo codice.

Ricordi come stavamo seguendo le buone pratiche Git, avendo branch per varie funzionalità su cui stavamo lavorando e non tutto su master? Verrà un momento in cui avrai finito con quella funzionalità e vorrai includerla nel tuo master. È qui che entra in gioco merge, quando vuoi integrare il tuo ramo in master.

Ci sono due tipi di azioni di merge:

Integrazione con avanzamento veloce (fast forward merge)

Ritorniamo al nostro esempio dall'ultima volta:

Questo è tanto semplice quanto spostare l'etichetta per master a the-ending. Git non ha dubbi su ciò che deve essere fatto esattamente, dal momento che il nostro "albero" aveva un'unica lista collegata di nodi.

$ git branch
  master
* the-ending
$ git checkout master
Switched to branch 'master'
$ git merge the-ending
Updating a39b9fd..b300387
Fast-forward
 byeworld | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 byeworld

Integrazione senza avanzamento veloce (non-fast forward merge)

Con questo tipo di integrazione Git non sa cosa fare. Ci sono state alcune modifiche sul branch base e altre modifiche sul branch che vogliamo integrare, il che genera i temuti conflitti di integrazione (merge conflicts)

Ecco la prima cosa da sapere circa i conflitti di integrazione: se non sai cosa sta succedendo, rinuncia all'operazione.

git merge --abort

Questo comando ti riporta allo stato originale, senza effetti collaterali. Hai semplicemente annullato il disastro che stavi per fare.

Esaminiamo passo passo come risolvere i conflitti di integrazione.

$ git checkout -b the-middle
Switched to a new branch 'the-middle'

Continuando secondo il nostro stile, impariamo con un esempio. Ho modificato helloworld nel branch the-middle.

$ git diff
diff --git a/helloworld b/helloworld
index a042389..e702052 100644
--- a/helloworld
+++ b/helloworld
@@ -1 +1,3 @@
 hello world!
+
+Middle World

Poi ho eseguito un'azione di commit su the-middle.

Quindi sono passato a master e ho modificato helloworld. Ho aggiunto quanto segue:

$ git diff --cached
diff --git a/helloworld b/helloworld
index a042389..ac7a733 100644
--- a/helloworld
+++ b/helloworld
@@ -1 +1,3 @@
 hello world!
+
+Master World

Capisci come mai ho dovuto eseguire  git diff --cached qui? In caso contrario chiedimelo qui sotto!

Ora è tempo di integrare!

$ git merge the-middle
Auto-merging helloworld
CONFLICT (content): Merge conflict in helloworld
Automatic merge failed; fix conflicts and then commit the result.

Quando un'azione di merge fallisce, ecco cosa fa git: modifica i file oggetto di integrazione sui quali si sono verificati i conflitti per mostrarti esattamente come potresti agire.

Prima dell'azione di merge, in master il contenuto del file helloworld era:

$ cat helloworld 
hello world!

Dopo l'azione di merge, in master il contenuto del file helloworld è:

$ cat helloworld 
hello world!
<<<<<<< HEAD
Master World
=======
Middle World
>>>>>>> the-middle

Questo ha senso? La parte <<<<< HEAD è la nostra (il branch base) e la parte >>>>> the-middle  è la loro (il branch che si vuole integrare nel branch base).

Puoi semplicemente modificare il file per rimuovere il testo extra aggiunto da git, e scegliere cosa dovrebbe contenere in definitiva helloworld. Ci sono alcuni strumenti e integrazioni per editor per facilitare le cose, ma penso che sapere come funziona sotto il cofano possa  renderti più fiducioso quando non hai a disposizione il tuo editor preferito.

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
Unmerged paths:
  (use "git add <file>..." to mark resolution)
both modified:   helloworld

Ho deciso di mantenere entrambe le modifiche.

$ cat helloworld 
hello world!
Master World
Middle World

N.d.T.
Da qui in avanti i commenti dei commit rilevanti sono stati tradotti per una maggiore comprensione dell'esposizione.

E il gioco è fatto:

$ git add helloworld 
$ git commit -m "risolto conflitto di integrazione"
[master c747e68] risolto conflitto di integrazione

Remoto

Visto che uno dei poteri del controllo della versione delle sorgenti è di salvare il tuo codice in caso di disastri, i remoti sono qui per essere di aiuto. Un remoto è una copia ospitata all'esterno del tuo repository. Per essere più precisi un remoto è un repository esterno (non necessariamente dello stesso codice che tu hai). Per esterno si intende una cartella differente nel tuo file system oppure nel cloud.

Clonazione

Il comando clone esegue una clonazione del repository remoto all'interno della tua directory di lavoro corrente. Ciò avviene semplicemente creando una copia della cartella ./git, che ci fornisce l'intera cronologia e i file necessari per popolare la directory di lavoro.

git clone <repository-url>

Se non hai ancora eseguito un'azione di clonazione, probabilmente non hai un remoto. Puoi creare un remoto in questo modo:

git remote add <nome> <url>

Inviare e Scaricare (push e pull)

Le azioni di push e pull si applicano sul remoto.

Push invia le tue modifiche al remoto, vale a dire che stiamo inviando l'indice e gli oggetti corrispondenti dall'object store della nostra versione locale!

git push <nome del remoto> <nome del branch>

Pull scarica il code dal remoto. Esattamente come prima, stiamo copiando l'indice e gli oggetti corrispondenti dell'object store dalla versione su remoto!

git pull origin master

origin è il nome predefinito del remoto. Visto che master è il branch predefinito puoi vedere come il comando si trasforma nel semplice testo che troviamo ovunque: git pull origin master. Ora ne sai di più.

Reset

Reset ripristina il tuo codebase a una versione precedente. Questo comando ha 3 opzioni:

--soft, --hard e --mixed.

La bellezza di reset, è che è in grado di cambiare la cronologia. Diciamo che hai commesso un errore in un commit e ora il tuo log di git è sporcato da commit di questo tipo:

Risoluzione Bug

Risoluzione Finale Bug

Risoluzione Finale Finale Bug

Accidenti, perché questo non funziona ultimo tentativo di risoluzione bug

Se vuoi mantenere la cronologia del tuo master pulita, vorrai pulire questo log di commit.

Se stai inviando una pull request dove non c'è accorpamento dei commit, è auspicata anche una cronologia di commit pulita!

Ecco dove entra in gioco il comando reset. Potresti ripristinare tutti i tuoi commit e convertirli tutti in uno singolo: tutto sistemato!

(Per favore non usare questo come messaggio di commit, segui le migliori pratiche!)

Tornando al nostro esempio ecco quello che ho fatto :

$ git log
commit 959781ec78c970d4797c5e938ec154de44d0151b (HEAD -> master)
Author: Neil Kakkar
Date:   Mon Nov 5 07:32:55 2018 +0000
Accidenti, perché questo non funziona ultimo tentativo di risoluzione bug
commit affa90c0db78999d22c326fdbd6c1d5057228822
Author: Neil Kakkar
Date:   Mon Nov 5 07:32:19 2018 +0000
Risoluzione Finale Finale Bug
commit 2e9570cffc0a8206132d75c402d68351eda450bd
Author: Neil Kakkar
Date:   Mon Nov 5 07:31:49 2018 +0000
Risoluzione Finale Bug
commit 4560fc0ec6305d0b7bcfb4be1901438fd126d6d1
Author: Neil Kakkar
Date:   Mon Nov 5 07:31:21 2018 +0000
Risoluzione Bug
commit c747e6891af419119fd817dc69a2e122084aedae
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
risolto conflitto di integrazione

Ora che il bug è risolto, vorrei pulire la mia cronologia prima di inviare le modifiche al master. Questo funzionerebbe bene anche nel caso in cui realizzassi a posteriori di avere introdotto un altro bug e volessi ripristinare la versione precedente. In questo caso il commit c747e689 non ha il miglior messaggio di commit per capire questo.

$ git reset c747e6891af419119fd817dc69a2e122084aedae
$ git log
commit c747e6891af419119fd817dc69a2e122084aedae (HEAD -> master)
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
risolto conflitto di integrazione

Ecco, tutto sistemato?

$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
      clean.txt
nothing added to commit but untracked files present (use "git add" to track)

clean.txt è il file che ho usato nel commit per risolvere il bug. Ora tutto quello che devo fare è:

$ git add clean.txt 
$ git commit -m "risoluzione bug: non si riesce a pulire la cartella"
[master d8487ca] risoluzione bug: non si riesce a pulire la cartella
 1 file changed, 4 insertions(+)
 create mode 100644 clean.txt
$ git log
commit d8487ca8b9acfa9666bdf2c6b7fa27b3971bd957 (HEAD -> master)
Author: Neil Kakkar
Date:   Mon Nov 5 07:41:41 2018 +0000
risoluzione bug: non si riesce a pulire la cartella
commit c747e6891af419119fd817dc69a2e122084aedae
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
risolto conflitto di integrazione

Ecco, fatto e finito. Riesci a indovinare ora, usando gli indizi del log, la sintassi del comando reset e le tue capacità tecniche per capire come funziona dietro le quinte?

Reset taglia l'alberatura dei commit al commit specificato. Tutte le etichette per quel branch, se sono più avanti, sono spostate indietro verso il commit specificato. I file esistenti rimangono comunque nell'object store? Sai come verificarlo ora.

I file sono anche stati rimossi dall'area di staging. Ora questo potrebbe essere un problema se hai molti file non tracciati o modificati che non vuoi aggiungere.

Come puoi fare?

Puoi recuperare l'indizio che ho lasciato all'inizio di questa sezione?

Le opzioni per gestire il comportamento del comando reset!

--soft mantiene tutti i file presenti nell'area di staging.

$ git reset --soft c747e6891af419119fd817dc69a2e122084aedae
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
new file:   clean.txt

--mixed è l'opzione predefinita: elimina anche tutti i file dall'area di staging.

--hard è brutale. Elimina i file dall'object store, comprese le directory. Usalo con estrema cautela. Ecco, ora sparisce la mia risoluzione del bug*. Andata.

$ git reset --hard c747e6891af419119fd817dc69a2e122084aedae
HEAD is now at c747e68 risolto conflitto di integrazione
$ git status
On branch master
nothing to commit, working tree clean

*Beh, non completamente. Git è stupefacente. Hai sentito parlare di metadati?. Un registro di ridondanza di quello che accade nel repository? Sì, naturalmente, Git lo mantiene!

$ git reflog
c747e68 (HEAD -> master) HEAD@{0}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
efc6d21 HEAD@{1}: commit: soft reset
c747e68 (HEAD -> master) HEAD@{2}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
d8487ca HEAD@{3}: commit: risoluzione bug: non si riesce a pulire la cartella
c747e68 (HEAD -> master) HEAD@{4}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
959781e HEAD@{5}: commit: Accidenti, perché questo non funziona ultimo tentativo di risoluzione bug
affa90c HEAD@{6}: commit: Risoluzione Finale Finale Bug
2e9570c HEAD@{7}: commit: Risoluzione Finale Bug
4560fc0 HEAD@{8}: commit: Risoluzione Bug
c747e68 (HEAD -> master) HEAD@{9}: commit (merge): risolto conflitto di integrazione
3d01508 HEAD@{10}: commit: add Master World
b300387 (the-ending) HEAD@{11}: checkout: moving from the-middle to master
fb8b2fc (the-middle) HEAD@{12}: commit: add Middle World
b300387 (the-ending) HEAD@{13}: checkout: moving from master to the-middle
b300387 (the-ending) HEAD@{14}: checkout: moving from the-middle to master
b300387 (the-ending) HEAD@{15}: checkout: moving from master to the-middle
b300387 (the-ending) HEAD@{16}: merge the-ending: Fast-forward
a39b9fd HEAD@{17}: checkout: moving from the-ending to master
b300387 (the-ending) HEAD@{18}: checkout: moving from master to the-ending
a39b9fd HEAD@{19}: checkout: moving from the-ending to master
b300387 (the-ending) HEAD@{20}: commit: add byeworld
a39b9fd HEAD@{21}: checkout: moving from master to the-ending
a39b9fd HEAD@{22}: commit (initial): Add helloworld

Questo è tutto il log dall'inizio dell'esempio dell'articolo precedente. Significa che sarei in grado di recuperare delle cose se avessi fatto un orribile errore?

$ git checkout d8487ca
Note: checking out 'd8487ca'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at d8487ca... fix bug: Unable to clean folder

$ ls
byeworld clean.txt  helloworld

N.d.T.
La traduzione del risultato del comando git qui sopra è: "Sei nello stato 'HEAD staccato'. Puoi guardarti attorno, fare modifiche sperimentali e inserirle in un commit, e puoi scartare qualunque commit fatto in questo stato senza influenzare alcun branch eseguendo un'altra azione di checkout.
Se vuoi creare un nuovo branch per mantenere i commit che hai creato, puoi farlo (ora o successivamente) usando nuovamente l'opzione -b con il comando checkout. Esempio: git checkout -b <nuovo-nome-branch>
HEAD è ora a d8487ca... risoluzione bug: non si riesce a pulire la cartella"

Ecco fatto.

Congratulazioni, sei un Git Ninja, apprendista ora.

C'è qualcos'altro che ti piacerebbe sapere? Qualcosa di Git che non ti è chiara? Fammelo sapere qui sotto! Cercherò di spiegartela nel modo nel quale l'ho imparata!

Soddisfatto? Non perdere ancora un altro post — iscriviti alla mia mailing list!

Comprendere i meccanismi per eliminare l'incertezza

Cos'è Git?

“È un sistema di controllo di versione.”

Perché mi serve?

“Per controllare le versioni, sciocchino.”

Va bene, va bene, non sono di grande aiuto, non ancora. Ecco l'idea di base: man mano che i progetti diventano troppo grandi, con troppi collaboratori, diventa impossibile tracciare chi ha fatto cosa e quando. Qualcuno ha introdotto un cambiamento che ha "rotto" l'intero sistema? Come fai a capire di quale cambiamento si tratta? Come tornare indietro, quando le cose funzionavano? Al paese delle meraviglie non compromesso?

Farò un ulteriore passo avanti: diciamo che c'è un progetto che non ha molti collaboratori, solo un piccolo progetto con te come creatore, manutentore e distributore: crei una nuova funzionalità per questo progetto, che introduce subdoli bug che si scopriranno in seguito. Non ricordi quali modifiche hai apportato al codebase esistente per creare questa nuova funzionalità. Problemi?

La risposta a tutti questi problemi è gestire le versioni (versioning)! Avere versioni per tutto il codice che è stato scritto ti assicura di sapere chi ha apportato le modifiche, quali modifiche ed esattamente dove, dall'inizio del progetto!

Ora ti invito a smettere di pensare a git come a una scatola chiusa, aprirlo e scoprire quali tesori ti attendono. Scopri come lavora Git e non avrai mai più problemi a far funzionare le cose. Una volta arrivato in fondo a questo articolo, prometto che ti renderai conto della follia di fare ciò che dice il fumetto XKCD qui sopra. Questo è esattamente ciò che la gestione delle versioni cerca di prevenire.

Come usare Git?

Suppongo che tu conosca i comandi di base di Git, o ne abbia sentito parlare, e che li abbia usati almeno una volta. In caso contrario, ecco un vocabolario di base per aiutarti a iniziare.

repository: un posto per conservare le cose. Con Git indica la cartella in cui si trova il codice

head: un "puntatore" all'ultima versione del codice alla quale stai lavorando.

add: un'azione per dire a Git di tracciare un file.

commit: un'azione per salvare lo stato corrente, in modo che sia possibile visionare questo stato, se necessario

remote: un repository che non è locale. Può essere in un'altra cartella oppure nel cloud (ad esempio GitHub); fa sì che altre persone possano facilmente collaborare, poiché non devono ottenere una copia del codice dal tuo sistema, possono semplicemente ottenerla dal cloud. Inoltre ti assicura di avere una copia di riserva nel caso il tuo computer si rompa

pull: un'azione per ottenere il codice aggiornato dal repository remoto

push: un'azione per inviare il codice aggiornato al repository remoto

merge: un'azione per integrare due versioni differenti di codice

status: visualizza informazioni circa lo stato corrente del repository

Dove si trova Git?

La magia risiede in una cartella nascosta: .git/

In ogni repostitory git, dovresti vedere qualcosa del genere:

$ tree .git/
.git/
├── HEAD
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags
8 directories, 14 files

Questo è il modo nel quale Git controlla e gestisce il tuo intero progetto. Esamineremo tutte le parti importanti, una a una.

Git consiste di 3 parti: l'object store, l'indice e la directory di lavoro.

Object Store

Ecco come Git conserva tutto internamente. Per ogni file nel tuo progetto che aggiungi e aggiorni con il comando add, Git genera un hash per il file e conserva il file sotto quell'hash. Per esempio, se ora creo un file helloworld ed eseguo git add helloworld (che dice a Git di aggiungere un file chiamato helloworld all'object store di git), ottengo qualcosa tipo questo:

$ tree .git/
.git/
├── HEAD
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── objects
│   ├── a0
│   │   └── 423896973644771497bdc03eb99d5281615b51
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags
9 directories, 16 files

È stato generato un nuovo oggetto! Per quelli che sono interessati a guardare sotto il cofano, Git usa internamente il comando hash-object in questo modo:

$ git hash-object helloworld
a0423896973644771497bdc03eb99d5281615b51

Sì, è lo stesso hash che vediamo all'interno della cartella objects. Perché la sotto-directory con i primi due caratteri dell'hash? Rende la ricerca più veloce.

Successivamente, Git crea un oggetto con il nome dell'hash sopra citato, comprime il file relativo e lo conserva lì. Pertanto puoi anche vedere il contenuto dell'oggetto!

$ git cat-file a0423896973644771497bdc03eb99d5281615b51 -p
hello world!

Questo avviene tutto dietro le quinte. Non dovresti mai usare il comando cat-file nelle operazioni quotidiane di aggiunta/aggiornamento. Userai semplicemente il comando add e Git si occuperà del resto.

Questo è il nostro primo comando git, fatto e finito.

git add crea un hash, comprime il file e aggiunge  l'oggetto compresso all'object store.

La directory di lavoro

Come suggerisce il nome, è dove lavori. Tutti i file che crei e modifichi si trovano nella directory di lavoro. Ho creato un nuovo file, byeworld ed eseguito il comando git status:

$ git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
new file:   helloworld
Untracked files:
  (use "git add <file>..." to include in what will be committed)
byeworld

I file non tracciati (untracked files) sono i file nella directory di lavoro che non abbiamo detto a git di gestire.

Se non avessimo fatto nulla nella directory di lavoro avremmo il seguente messaggio:

$ git status
On branch master
nothing to commit, working tree clean

che informa che non ci sono cambiamenti e la situazione del codebase è pulita ("nothing to commit, working tree clean"). Ignora per ora le parole "branch" e "commit". Il concetto chiave è che la directory di lavoro è pulita.

L'indice

Questo è il nucleo di Git. Anche noto come staging area. L'indice conserva la corrispondenza dei file con gli oggetti nell'object store. Qui è dove entrano in gioco i commit. Il miglior modo per vederlo è provare!

Eseguiamo un'azione di commit per l'aggiunta del file helloworld

$ git commit -m "Add helloworld"
[master (root-commit) a39b9fd] Add helloworld
 1 file changed, 1 insertion(+)
 create mode 100644 helloworld

Ora la nostra alberatura è:

$ tree .git/
.git/
├── COMMIT_EDITMSG
├── HEAD
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── a0
│   │   └── 423896973644771497bdc03eb99d5281615b51
│   ├── a3
│   │   └── 9b9fdd624c35eee08a36077f411e009da68c2f
│   ├── fb
│   │   └── 26ca0289762a454db2ef783c322fedfc566d38
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags
14 directories, 22 files

Interessante! Abbiamo due nuovi oggetti nell'object store, e alcune cose che ancora non capiamo nelle cartelle logs e refs. Affidiamoci nuovamente al nostro amico cat-file:

$ git cat-file a39b9fdd624c35eee08a36077f411e009da68c2f -p
tree fb26ca0289762a454db2ef783c322fedfc566d38
author = <=> 1537700068 +0100
committer = <=> 1537700068 +0100
Add helloworld
$ git cat-file fb26ca0289762a454db2ef783c322fedfc566d38 -p
100644 blob a0423896973644771497bdc03eb99d5281615b51 helloworld

Come puoi intuire il primo oggetto rappresenta i metadati del commit: chi ("author", "committer") ha fatto cosa e perché ("Add helloworld"), con un'alberatura ("tree"). Il secondo oggetto è l'effettiva alberatura. Se conosci il file system di unix, sai esattamente di cosa si tratta.

L'alberatura (tree) in Git corrisponde al sistema di file di Git. Tutto è un'alberatura (directory) oppure un file (blob), e a ogni commit, Git conserva anche le informazioni sull'alberatura, per dire a sé stesso: questo è come dovrebbe essere la directory di lavoro a questo punto. Nota che l'alberatura punta esattamente a uno specifico oggetto di ciascun file che contiene (l'hash).

Ora è il momento di parlare dei branch! Il nostro primo commit ha aggiunto qualcosa anche a .git/. Ora il nostro interesse si sposta verso .git/refs/heads/master:

$ cat .git/refs/heads/master 
a39b9fdd624c35eee08a36077f411e009da68c2f

Ecco quello che ti serve sapere sui branch:

Un branch in Git è un puntatore mobile e leggero verso uno di questi commit. Il nome del branch predefinito in Git è master.

Cosa? Mi piace pensare ai branch come a biforcazioni del codice. Vuoi fare qualche modifica ma non vuoi rompere le cose. Decidi di avere una demarcazione più forte di un log di commit, e qui entrano in gioco i branch. master è il branch predefinito, anche usato de-facto come branch di produzione. Da qui, la creazione del file qui sopra. Come puoi dedurre dal contenuto del file, punta al nostro primo commit. Di conseguenza, è un puntatore a un commit.

Esploriamo ulteriormente. Diciamo che ho creato un nuovo branch:

$ git branch the-ending
$ git branch
* master
  the-ending

Eccolo qui, un nuovo branch! Come puoi dedurre, una nuova voce deve essere stata aggiunta a  .git/refs/heads/ e visto che non ci sono commit ulteriori, dovrebbe puntare anche questo al nostro primo commit, proprio come master.

$ cat .git/refs/heads/the-ending
a39b9fdd624c35eee08a36077f411e009da68c2f

Sì, esattamente! Ora ricordi il file byeworld? Questo file non era ancora tracciato, quindi non importa in quale branch ti trovi, quel file sarà sempre lì. Diciamo che voglio spostarmi in questo branch ora, quindi eseguo l'azione di checkout verso il branch.

$ git checkout the-ending
Switched to branch 'the-ending'
$ git branch
  master
* the-ending

Ora, dietro le quinte, Git modificherà tutto il contenuto della directory di lavoro per farlo corrispondere al contenuto indicato dal commit del branch. Per ora, visto che è esattamente lo stesso di master, sembra uguale.

Aggiungo il file byeworld con il comando add ed eseguo il commit.

Cosa ti aspetti che cambi nella cartella objects?

Cosa ti aspetti che cambi nella cartella refs/heads?

Pensaci prima di proseguire.

$ tree .git/
.git/
├── COMMIT_EDITMSG
├── HEAD
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           ├── master
│           └── the-ending
├── objects
│   ├── 0b
│   │   └── 17be9dbc34c5a5fbb0b94d57680968efd035ca
│   ├── a0
│   │   └── 423896973644771497bdc03eb99d5281615b51
│   ├── a3
│   │   └── 9b9fdd624c35eee08a36077f411e009da68c2f
│   ├── b3
│   │   └── 00387d818adbbd6e7cc14945fdf4c895de6376
│   ├── d1
│   │   └── 8affe001488123b496ceb34d8b13b120ab4cb6
│   ├── fb
│   │   └── 26ca0289762a454db2ef783c322fedfc566d38
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   ├── master
    │   └── the-ending
    └── tags
17 directories, 27 files

3 nuovi oggetti, 1 per l'aggiunta del file, 2 per il commit! Ha senso? Cosa pensi che contengano gli oggetti?

• I metadati di commit
• Il contenuto dell'oggetto generato da add
• La descrizione dell'alberatura

L'ultima parte del quadro è: come funzionano questi metadati di commit con i metadati del precedente. Bene, cat-file!

$ git cat-file 0b17be9dbc34c5a5fbb0b94d57680968efd035ca -p
100644 blob d18affe001488123b496ceb34d8b13b120ab4cb6 byeworld
100644 blob a0423896973644771497bdc03eb99d5281615b51 helloworld
$ git cat-file b300387d818adbbd6e7cc14945fdf4c895de6376 -p
tree 0b17be9dbc34c5a5fbb0b94d57680968efd035ca
parent a39b9fdd624c35eee08a36077f411e009da68c2f
author = <=> 1537770989 +0100
committer = <=> 1537770989 +0100
add byeworld
$ git cat-file d18affe001488123b496ceb34d8b13b120ab4cb6 -p
Bye world!
$ cat .git/refs/heads/the-ending 
b300387d818adbbd6e7cc14945fdf4c895de6376

Lo vedi? Il puntatore al genitore ("parent")! Esattamente quello che avevi pensato, una lista collegata, che collega i commit insieme!

Vedi l'implementazione del branch? Punta a un commit, l'ultimo che abbiamo effettuato dopo l'azione di checkout! Naturalmente il master dovrebbe ancora puntare al commit di helloworld, giusto?

$ cat .git/refs/heads/master
a39b9fdd624c35eee08a36077f411e009da68c2f

Va bene, abbiamo esaminato tante cose, riassumiamole fino a qui.

TL;DR

Git lavora con gli oggetti, versioni compresse dei file che chiedi a Git di tracciare.

Ogni oggetto ha un ID(entificativo), un hash generato da Git in base al contenuto del file a cui si riferisce.

Ogni volta che esegui il comando add per aggiungere/aggiornare un file, git aggiunge un nuovo oggetto all'object store. Questa è esattamente la ragione per cui non puoi avere a che fare con file molto grandi in Git – salva l'intero file ogni volta che esegui il comando add per aggiungere modifiche, non le differenze tra le versioni (contrariamente a quanto si crede comunemente).

Ogni commit crea 2 oggetti:

1. L'alberatura: un ID per l'alberatura, che agisce esattamente come una directory unix, che punta ad altre alberature (directory) o blob (file). Questo genera la costruzione dell'intera struttura di directory in base agli oggetti presenti al momento. I blob sono rappresentati dagli oggetti correnti creati dal comando add.
2. I metadati di commit: un ID per i commit, chi ha eseguito il commit, un alberatura che rappresenta il commit, il messaggio di commit e il commit genitore. Forma una struttura a lista collegata che mette insieme i commit.

I branch sono puntatori a metadati degli oggetti di commit, tutti conservati in .git/refs/heads

Questo è tutto per la comprensione di quanto succede dietro le quinte! Nella prossima parte, esamineremo alcune delle azioni di Git che fanno venire gli incubi alle persone:

reset, merge, pull, push, fetch e come modificano la struttura interna in .git/.

Altri articoli in questa serie:

• Come non avere più paura di Vim
• Come non avere più paura di Python

Ti è piaciuto? Non perdere più un post — iscriviti alla mia mailing list!

Cosa fa git log?

Il comando git log visualizza tutti i commit nella cronologia di un repository.

Nella modalità predefinita, il comando visualizza per ogni commit:

• Secure Hash Algorithm (SHA)
• autore
• data
• messaggio di commit

Spostarsi in Git Log

Git usa l'impaginatore Less del terminale per sfogliare la cronologia dei commit. Puoi spostarti al suo interno usando i seguenti comandi:

• per andare alla riga successiva, usa il tasto  j oppure ↓
• per andare alla riga precedente, usa il tasto k oppure ↑
• per spostarti alla videata (pagina) successiva usa la barra spaziatrice oppure il tasto Pagina Giù
• per spostarti alla videata (pagina) precedente, usa il tasto b oppure il tasto Pagina Su
• per uscire dal log, usa il tasto q

Opzioni di Git Log

Puoi personalizzare le informazioni presentate da  git log tramite opzioni.

--oneline

git log --oneline

L'opzione --oneline fa in modo che  git log visualizzi:

• un commit per riga
• i primi sette caratteri del SHA
• il messaggio di commit

--stat

git log --stat

L'opzione --stat fa in modo che git log visualizzi:

• i file che sono stati modificati in ogni commit
• il numero di righe aggiunte o rimosse
• una riga di riepilogo con il numero totale di file e righe modificati

--patch oppure -p

git log --patch

oppure nella versione abbreviata

git log -p

L'opzione --patch fa in modo che git log visualizzi:

• i file che hai modificato
• la posizione delle righe che hai aggiunto o rimosso
• le modifiche specifiche che hai effettuato

Visualizzare un numero specifico di commit per autore

Per visualizzare un numero specifico di commit eseguiti da un autore nel repository corrente (con l'opzione --pretty per un formato abbellito) si può usare il comando seguente:

git log --pretty=format:"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" -n {NUMERO_DI_COMMIT} --author="{NOME_AUTORE}" --all

Partire da uno specifico commit

Per far partire git log da uno specifico commit usa il suo SHA:

git log 7752b22

Questo visualizzerà il commit con SHA 7752b22 e tutti i commit effettuati prima di quello. Puoi aggiungere qualsiasi altra opzione.

--graph

git log --graph

L'opzione --graph ti consente di visualizzare il tuo git log come un grafico. Per rendere le cose interessanti, puoi aggiungere l'opzione --oneline che hai appreso qui sopra.

git log --graph --oneline

Il risultato sarebbe simile a questo:

* 64e6db0 Update index.md
* b592012 Update Python articles (#5030)
* ecbf9d3 Add latest version and remove duplicate link (#8860)
* 7e3934b Add hint for Compose React Components (#8705)
* 99b7758 Added more frameworks (#8842)
* c4e6a84 Add hint for "Create a Component with Composition" (#8704)
*   907b004 Merge branch 'master' of github.com:freeCodeCamp/guide
|\  
| * 275b6d1 Update index.md
* |   cb74308 Merge branch 'dogb3rt-patch-3'
|\ \  
| |/  
|/|   
| *   98015b6 fix merge conflicts after folder renaming
| |\  
|/ /  
| * fa83460 Update index.md
* | 6afb3b5 rename illegally formatted folder name (#8762)
* | 64b1fe4 CSS3: border-radius property (#8803)

Uno dei vantaggi dell'utilizzo di questo comando è che ti consente di ottenere un riepilogo di come i commit si sono integrati e come si è formata la cronologia.

Ci sono molte altre opzioni che potresti usare assieme a --graph. Un paio di queste sono  --decorate e --all. Assicurati di provare anche queste. Puoi fare riferimento alla documentazione (in lingua inglese) per ulteriori informazioni utili.

Ulteriori Informazioni (in lingua inglese):

• Git Basics - Viewing the Commit History
• Git Log

Altre Risorse su Git

• Git Checkout
• Git Commit
• Git Stash
• Git Branch

Git è un popolare sistema di controllo della versione e uno strumento essenziale nella cassetta degli attrezzi di uno sviluppatore.

I branch sono una parte potente e integrante del lavoro con Git.

In questo articolo, imparerai le basi per quanto riguarda l'eliminazione di branch locali e remoti in Git.

Cosa sono i branch in Git?

Un branch è un puntatore a un commit.

I branch di Git sono un'istantanea di un progetto e delle sue modifiche, in uno specifico punto nel tempo.

Quando si lavora su un grande progetto, c'è un repository principale con tutto il codice, spesso chiamato main o master.

Usando un branch sei in grado di creare versioni nuove e indipendenti dall'originale progetto di lavoro principale. Potresti creare un branch per fare modifiche, aggiungere una nuova caratteristica, o scrivere dei test quando stai tentando di risolvere un bug. Un nuovo branch ti consente di fare questo senza influenzare il codice principale in alcun modo.

Riepilogando, i branch ti consentono di fare modifiche al codebase senza influenzare il codice principale, fino a quando sei assolutamente pronto per implementare queste modifiche.

Questo ti aiuta a mantenere il codebase pulito e organizzato.

Perché eliminare i branch in Git?

Hai creato un branch che contiene del codice per una modifica che vorresti effettuare nel tuo progetto.

Poi hai incorporato quella modifica o nuova funzionalità nella versione originale del progetto.

Ciò significa che non è più necessario mantenere o usare quel branch, quindi è buona prassi comunemente usata eliminarlo in modo che non ingombri il tuo codice.

Come eliminare un branch locale in Git

I branch locali sono branch sulla tua macchina locale e non influiscono sui branch remoti.

Il comando per eliminare un branch locale in Git è:

git branch -d  nome_branch_locale

• git branch è il comando che lavora sui branch.
• -d è un'opzione del comando, e un alias per  --delete (elimina).  Denota che tu vuoi eliminare qualcosa come suggerisce il nome (inglese).
• nome_branch_locale è il nome del branch che vuoi rimuovere.

Diamo un'occhiata a questo in modo un po' più dettagliato con un esempio.

Per elencare tutti i branch puoi usare il comando seguente:

git branch

Nel mio caso ho due branch, master e test2. Sono attualmente sul branch test2 come mostra l'asterisco (*) a fianco del nome del branch:

Voglio eliminare il branch test2 , ma non è possibile eliminare il branch sul quale si è attualmente posizionati.

Se provassi a farlo, otterresti un errore come questo:

Quindi, prima di eliminare un branch locale, spostati in un altro branch che NON vuoi eliminare, con il comando git checkout :

git checkout nome_branch

#dove nome_branch è il nome del branch nel quale vuoi spostarti
#nel mio caso l'altro branch che ho è master quindi eseguo:
#git checkout master

Ecco il risultato:

Ora posso eliminare il branch:

Il comando che abbiamo appena usato per eliminare un branch locale non funziona sempre.

Se il branch contiene modifiche al codice che non sono state integrate oppure che si trovano in commit non inviati al repository remoto, l'opzione -d non consente l'eliminazione del branch locale.

Questo perché i commit non sono visti da alcun altro branch e Git ti sta proteggendo contro la perdita accidentale di dati passati a commit.

Se provi a fare questo, Git ti mostra un errore, il cui testo tradotto è "errore: Il branch 'test_2' non è stato interamente integrato. Se sei sicuro di volerlo cancellare, esegui 'git branch -D test_2'"

Come suggerito dal messaggio di errore, devi usare il flag -D al posto di -d:

git branch -D nome_branch_locale

L'opzione -D maiuscola (che è un alias per --delete --force – eliminazione forzata), forza l'eliminazione del branch locale a prescindere dallo stato delle integrazioni.

Nota che dovresti usare questo comando con cautela, visto che non ti verrà richiesta conferma per questa azione.

Usalo solo se se sei assolutamente sicuro che vuoi eliminare un branch locale.

Se non hai integrato il branch in un altro branch locale o inviato il commit a un branch remoto nel codebase, rischierai di perdere tutte le modifiche che hai effettuato.

Come eliminare un branch remoto in Git

I branch remoti sono separati da quelli locali.

Sono dei repository ospitati in un server remoto ai quali si può accedere, al contrario dei branch locali, che sono repository nel tuo sistema locale.

Il comando per eliminare un branch remoto è:

git push nome_remoto -d nome_branch_remoto

• Invece di usare il comando git branch, utilizzato per i branch locali, puoi eliminare un branch remoto con il comando git push.
• Poi specifichi il nome del repository remoto, che nella maggior parte dei casi è origin.
• -d è l'opzione per l'eliminazione, alias per --delete.
• nome_branch_remoto è il branch remoto che vuoi eliminare.

Ora vediamo un esempio di come eliminare un branch remoto.

Per visualizzare tutti i  branch remoti usa questo comando:

git branch -a

L'opzione -a (a alias per --all - tutto-) mostra tutti i branch, sia locali che remoti.

Ho due branch locali, chiamati master e test e due remoti, origin/master e origin/test.

L'opzione -r, un alias per --remotes (remoti), mostra solo i branch nei repository remoti.

Voglio eliminare il branch remoto origin/test , quindi uso il comando:

git push origin -d test

Risultato:

Il comando ha eliminato il branch test nel repository chiamato origin.

Il branch origin/test sul repository remoto non è più presente:

Conclusione

Ora sai come eliminare branch locali e remoti in Git.

Se vuoi saperne di più su Git, puoi vedere i seguenti corsi nel canale YouTube di freeCodeCamp:

• Per imparare come impostare Git,  per una panoramica dei comandi Git più importanti, e sul tipico flusso di lavoro di git: Git and GitHub for beginners - Crash course (in lingua inglese).
• Per esaminare più in profondità i branch e come funzionano: Git Branches Tutorial (in lingua inglese).

Grazie per aver letto questo articolo e buon apprendimento!

Git Branch

È una funzionalità che ti consente di creare nuovi branch di un progetto per provare idee, isolare nuove funzionalità, oppure sperimentare senza impatti sul progetto principale.

Sommario

• Visualizzare i branch
• Passare da un branch a un altro
• Creare un nuovo branch
• Rinominare un branch
• Eliminare un branch
• Confrontare dei branch
• Aiuto per git branch
• Ulteriori informazioni

Visualizzare i branch

Per visualizzare i branch in un repository Git esegui il comando:

git branch

Per vedere sia i branch tracciati su remoto che i branch locali esegui il comando:

git branch -a

Ci sarà un asterisco (*) a fianco del branch sul quale ti trovi attualmente.

Ci sono svariate opzioni che puoi specificare con git branch per vedere informazioni differenti. Per maggiori dettagli sui branch puoi usare l'opzione -v (oppure -vv o --verbose). L'elenco dei branch includerà a fianco del nome il valore SHA-1 e la riga di oggetto del commit per l'HEAD di ogni branch.

Puoi usare l'opzione -a (oppure --all) per mostrare tutti i branch di un repository, sia locali che remoti. Se vuoi vedere solo i branch remoti usa l'opzione -r (oppure--remotes).

Passare da un branch a un altro

Per passare da un branch a un altro branch esistente (azione di checkout) esegui il comando:

git checkout NOME-BRANCH

In genere Git non ti lascerà uscire per passare a un altro branch, a meno che la tua directory di lavoro sia pulita, in quanto perderesti qualsiasi modifica fatta che non sia stata soggetta a commit. Hai tre opzioni per gestire le tue modifiche:

1. sbarazzartene (vedi Git checkout per dettagli) oppure
2. effettuare un'azione di commit (vedi Git commit per dettagli) oppure
3. accantonarle (vedi Git stash per dettagli).

Creare un nuovo branch

Per creare un nuovo branch esegui il comando:

git branch NOME-NUOVO-BRANCH

Nota che questo comando crea solamente il nuovo branch. Per spostarti devi eseguire il comando git checkout NOME-NUOVO-BRANCH.

Esiste una scorciatoia per creare e passare direttamente a un nuovo branch. Puoi eseguire git checkout con l'opzione -b (per branch). I seguenti comandi fanno la stessa cosa:

# Metodo a due passaggi
git branch NOME-NUOVO-BRANCH
git checkout NOME-NUOVO-BRANCH

# Scorciatoia
git checkout -b NOME-NUOVO-BRANCH

Quando crei un nuovo branch, verranno inclusi tutti i commit del branch genitore. Il branch genitore è quello nel quale di trovi quando crei il nuovo branch.

Rinominare un branch

Per rinominare un branch esegui il comando:

git branch -m VECCHIO-NOME-BRANCH NUOVO-NOME-BRANCH

# Alternativa
git branch --move VECCHIO-NOME-BRANCH NUOVO-NOME-BRANCH

Eliminare un branch

Git non ti consente di eliminare il branch sul quale ti trovi attualmente. Prima devi passare a un altro branch, quindi eseguire il comando:

git branch -d BRANCH-DA-ELIMINARE

# Alternativa:
git branch --delete BRANCH-DA-ELIMINARE

Il branch nel quale passi prima dell'eliminazione fa la differenza. Git solleverà un errore se su tutte le modifiche nel branch che stai tentando di eliminare non è stata eseguita un'azione di merge all'interno del branch corrente. Puoi inibire questo comportamento e forzare Git a eliminare il branch con l'opzione -D (nota la lettera maiuscola) oppure usando l'opzione --force con -d oppure --delete:

git branch -D BRANCH-DA-ELIMINARE

# Alternativa
git branch -d --force BRANCH-DA-ELIMINARE
git branch --delete --force BRANCH-DA-ELIMINARE

Confrontare dei branch

Puoi confrontare dei branch con il comando git diff:

git diff PRIMO-BRANCH..SECONDO-BRANCH

Vedrai un risultato con testo colorato per evidenziare le modifiche tra i branch. Per tutte le righe modificate, la versione SECONDO-BRANCH avrà una riga verde che inizia con un  ”+”, e la versione PRIMO-BRANCH avrà una riga rossa che inizia con un  ”-“. Se non vuoi che Git visualizzi due righe per ogni modifica, puoi usare l'opzione --color-words (colora parole), nel qual caso Git mostrerà una riga con il testo eliminato in rosso e il testo aggiunto in verde.

Se vuoi vedere un elenco di tutti i branch sui quali è stata eseguita un'azione di merge per tutte le modifiche verso il branch corrente (in altre parole se il tuo branch corrente include tutte le modifiche fatte negli altri branch in elenco), esegui il comando git branch --merged.

Aiuto per Git branch

Se non ti ricordi come si usa un'opzione, oppure vuoi esplorare altre funzionalità del comando git branch, puoi eseguire uno qualunque di questi comandi:

git help branch
git branch --help
man git-branch

Ulteriori informazioni

• Il comando git merge
• Il comando git checkout
• Il comando git commit
• Il comando git stash
• Documentazione di Git: branch

Benvenuto nella nostra guida definitiva ai comandi git merge e git rebase. Questo tutorial ti insegnerà tutto quello che devi sapere per combinare più branch con Git.

Git Merge

Il comando git merge incorporerà nel tuo branch corrente tutte le modifiche fatte sul codice in un branch diverso, sotto forma di nuovo commit.

La sintassi del comando è la seguente:

git merge NOME-BRANCH

Per esempio, se stai attualmente lavorando in un branch chiamato dev e vorresti incorporare tutte le nuove modifiche fatte in un branch chiamato new-features, dovrai eseguire il seguente comando:

git merge new-features

Nota: Git non ti consentirà l'azione di merge se nel tuo branch corrente ci sono modifiche per le quali non hai ancora eseguito l'azione di commit. Per gestire queste modifiche puoi in alternativa:

• Creare un nuovo branch ed eseguire il commit delle modifiche

git checkout -b nome-nuovo-branch
git add .
git commit -m "<il tuo messaggio di commit>"

• Accantonarle

git stash               # accantona nell'area di stash
git merge new-features  # esegui le tue incorporazioni
git stash pop           # recupera nuovamente la modifiche nella tua alberatura di lavoro

• Abbandonare tutte le modifiche

git reset --hard        # elimina tutte le modifiche in sospeso

Git Rebase

L'azione di rebase di un branch in Git è un modo per spostare un intero branch in un altro punto nell'alberatura. L'esempio più semplice è spostare un branch più in alto nell'alberatura. Diciamo che abbiamo un branch che si discosta dal branch master al punto A:

        /o-----o---o--o-----o--------- branch
--o-o--A--o---o---o---o----o--o-o-o--- master

Quando esegui l'azione di rebase puoi spostarlo in questo modo:

                                   /o-----o---o--o-----o------ branch
--o-o--A--o---o---o---o----o--o-o-o master

Per effettuare il rebase, assicurati di avere tutti i commit che vuoi portarti nel rebase nel tuo branch master. Entra (checkout) nel branch per il quale vuoi effettuare l'azione di rebase ed esegui git rebase master (dove master è il branch verso il quale vuoi effettuare lo spostamento).

È anche possibile effettuare il rebase su un branch diverso, in modo che, per esempio, un branch basato su un altro branch (chiamiamolo "feature") sia spostato sul master:

                            /---o-o branch
           /---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master

Dopo git rebase master branch oppure git rebase master se sei entrato nel branch, otterrai:

           /---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master
                                  \---o-o branch

Git rebase interattivo nella console

Puoi usare git rebase con l'opzione -i, iniziando in questo modo un'azione interattiva nella console, con un elenco di commit che puoi scegliere, modificare, o scartare nel rebase:

• Digita git rebase -i HEAD~5, con l'ultimo numero che corrisponde a quanti commit vuoi esaminare all'indietro rispetto al più recente.
• Si aprirà il tuo editor predefinito con un testo che puoi iniziare a modificare
• Sul lato sinistro, puoi sovrascrivere la parola  pick con uno dei comandi qui sotto. Se vuoi raggruppare un commit con uno precedente e scartare il messaggio di commit, inserisci f al posto di pick per quel commit.
• Salva ed esci dall'editor di testo, a questo punto git inizierà a rieseguire i commit utilizzando i comandi di rebase specificati al punto precedente.
• Se il rebase si ferma, esegui gli aggiustamenti necessari, poi usa git rebase --continue fino a che l'azione di rebase non si conclude positivamente.
• In caso di successo, devi forzare l'invio delle tue modifiche con git push -f per aggiungere la versione dopo il rebase al tuo repository remoto.
• Se c'è un conflitto nell'azione di merge, ci diversi modi per sistemarlo, compreso il seguire le istruzioni di questa guida (in lingua inglese). Un modo è aprire i file in un editor di testo ed eliminare le parti di codice indesiderate. Poi usa git add <nome file> seguito da git rebase --continue. Puoi saltare il commit che causa conflitto digitando git rebase --skip, oppure interrompere l'azione di rebase digitando nella console git rebase --abort.

N.d.T.
La descrizione dei comandi di rebase nel testo che segue è stata tradotta per una migliore comprensione dell'esposizione, ma nella realtà è in lingua inglese.

pick 452b159 <messaggio per questo commit>
pick 7fd4192 <messaggio per questo commit>
pick c1af3e5 <messaggio per questo commit>
pick 5f5e8d3 <messaggio per questo commit>
pick 5186a9f <messaggio per questo commit>

# Rebase 0617e63..5186a9f onto 0617e63 (30 comandi)
#
# Comandi:
# p, pick = usa il commit
# r, reword = usa il commit, ma interrompi la modifica del  messaggio di commit.
# e, edit = usa il commit, ma interrompi l'amend e interrompi la modifica del messaggio di commit.
# s, squash = usa il commit, uniscilo al commit precedente e interrompi la modifica del messaggio di commit
# f, fixup = come "squash", ma scarta il messaggio di questo commit, pertanto non interrompe.
# x, exec = esegui il comando (il resto della riga) usando la shell
# d, drop = rimuovi il commit
#
# Queste righe possono essere riordinate, vengono eseguite dall'inizio alla fine. 
#
# Se elimini una riga di commit QUEL COMMIT VERRÀ PERDUTO.
#
# Tuttavia, se elimini tutto, l'azione di rebase verrà interrotte.
#
# Nota che i commit vuoti sono commentati (esclusi)

Conflitti in Merge

Un conflitto in merge è quando esegui commit in branch separati che modificano la stessa riga in maniera conflittuale. Se questo accade, Git non saprà quale versione del file mantenere e stamperà un messaggio di errore simile al seguente:

CONFLICT (content): Merge conflict in resumé.txt Automatic merge failed; fix conflicts and then commit the result.

Se osservi il file resumé.txt citato nel messaggio nel tuo editor testi, vedrai dove avviene il conflitto:

<<<<<<< HEAD
Address: 808 South Street
=======
Address: 505 North Street
>>>>>>> updated_address

Git ha aggiunto alcune righe al file:

• <<<<<<< HEAD
• =======
• >>>>>>> updated_address

Pensa a ======= come la riga che divide il conflitto. Tutto quello che sta fra <<<<<<< HEAD e ======= è il contenuto nel branch corrente al quale il riferimento HEAD sta puntando. Mentre tutto quello che sta tra  ======= e >>>>>>> updated_address è il contenuto nel branch che si sta incorporando, updated_address.

Git Merge vs Git Rebase

Sia git merge che git rebase sono comandi molto utili, e uno non è migliore dell'altro. Tuttavia ci sono alcune differenze molto importanti tra i due comandi che tu e la tua squadra dovreste tenere in considerazione.

Ogniqualvolta git merge viene eseguito, viene creato un commit di merge supplementare. Ogni volta che lavori nel tuo repository locale, avere troppi commit di merge potrebbe rendere confusa la cronologia dei commit. Un modo per evitare il commit di merge è usare invece git rebase.

git rebase è una funzionalità molto potente. Ciò detto, è anche rischiosa se non usata nel giusto modo. git rebase altera la cronologia dei commit, quindi usalo con cautela. Se il rebase viene fatto nel repository remoto, allora può creare molti problemi quando gli altri sviluppatori tentano di ottenere le ultime modifiche al codice dal repository remoto. Ricorda di eseguire git rebase in un repository locale.

Questo è tutto ciò che devi sapere per eseguire al meglio merge e rebase.

Il comando git commit salverà all'interno del repository locale tutte le modifiche presenti nell'area di stage, oltre a una breve descrizione inserita dall'utente .

I commit sono al centro dell'utilizzo di Git. Puoi pensare a un commit come un'istantanea del tuo progetto, in cui una sua nuova versione viene creata nel repository corrente. Due importanti caratteristiche dei commit sono:

• è possibile recuperare la modifiche inserite in un commit successivamente, oppure riportare il progetto a una versione referenziata da un certo commit (vedi Git checkout)
• se più commit modificano diverse parti del progetto, non si sovrascrivono anche se gli autori del commit non sono consapevoli l'uno dell'altro. Questo è uno dei vantaggi dell'utilizzo di Git rispetto a strumenti come Dropbox o Google Drive.

Opzioni

Esistono diverse opzioni che puoi includere con git commit. Tuttavia, questa guida coprirà solo le due opzioni più comuni. Per un elenco più esaustivo di opzioni, consulta la documentazione di GIT.

L'Opzione -m

L'opzione -m è quella più comune usata con git commit. La -m sta per messaggio. Quando si chiama git commit, occorre includere un messaggio. Il messaggio dovrebbe essere una breve descrizione delle modifiche comprese nel commit. Il messaggio dovrebbe essere alla fine del comando e deve essere racchiuso tra virgolette " ".

Un esempio di come usare l'opzione -m :

git commit -m "Il mio messaggio"

Il risultato nel tuo terminale dovrebbe essere circa questo:

[master 13vc6b2] Il mio messaggio
 1 file changed, 1 insertion(+)

NOTA: Se l'opzione -m non è stata passata al comando git commit, ti verrà presentata la richiesta di aggiungere un messaggio usando il tuo editor di testo predefinito – vedi "Usare messaggi di commit dettagliati" qui sotto.

L'Opzione -a

Un'altra popolare opzione è -a. La -a sta per all (tutto). Questa opzione fa sì che tutti i file modificati siano passati all'area di stage per il commit. Tuttavia se ci sono nuovi file non tracciati, con l'opzione -a non verranno considerati, in quanto sono soggetti all'azione di commit solo i file noti al repository Git.

Per esempio:

Diciamo che hai un file README.md che è già stato incluso in un commit al tuo repository. Se apporti modifiche a questo file, puoi usare l'opzione -a nel comando di commit per aggiungere le modifiche al tuo repository. Tuttavia, cosa succede se hai anche creato un nuovo file chiamatoindex.html che non hai ancora aggiunto al repository? L'opzione -a non lo porterà nell'area di stage, in quanto non esiste nel repository. Quando vengono aggiunti nuovi file, si dovrebbe usare il comando git add per passare i nuovi file nell'area di stage affinché possano essere successivamente soggetti all'azione di commit.

Un esempio di come usare l'opzione -a:

git commit -am “Le mie nuove modifiche”

Il risultato nel tuo terminale dovrebbe essere circa questo:

[master 22gc8v1] Le mie nuove modifiche
 1 file changed, 1 insertion(+)

Usare messaggi di commit dettagliati

Anche se git commit -m "messaggio di commit" va bene, può essere utile fornire informazioni più dettagliate e sistematiche.

Se l'azione di commit viene eseguita senza l'opzione -m, git aprirà il tuo editor di testo predefinito con un nuovo file, che include come commento un elenco di tutti i file/modifiche che saranno soggetti al commit. Poi puoi inserire il tuo messaggio di commit dettagliato (la prima riga viene considerata come oggetto del messaggio) e il commit verrà eseguito quando salvi/chiudi il file.

Ricorda che:

• È una pratica standard mantenere la lunghezza di ciascuna riga del messaggio di commit entro i 72 caratteri.
• Va benissimo, ed è addirittura consigliato, scrivere messaggi di commit su più righe.
• Puoi anche fare riferimento ad altre issue (problemi) o pull request (richieste di modifica) nel tuo messaggio di commit. GitHub alloca un numero di riferimento per tutte le issue e pull request. Quindi, se per esempio vuoi fare riferimento alla pull request #788, lo puoi fare sia nella riga di oggetto che nel corpo del messaggio.

L'opzione —amend

L'opzione --amend ti consente di modificare il tuo ultimo commit. Diciamo che hai appena eseguito un commit e ti accorgi di un errore nel messaggio che hai inserito. Puoi comodamente modificare il commit più recente usando il comando:

git commit --amend -m "un messaggio di commit aggiornato"

Se ti sei dimenticato di includere un file nel commit:

git add NOME-FILE-DIMENTICATO
git commit --amend -m "un messaggio di commit aggiornato"

# Se non devi cambiare il messaggio di commit, usa l'opzione --no-edit
git add NOME-FILE-DIMENTICATO
git commit --amend --no-edit

I commit prematuri avvengono continuamente nel corso del tuo sviluppo quotidiano. È facile dimenticare di passare un file all'area di stage o come formattare correttamente il tuo messaggio di commit. L'opzione --amend è un modo conveniente per correggere questi errori minori. Questo comando sostituirà il vecchio messaggio di commit con quello aggiornato specificato nel comando.

I commit modificati con l'opzione --amend sono in realtà commit nuovi e il commit precedente non sarà più nel tuo branch corrente. Quando lavori assieme ad altri, dovresti cercare di evitare di modificare un commit se quest'ultimo è già stato inviato al repository remoto.

Con --amend, una delle altre opzioni più utili che potresti usare è --author che ti consente di modificare l'autore dell'ultimo commit che hai eseguito. Immagina una situazione nella quale non hai propriamente impostato il tuo nome o email nella configurazione di git, ma hai già eseguito un commit. Con l'opzione --author puoi semplicemente modificarli senza resettare l'ultimo commit.

git commit --amend --author="John Doe <johndoe@email.com>"

L'opzione -v oppure —verbose

L'opzione -v oppure--verbose viene usata senza l'opzione -m e può essere utile quando vuoi inserire un messaggio di commit con il tuo editor testi predefinito ed essere in grado di vedere le modifiche che hai effettuato per questo commit. Il comando apre il tuo editor di testo predefinito con un modello di messaggio di commit assieme a una copia delle modifiche effettuate per questo commit. Le modifiche, o diff, non saranno incluse nel messaggio di commit ma ti offrono un buon metodo per fare riferimento alle tue modifiche mentre le descrivi nel messaggio di commit.

Come raggruppare più commit in uno

Questa è una caratteristica fantastica di rebase che può essere utilizzata in modalità interattiva. Per raggruppare gli ultimi n commit in uno, esegui il comando seguente:

git rebase -i HEAD~n

Questo farà aprire l'editor di testo con un contenuto simile al seguente:

pick commit_1
pick commit_2
pick commit_3
...
pick commit_n
# Alcuni commenti

Lascia da parte il primo commit, e per i restanti commit che vuoi raggruppare modifica il corrispondente testo da pick a squash. Salva ed esci dall'editor.

Per esempio se avessi voluto raggruppare gli ultimi tre commit, avresti prima eseguito git rebase -i HEAD~3 quindi avresti modificato i tuoi commit in questo modo:

pick dd661ba Commit 1
squash 71f5fee Commit 2
squash f4b4bf1 Commit 3

Se hai già inviato i commit a un repository remoto prima di raggrupparli, li devi nuovamente inviare al remoto, con l'opzione -f , altrimenti git darà un errore.

È fortemente consigliato che tu legga le informazioni inserite nel file aperto nell'editor in quanto ci sono parecchie cose che potresti fare.

Ulteriori Informazioni:

• Documentazione di Git: commit