Nei nostri tutorial precedenti per il software di controllo della versione git, abbiamo imparato i comandi di base essenziali per l’uso di git, come così come lavorare con GitHub.com per creare un repository e inviare il codice del nostro progetto al sito web.
Ora è il momento di iniziare a lavorare effettivamente con GitHub (e git) nel modo in cui dovrebbero essere usato: apportare le modifiche al progetto in modo sicuro da un lato e unirle di nuovo nel progetto originale una volta che si sono dimostrate corrette. O almeno non disastroso.
Ormai hai capito che git salva ogni versione del tuo progetto come un’istantanea del codice esattamente come era nel momento in cui l’hai commesso. Essenzialmente la creazione di una sequenza temporale delle versioni di un progetto mentre procede, in modo da poter tornare a una versione precedente in caso di disastro.
Il modo in cui git e GitHub gestiscono questa sequenza temporale, specialmente quando più più di una persona sta lavorando al progetto e sta apportando modifiche – è utilizzando le filiali. Un ramo è essenzialmente un insieme univoco di modifiche al codice con un nome univoco. Ogni repository può avere uno o più rami. Il ramo principale – quello in cui tutte le modifiche alla fine vengono fuse di nuovo e si chiama master. Questa è la versione funzionante ufficiale del tuo progetto, e quella che vedi quando visiti il repository del progetto su github.com/yourname/projectname.
Non scherzare con il master. Se apporti modifiche al ramo principale di un progetto di gruppo mentre altre persone ci stanno lavorando, le tue modifiche al volo si propagheranno per influenzare tutti gli altri e molto rapidamente ci saranno conflitti di fusione, pianto, strappi di indumenti, e piaghe di cavallette. È così serio.
Perché è così importante non scherzare con il maestro? Una parola: il ramo principale è distribuibile. È il tuo codice di produzione, pronto per essere lanciato nel mondo. Il master branch è pensato per essere stabile, ed è il contratto sociale del software open source di non spingere mai e poi mai qualcosa al master che non sia testato o che rompa la build. L’intero motivo per cui GitHub funziona è che è sempre sicuro lavorare dal master.
Branching Out
Invece, tutti usano i rami creati dal master per sperimentare, apportare modifiche e aggiunte e cambiamenti , prima di riportare quel ramo nel master una volta che sono stati approvati e si sa che funzionano. Il master viene quindi aggiornato per contenere tutte le nuove cose.
Per iniziare a lavorare su qualcosa di nuovo in un progetto, o per cambiare cose esistenti, crei un ramo dal ramo master stabile. Continuiamo a lavorare con il progetto di esempio creato per il nostro tutorial precedente, buon vecchio studious_octo_carnival. Per favore ora apri la tua versione sul tuo computer e cd nella directory.
Passaggio 1: fai l’inventario.
Prima di creare nuovi rami, vogliamo controllare eventuali altri rami esistenti . Conosciamo il maestro, ma chissà cosa potrebbero combinare i nostri collaboratori al progetto, quelle scimmie dispettose? Quindi possiamo visualizzare tutti i rami esistenti digitando “git branch -a” nel terminale, che dice a git che vogliamo vedere TUTTI i rami in questo progetto, anche quelli che non sono nel nostro spazio di lavoro locale.
Questo restituisce l’output che vedi nell’esempio di codice seguente. Il suo aspetto può variare leggermente a seconda del sistema operativo e dell’applicazione del terminale, ma le informazioni sono in definitiva le stesse. L’asterisco accanto a “master” nella prima riga dell’output indica che siamo attualmente in quel ramo. La seconda riga ci dice che sul nostro remoto, chiamato origin, c’è un singolo ramo, chiamato anche master. (Ricorda che il nostro telecomando è il repository GitHub per questo progetto).
Passaggio 2: crea un nuovo ramo
Ora che sappiamo come visualizzare i rami, creiamone uno! Tenete a mente mentre procediamo che abbiamo il nostro ramo principale, il nostro progetto originale. Ora creeremo una nuova versione del progetto, un ramo, con cui giocare e apportare modifiche localmente sul nostro computer, mentre la versione originale del progetto, il master, rimane al sicuro indisturbata su GitHub. Diamo al nuovo ramo un nome descrittivo per ricordarci cosa intendiamo fare mentre ci lavoriamo. In questo caso, sarà un semplice “Hello World”, quindi chiamiamolo hello_octo.
Per creare questo nuovo ramo, digita “git checkout -b branchNameHere” (quindi, nel nostro caso, “git checkout -b hello_octo”).
Supponendo che nessun altro abbia già creato un ramo chiamato “hello_octo”, git restituisce “Switched to a new branch ‘hello_octo’.” (Nel caso in cui esista già un ramo con quel nome, git ci dirà invece “fatale: un ramo chiamato ‘hello_octo’ esiste già.” Non è un grosso problema, fai di nuovo git checkout -b con una nuova variazione del nome).
Possiamo anche usare il comando git checkout per passare avanti e indietro tra i nostri due rami. Digita “git checkout branchName” per passare a quel ramo.Quindi, “git checkout master” ti porta a master mentre “git checkout hello_octo” ti riporta al ramo hello_octo.
Se provi a passare a un ramo che non esiste, come “git checkout hello_kitty”, git ti farà sapere che è impossibile:
Come fa git a sapere su quale ramo ti trovi attualmente? Git osserva sempre ciò che fai e mantiene un puntatore speciale chiamato HEAD. Come l’ago di una bussola punta sempre a nord, HEAD indica sempre ramo locale in cui ti trovi attualmente.
(Avremmo anche potuto creare il nostro ramo utilizzando il comando git “git branch branchNameHere”, e poi passare ad esso con git checkout. Tuttavia, la piccola scorciatoia con il “-b” in “git checkout -b branchNameHere” crea entrambi il ramo E passa ad esso. Non posso dirti quanti programmatori nuovi di git generano messaggi di errore e frustrazione perché semplicemente non si sono ricordati di passare al loro nuovo ramo dopo aver creato i t. Quindi, ci atteniamo a git checkout -b, mmmkay?)
Apportare modifiche al nostro ramo di lavoro
Ora che abbiamo più rami – il nostro ramo di lavoro su cui apportare modifiche, e il nostro ramo principale rimane al sicuro indisturbato: possiamo metterci al lavoro. Nel nostro scenario, utilizzeremo il nostro ramo “hello_octo” per apportare e testare le nostre modifiche, quindi trasferirle nuovamente al ramo principale su GitHub.
Ricordati di assicurarti di essere sul tuo ramo funzionante, e non master, con il buon vecchio git branch -a.
Passaggio 3. Crea un nuovo file vuoto, denominato “hello_octo_world”:
(Questo file vuoto è solo a scopo dimostrativo, quindi non preoccuparti che non ci sia nome / tipo di estensione del file).
Dato che è nuovo di zecca, giusto ora questo file è solo sul tuo ramo. Utilizza il comando “ls” per visualizzarlo:
Tuttavia, ricorda che siamo nel nostro ramo di lavoro, hello_octo, dove abbiamo creato questa nuova cosa. Il master non sa nulla di nessun hello_octo, perché è isolato in modo sicuro da qualsiasi modifica volente o nolente che stiamo facendo qui sul ramo di lavoro. È sempre lo stesso master serenamente immutato con cui abbiamo iniziato:
Passaggio 4: prepara il nuovo file e invia il nostro nuovo file al ramo funzionante.
Ora è il momento per mettere in scena (aggiungere) e salvare il nostro nuovo file sul ramo di lavoro. (Suona familiare?). Questo collegherà questa nuova entità al ramo di lavoro in preparazione per spostarlo eventualmente al master. Questo file ora esiste nel ramo hello_octo; come abbiamo visto sopra, attualmente non esiste nel ramo principale.
A questo punto hai appena preso un istantanea delle modifiche alla filiale In un progetto del mondo reale, è probabile che ci siano più cambiamenti e lavoro da fare. Ora è quando andrai a farlo, impegnandoti lungo il percorso in punti logici. Ricorda che, su GitHub, i commit rappresentano i tuoi salvataggi consecutivi. Ogni commit ha un messaggio di commit associato, che è una descrizione che spiega specificamente cosa hai fatto lì e perché. I messaggi di commit catturano la cronologia delle tue modifiche, così in futuro tu, così come altri collaboratori del progetto, potrete capire cosa avete fatto e perché.
Unire il codice tra le filiali
Una volta che noi sono finalmente finite con tutte le modifiche e le aggiunte – e tutto funziona * – è ora di unire. La parte interessante arriva dopo che siamo tornati al nostro ramo principale (che – dillo con me! – che facciamo con “git checkout master”). “Hello_octo_world” sembra mancare, ma non lo è – attualmente esiste nel nostro lavoro e siamo nel nostro ramo principale. Te lo mostro di nuovo perché è al centro della comprensione dei rami in git:
Ora: in questo esercizio , “hello_octo_world” rappresenta qualsiasi modifica a qualsiasi file (o l’aggiunta di un file completamente nuovo) che ha superato tutti i test sul nostro ramo di sviluppo ed è pronto per essere in produzione. Il processo di spostamento del codice tra i rami (spesso dallo sviluppo al produzione) è noto come unione.
Molto importante: durante la fusione, dobbiamo essere sul ramo in cui vogliamo fonderci. Fondamentalmente, diremo a git, “Vedi quella nuova cosa? Va bene portarlo qui adesso. “
Passaggio 5: unisci le modifiche al ramo di lavoro
In questo caso, poiché vogliamo unire dal nostro ramo di lavoro, dove” hello_octo_world ” esiste, per il nostro ramo principale, dobbiamo essere sul ramo principale.
Una volta sul ramo principale, tutto ciò che dobbiamo fare è eseguire il comando di unione. Il modo migliore per farlo è digitare ” git merge –no-ff ”- l’ulteriore” –no-ff “dice a git che vogliamo conservare tutti i messaggi di commit prima dell’unione. Ciò renderà più facile tenere traccia delle modifiche in futuro:
Tornare a GitHub
L’ultima cosa che dobbiamo fare ora è far sapere a GitHub che ci siamo dati da fare master quaggiù sul nostro ambiente di sviluppo locale.
In altre parole, è il momento di git push. Hai capito!
L’output di git conferma che l’unione dal tuo ramo di sviluppo al ramo principale nel tuo ambiente locale, è stato ora copiato sul server remoto: “master → master”.
E questo è tutto! Abbiamo creato con successo un ramo di lavoro separato dal master. Abbiamo apportato delle modifiche. Messo in scena e eseguito il commit di tali modifiche. Quindi li abbiamo uniti di nuovo nel master sul nostro ambiente di lavoro locale. Quindi, infine, abbiamo trasferito tutto su GitHub in modo che tutte le versioni del nostro progetto siano le stesse, ovunque!
Una nota finale
Alcune pulizie è in ordine ora: poiché abbiamo unito con successo il nostro ramo hello_octo, non ne abbiamo più bisogno. Per eliminare un ramo unito, digita semplicemente “git branch -d branchName”:
Nessun problema: se tenti di eliminare accidentalmente un ramo che non è stato ancora unito, git genererà un errore.
Allora! Finora abbiamo utilizzato un progetto di esempio estremamente semplificato, perché a questo punto la cosa più importante è capire e assimilare il flusso di lavoro git. C’è molto di più nell’unione di questo nel mondo reale, ad esempio, cosa succede se ricevi messaggi di errore perché la tua unione ha conflitti? Nessun problema, nuovo git-ster, ci arriveremo.
I tuoi compiti: crea (“touch”) altri nuovi file nel progetto di esempio ed esercitati ad apportare modifiche, mettere in scena, eseguire il commit e infine unirli indietro. Fai attenzione a capire dove sta puntando la tua TESTA, cioè qual è il tuo ramo attuale. Applica le modifiche solo al tuo ramo di lavoro.
Perché, ricorda: Non. Mess. Con. Il. Maestro .