Flussi di lavoro e utilizzo avanzati di Git

Di recente abbiamo esaminato le basi per iniziare a utilizzare Git per il controllo del codice sorgente nei tuoi progetti. Anche se questo è un ottimo punto di partenza, ci sono un sacco di altri comandi e flussi di lavoro Git che ti aiuteranno a capire come usare Git nel tuo lavoro di codifica quotidiano.

Git flussi di lavoro

Quando ho iniziato a usare Git, ho pensato di sapere come usarlo correttamente. Il mio approccio ideale era quello di apportare tutte le modifiche in un punto senza branch, quindi eseguirne il commit nel repository e continuare a lavorare.

Sebbene fosse meglio che non usare il controllo della versione, mi ci è voluto un po' per rendermi conto che non stavo usando la maggior parte della potenza fornita da Git. Per far funzionare Git per me, avevo bisogno di una strategia per ramificare e unire le mie modifiche.

Poi è uscito git-flow e l'ho adottato come mia strategia. Ricordo ancora che mi sentivo come se stessi sbirciando dietro una tenda dove si trovavano gli straordinari sviluppatori. Ora ho avuto un'idea di come funzionavano e potevo iniziare a diventare uno di loro.

Ma git-flow non si adatta a tutti gli scenari, quindi mentre lo esamineremo daremo anche un'occhiata ad alcuni altri metodi per mantenere organizzati i tuoi progetti Git, incluso il modo in cui gestisco i miei progetti come sviluppatore solitario.

git-flusso

Guardando git-flow ora, riconosco che il panorama del software è cambiato notevolmente in 10 anni e git-flow potrebbe non essere l'opzione migliore per il tuo team. Quando è stato scritto git-flow, era raro distribuire un'applicazione più volte in un giorno. Invece, probabilmente hai eseguito un numero di versione principale e rilasciato ogni pochi mesi o settimane se facevi parte di un team particolarmente agile.

Diamo un'occhiata a cos'è git-flow.

Se vuoi vedere la spiegazione approfondita completa con grafici e comandi Git per Git Flow, dovresti leggere questo post.

In git-flow, due rami hanno una vita infinita. Innanzitutto, main che dovrebbe riflettere il codice pronto per essere distribuito nell'ambiente live/di produzione.

In secondo luogo, abbiamo il nostro ramo di sviluppo. Questo ramo dovrebbe avere le ultime modifiche pronte per la prossima versione del nostro software. Quando le modifiche in sviluppo sono pronte per essere implementate nella nostra applicazione live, le uniamo al ramo principale e le tagghiamo con il numero di versione che corrisponde al numero di versione.

Al di fuori dei due rami principali, ci sono tre tipi di rami di supporto.

1. Caratteristica

Un ramo di funzionalità può essere creato solo dal ramo di sviluppo. Deve essere nuovamente unito al ramo di sviluppo. La denominazione può essere qualsiasi cosa descrittiva della funzione su cui stai lavorando.

Quando il lavoro è pronto per il rilascio successivo, viene nuovamente unito al ramo di sviluppo dove attende il tempo di rilascio.

2. Rilascio

I rami di rilascio sono costituiti dal ramo di sviluppo e devono fondersi di nuovo sia in sviluppo che in principale. Assegna un nome a un ramo di rilascio con la convenzione release-x. In pratica, questo di solito significa nominare un ramo con il numero di versione che intendi utilizzare in questo modo: release-2.2

Utilizzi un ramo di rilascio come un modo per eseguire la preparazione finale per rilasciare il software. Ciò può includere aumentare il numero di versione dei file, assicurarsi che le traduzioni siano state eseguite o controlli finali del codice.

3. Correzione rapida

Il ramo dell'hotfix viene creato dal ramo principale e viene utilizzato per contenere le modifiche che devono essere gestite immediatamente nell'applicazione live. Questo potrebbe essere un bug che deve essere risolto o un problema di sicurezza che deve essere affrontato.

Una volta che il problema è stato risolto e distribuito al tuo ramo principale, taggherai il tuo codice con il numero di versione corretto.

Il motivo principale per cui i team non utilizzano git-flow ora è che il modo in cui rilasciamo il software è cambiato. Invece di versioni più grandi meno spesso, è possibile rilasciare una modifica a un'applicazione alcune volte al giorno. So che invio il lavoro ai siti dei miei clienti molte volte alla settimana non appena è pronto. Non eseguiamo i numeri di versione del sito, continuiamo a migliorarlo.

git-flow standard non è pensato per adattarsi a questo.

Flusso Github

La seconda opzione che molte persone usano è Github Flow.

L'unica grande regola di Github Flow è che qualsiasi codice si trovi nel ramo principale può essere distribuito in qualsiasi momento perché è pronto per la produzione.

Tutti i rami vengono creati dal ramo principale con un nome descrittivo per qualsiasi cosa tu stia facendo.

Una volta che hai le modifiche pronte, crei una richiesta pull.

Le richieste pull dicono agli altri che lavorano sullo stesso codice che il lavoro che stai facendo è pronto per essere rivisto prima che tali modifiche vengano unite nel codice principale.

Dopo aver inviato una richiesta pull, il team con cui collabori può esaminare le modifiche e fornire feedback. Se la richiesta pull è considerata pronta per l'unione, viene unita al ramo principale per il tuo progetto.

Uno svantaggio del flusso Github per un singolo sviluppatore o un team molto piccolo è che l'amministrazione di una richiesta pull può creare un sovraccarico aggiuntivo nella gestione del progetto. Questo è il motivo per cui non li uso nel mio lavoro.

Come utilizzo i flussi di lavoro Git con i progetti dei clienti

Nel mio lavoro con i clienti, di solito sono l'unico a scrivere codice ogni giorno per un progetto. Il mio cliente può aggiornare i plugin di WordPress o modificare alcuni CSS, ma non eseguono alcun lavoro di codifica importante. Ciò significa che se andassi con il flusso di Github, rivedrei le mie richieste pull che creano solo grattacapi di gestione aggiuntivi. Diamo un'occhiata al sistema che uso, che ha una certa somiglianza sia con git-flow che con Github.

Ho due rami principali chiamati main e staging. Il ramo principale tiene traccia con qualsiasi codice sia attualmente in esecuzione nel sito di produzione. Il ramo di staging tiene traccia di tutto ciò che viene testato sul sito di staging che utilizziamo per testare le modifiche prima di inviarle al sito live.

Ogni ramo viene creato dal ramo principale. Alle nuove funzionalità viene assegnato un nome come questo: feature/32-new-feature. In questo contesto, il numero 32 corrisponde al numero del ticket nel nostro sistema di gestione dei progetti e le parole che seguono sono una breve descrizione di ciò su cui si sta lavorando. Le correzioni di bug vengono denominate in modo simile, bug/20-bug-name.

Ogni ramo creato viene prima unito al nostro ramo di staging, quindi, una volta approvato dal cliente o testato da me stesso, viene unito al ramo principale. Quel flusso di lavoro potrebbe assomigliare a questo.

# unisci la funzione nel ramo di staging

git merge feature/32-nuove-funzioni

# distribuire e testare la funzionalità

git checkout principale

git merge feature/32-nuove-funzioni

# distribuire la funzionalità al sito live

Nei miei progetti, ho impostato la distribuzione continua, il che significa che ogni volta che inserisco il codice in main, viene inviato automaticamente al sito live. Lo stesso processo è impostato per il ramo di staging.

Se stessi lavorando con un team in grado di controllare il mio codice in un flusso di lavoro di richiesta pull, userei questo sistema perché funziona bene in un team. Per uno sviluppatore che lavora principalmente da solo, è semplicemente il sovraccarico di gestione che rallenterà il flusso di lavoro.

Comandi Git avanzati che utilizzo

Ora che abbiamo un'idea di come possiamo usare Git in un flusso di lavoro pratico, diamo un'occhiata ai comandi più avanzati che saranno necessari per farlo accadere. Uso ciascuno di questi comandi almeno alcune volte alla settimana mentre lavoro con il codice del mio cliente.

Anche se utilizzerai un'applicazione GUI (ne ho menzionate alcune buone nel mio ultimo post su Git) è comunque importante avere una comprensione di ciò che sta accadendo in background. Molte volte ho dovuto lavorare tramite terminale per risolvere un problema creato da un'applicazione Git GUI.

Aggiunta di modifiche per riga

L'unico comando che ha reso l'utilizzo di Git tramite il clic del terminale per me è stato git add -p. Fino a quando non ho imparato questo comando, ho usato le applicazioni della GUI perché avrei apportato modifiche al mio codice ma volevo suddividere righe specifiche in commit diversi in modo da poter spiegare perché avevo apportato una modifica. Per fare ciò ho usato una GUI per selezionare le righe, ma git add -p ti guida attraverso un'interfaccia interattiva per aggiungere modifiche in blocchi.

Lo uso molte volte ogni giorno.

Tieni traccia del ramo Git remoto

Se stai abbattendo un repository esistente e hai branch come main e staging di cui devi tenere traccia ma esistono già, devi dire alle tue versioni locali dei branch di tenere traccia di quelle versioni remote del branch.

Ci sono alcuni modi per farlo.

# Imposta a monte quando si passa al telecomando

git push -u origin staging

# Impostare a monte

# presuppone che tu sia sul ramo che desideri attualmente tracciare con il telecomando

git branch -u origin/staging

git branch --set-upstream-to=origine/staging

# Se non sei sul ramo che vuoi tracciare, quindi specifichi il ramo alla fine

git branch --set-upstream-to=origine/staging staging

Salva le modifiche senza commetterle

A volte sarai nel bel mezzo di un lavoro che non è ancora pronto per essere impegnato, ma devi salvarne lo stato. Ecco dove git stash è utile. Questo comando nasconde le modifiche per te rimuovendo le modifiche. Puoi riaverli usando git stash pop. Ci sono alcuni altri comandi per rendere utile stash, ma quelli sono i due che uso regolarmente.

Esegui un commit Git specifico

A volte devi inserire un commit specifico nel tuo lavoro attuale. Con un HEAD pulito (non hai ancora apportato modifiche) puoi inserire un commit specifico con git cherry-pick . Puoi trovare la documentazione completa su git cherry-pick qui.

Per ogni commit Git costruisce una lunga sequenza di lettere e numeri che viene chiamata Git Object e comunemente indicata come SHA. Poiché ogni commit ne ottiene uno, puoi fare riferimento a un commit con il suo valore SHA. Ulteriori informazioni sugli oggetti Git.

Butta via i cambiamenti che non ti servono

Ad un certo punto in qualsiasi progetto, apporteremo modifiche e poi ci rendiamo conto che non funziona e dobbiamo semplicemente scartarle e ricominciare da capo. Invece di provare semplicemente ad annullare fino a quando non torniamo dove vogliamo essere, possiamo usare il seguente comando Git per rimuovere tutte le modifiche che non sono state ancora tracciate.

git reset --hard

Il comando precedente ripristinerà il codice al commit più recente sul ramo su cui stai attualmente lavorando. Potremmo anche usare un <#commitSHA> con questo comando per ripristinare un commit specifico se volessimo tornare a uno stato precedente all'ultimo commit. Forse lo useresti per ripristinare il checkout del ramo iniziale perché l'intero ramo di lavoro non è qualcosa che vuoi mantenere, ma avevi già tracciato parte del lavoro.

Per fare un ulteriore passo avanti, possiamo eliminare tutti i file o le directory che non sono ancora stati tracciati in git con il comando git clean.

git clean -fd: i flag f e d dicono a git di buttare via file e directory che non sono tracciati.

Rimuovi rami

Ogni settimana o due guardo i risultati di un comando git status e scopro di avere troppi rami per capire ragionevolmente cosa sta succedendo nel mio repository. Ciò significa che posso rimuovere tutti i rami che corrispondono a ticket che sono stati risolti con i seguenti comandi.

# rimuove la versione locale

git branch -d $branchname

#rimuove il ramo sul mio telecomando

git push $nomeremoto --delete $nomediramazione

Usa il controllo della versione

Anche se potresti non essere un esperto di tutti i comandi Git che utilizzerai, una cosa importante da ricordare è che dovresti usare il controllo della versione . Anche se sei l'unica persona a lavorare su un progetto, l'utilizzo di Git e un flusso di lavoro Git ti aiuterà a mantenere organizzati i tuoi progetti. Non dovrai premere CTRL + Z finché non avrai ripristinato il tuo lavoro dopo aver scritto il codice che non ha funzionato.

Potrai fidarti del tuo sistema e continuare a produrre lavoro per i tuoi progetti.

Prova l'hosting WordPress completamente gestito

Hai bisogno di un hosting ottimizzato per WordPress? Dai un'occhiata ai piani di hosting WordPress completamente gestiti di Nexcess oggi.