Flussi di lavoro Git per professionisti: una buona guida Git

Git può supportare il tuo progetto non solo con il controllo della versione, ma anche con la collaborazione e la gestione dei rilasci. Comprendere come i modelli di flusso di lavoro Git possono aiutare o ostacolare un progetto ti darà le conoscenze per valutare e adattare efficacemente i processi Git del tuo progetto.

In questa guida isolerò i modelli di processo di sviluppo software che si trovano nei flussi di lavoro Git comuni. La loro conoscenza ti aiuterà a trovare una direzione quando ti unisci, crei o cresci un team di sviluppo. I pro e i contro per determinati tipi di progetti o team verranno evidenziati negli esempi di flusso di lavoro che esploriamo, in modo che tu possa scegliere ciò che potrebbe funzionare bene per il tuo scenario.

Questa non è un'introduzione all'uso di Git. Ci sono già favolose guide e documentazione per questo. Trarrai vantaggio da questa guida al flusso di lavoro Git se hai già esperienza all'interno di un team di sviluppo di applicazioni e hai affrontato intoppi del flusso di lavoro, implosioni di integrazione o git-tastrofi: questi schemi potrebbero far luce su come evitare queste situazioni in futuro.

Collaborazione

In termini di processo Git, la collaborazione riguarda spesso flussi di lavoro ramificati. Pensare in anticipo a come intreccerai gli alberi dei commit ti aiuterà a ridurre al minimo i bug di integrazione e a supportare la tua strategia di gestione dei rilasci.

Ramo di integrazione

Usa un ramo di integrazione con i team di sviluppo software che lavorano per distribuire una raccolta di contributi nella produzione come un'unica entità. Ciò si oppone ai team che si concentrano sulla distribuzione delle funzionalità individualmente. Spesso i team potrebbero voler fare quest'ultimo, ma le limitazioni pratiche impongono un processo che raggruppa i loro sforzi e il team finisce per fare il primo, quindi assicurati di rivedere il tuo effettivo utilizzo di Git per vedere se potresti trarre vantaggio dall'utilizzo di questo tipo di collaborazione modello.

Questo modello di flusso di lavoro è un utile punto di sosta quando il rischio di integrare più rami è sufficientemente alto da giustificare il test dei contributi combinati nel loro insieme.

Un ramo di integrazione di solito consiste in una caratteristica principale e diversi contributi minori da distribuire insieme. Metti un ramo di integrazione attraverso il processo del tuo team di sviluppo (domande e risposte e test di accettazione, ad esempio). Inserisci i commit minori su di esso per portarlo vicino alla produzione, quindi usa un ramo dell'ambiente o un ramo di rilascio (discusso di seguito) per prepararlo per la distribuzione.

Tieni presente che i contributi sul ramo di integrazione devono essere uniti nella fase di rilascio successiva prima che un'altra funzionalità principale possa essere unita al ramo di integrazione, altrimenti stai mescolando funzionalità in diverse fasi di completamento. Questo inibirà la tua capacità di rilasciare ciò che è pronto.

Rami tematici

I team vorranno usare i rami degli argomenti se è importante mantenere i loro alberi di commit in uno stato che possa essere facilmente letto o che le singole funzionalità siano ripristinate. I rami degli argomenti indicano che i commit possono essere sovrascritti (usando un push forzato) per ripulire la loro struttura ed essere ridotti a un commit di funzionalità.

I rami degli argomenti sono spesso di proprietà di un singolo collaboratore, ma possono anche essere uno spazio designato su cui un team può sviluppare una funzionalità. Altri contributori sanno che questo tipo di ramo potrebbe avere il suo albero di commit riscritto in qualsiasi momento, e non dovrebbero cercare di mantenere sincronizzati i loro rami locali con esso.

Senza utilizzare i rami degli argomenti nel flusso di lavoro Git, sei limitato a rispettare i commit che invii a un ramo remoto. Forzare il push di un nuovo albero di commit su un ramo remoto potrebbe far arrabbiare altri contributori che fanno affidamento sull'integrità mantenuta del ramo con cui si sincronizzano.

È probabile che tu utilizzi già questo modello di flusso di lavoro senza rendertene conto, ma vale la pena avere un insieme condiviso di definizioni tra i team per rafforzare le pratiche dietro di loro. Ad esempio, potresti scoprire che la convenzione di anteporre il nome del ramo con le iniziali del creatore del ramo aiuta a segnalare quali sono i rami dell'argomento. In ogni caso, spetta al tuo team decidere le convenzioni interne.

NON utilizzare rami di argomenti su repository pubblici, causerai una miriade di conflitti per chiunque abbia sincronizzato i propri rami locali con un ramo di argomenti a cui è stato riscritto l'albero dei commit.

Forchetta

I progetti open source prosperano utilizzando questa funzionalità originata da Github. Il fork autorizza i gestori del repository con un gateway forzato rispetto al push diretto a un ramo del repository di origine, ma soprattutto facilita la collaborazione. Wahoo!

Potresti trovarti nello scenario in cui anche la creazione di un fork di un repository privato soddisfa le tue esigenze. L'impostazione del repository di origine in sola lettura per i contributori del repository fork e il rollio con le richieste pull offre gli stessi vantaggi offerti dalla community open source. I team di diverse organizzazioni possono lavorare in modo efficace utilizzando un fork che può essere la piattaforma per la comunicazione e l'adesione alle politiche di progetto.

Il modello di flusso di lavoro fork offre ai team il proprio spazio per lavorare in qualsiasi modo siano abituati con un unico punto di integrazione tra i due repository: una richiesta pull. La comunicazione eccessiva è fondamentale nella descrizione della richiesta pull. I team hanno avuto flussi di comunicazione separati prima dell'emissione di una richiesta pull e l'evidenziazione delle decisioni già prese accelererà il processo di revisione.

Ovviamente uno dei vantaggi del flusso di lavoro del fork è che puoi indirizzare i commenti ai contributori del repository di origine, poiché le autorizzazioni scendono a cascata. Dal punto di vista del repository di origine, hai il controllo per eliminare i fork quando non sono più necessari.

Assicurati di utilizzare uno strumento che faciliti il ​​fork e pull delle richieste per sfruttare questo schema. Questi strumenti non si limitano a Github: altre scelte popolari sono Bitbucket e GitlLab. Ma ci sono molti altri servizi di hosting del flusso di lavoro Git che avranno queste funzionalità (o simili). Scegli quale servizio funziona meglio per te.

NON utilizzare un fork di un repository privato per ogni membro di un team. I numerosi repository biforcati possono rendere difficile la collaborazione di più membri sullo stesso ramo di funzionalità e mantenere tutti questi repository sincronizzati può diventare soggetto a errori a causa del numero di parti mobili. I progetti open source hanno membri del team principale con accesso push al repository di origine che riduce questo sovraccarico.

Clone

Una strategia di outsourcing comune consiste nell'avere "posti" di contributo su un progetto che può essere occupato da più sviluppatori di software. Spetta alla società di outsourcing gestire la propria pipeline di risorse per fornire orari contrattuali, i problemi che devono affrontare sono come integrare, formare e mantenere un pool di sviluppatori per i progetti di ciascun cliente.

L'utilizzo di un clone del repository del progetto crea un terreno di formazione e comunicazione isolato per consentire al team in outsourcing di gestire i propri contributi, applicare le politiche e sfruttare la condivisione delle conoscenze, il tutto sotto l'occhio vigile del team di sviluppo del cliente. Una volta che un contributo è ritenuto conforme agli standard e pronto per il repository principale, può essere inviato a uno dei repository di origine rami remoti e integrato come di consueto.

Alcuni progetti hanno grandi aspettative nel seguire le loro convenzioni di codifica e definire standard di flusso di lavoro Git per contribuire al loro repository. Può essere scoraggiante lavorare in questo ambiente finché non hai imparato le basi, quindi lavora insieme come una squadra per ottimizzare il tempo di entrambe le parti.

NON creare una copia ospitata del repository del cliente senza il suo permesso, potresti rompere un accordo contrattuale, verifica in anticipo che questa pratica andrà a beneficio del progetto con il cliente.

Gestione del rilascio

I passaggi tra il passaggio dalla collaborazione al rilascio inizieranno in punti diversi all'interno del processo di sviluppo per ciascun team. In genere, non si desidera utilizzare più di un modello Git di gestione dei rilasci. Vuoi avere il flusso di lavoro più semplice possibile che consentirà al tuo team di fornire risultati efficaci.

Filiali dell'ambiente

Il processo di sviluppo del software può essere supportato da diversi ambienti per aiutare con la garanzia della qualità prima di essere distribuito in produzione. I rami dell'ambiente imitano le fasi di questo processo: ogni fase corrisponde a un ramo e i contributi fluiscono attraverso questi in una pipeline.

I team che eseguono questi processi hanno spesso ambienti applicativi impostati per ogni fase della pipeline, ad esempio "QA", "Staging" e "Produzione". In questi casi l'infrastruttura è in atto per supportare il personale che è responsabile della firma di una funzionalità o di un contributo per la propria parte di ciò che significa essere pronti per la produzione (ad es. test esplorativi, QA, test di accettazione), prima di spostarlo nella persona successiva fase. Questo offre loro un posto dove distribuire, testare e valutare in base ai loro requisiti, con un flusso di lavoro Git per registrare il suo viaggio attraverso il tunnel di approvazione.

Avere un ramo per ogni fase del processo va bene per i piccoli team che possono lavorare per un rilascio come unità. Sfortunatamente, una pipeline come questa può creare colli di bottiglia o accumularsi troppo facilmente e lasciare delle lacune. Associa il tuo processo Git alla tua infrastruttura che può causare problemi quando le richieste di funzionalità aumentano ed entrambi i processi devono essere ridimensionati.

NON utilizzare questo modello senza prima considerare i vantaggi a lungo termine di altri modelli.

Rami di rilascio

Un team che spinge una raccolta di contributi alla propria applicazione di produzione come unità in sprint successivi può trovare i rami di rilascio una soluzione favorevole.

A una raccolta di commit quasi "pronti per la produzione" vengono fornite correzioni di bug minori su un ramo di rilascio. Utilizzare un ramo di integrazione per combinare e testare le funzionalità prima di spostare il relativo albero di commit in un ramo di rilascio. Limitare la responsabilità di un ramo di rilascio a essere un controllo finale prima della distribuzione nell'applicazione di produzione.

I rami di rilascio differiscono dai rami ambientali in quanto hanno una breve durata. I rami di rilascio vengono creati solo quando necessario e distrutti dopo che il relativo albero di commit è stato distribuito in produzione.

Cerca di impedire l'accoppiamento di rami di rilascio alla road map di sviluppo del software. Limitarsi a seguire un piano predeterminato ritarda la distribuzione di una versione fino a quando tutte le funzionalità pianificate non sono pronte per la produzione. Non assegnare un numero di versione alla roadmap prima di creare un ramo di rilascio può alleviare questi tipi di ritardi, consentendo alle funzionalità pronte per la produzione di essere inserite in un ramo di rilascio e distribuite.

Utilizzare una convenzione di denominazione del numero di versione per il nome del ramo di rilascio per rendere evidente quale versione del repository è stata distribuita in produzione.

Distribuire il ramo principale e non il ramo di rilascio. Per incoraggiare l'esecuzione di piccole correzioni sui rami di rilascio prima dell'unione con il ramo principale, utilizzare un hook Git sul ramo principale per eseguire il trigger dopo che si è verificata un'unione per distribuire automaticamente l'albero di commit aggiornato in produzione.

Consentire l'esistenza di un solo ramo di rilascio in un determinato momento ti assicura di evitare il sovraccarico di mantenere più rami di rilascio sincronizzati tra loro.

NON utilizzare rami di rilascio con più team che lavorano sullo stesso repository. Anche se i rami di rilascio sono di breve durata, se il controllo finale richiede troppo tempo, impedisce all'altra squadra di rilasciare. È probabile che un team che si appoggia al ramo di rilascio di un altro team introduca bug e causi ritardi per entrambi i team. Guarda il modello di rilascio con timestamp di seguito, che funziona meglio per un numero maggiore e gruppi di contributori.

Rilasci con timestamp

Le applicazioni con limitazioni dell'infrastruttura pianificano comunemente le loro distribuzioni durante i periodi di traffico ridotto. Se il tuo progetto si trova di fronte a code regolari di funzionalità pronte per essere distribuite, potresti trarre vantaggio dall'utilizzo di versioni con timestamp .

Una versione con timestamp si basa sul processo di distribuzione per aggiungere automaticamente un tag timestamp all'ultimo commit sul ramo master che è stato distribuito in produzione. I rami degli argomenti vengono utilizzati per sottoporre una funzionalità al processo di sviluppo prima di essere uniti al ramo principale in attesa della distribuzione.

Il tag timestamp deve includere un timestamp effettivo e un'etichetta per indicare che rappresenta una distribuzione, ad esempio: deployed-201402121345 .

L'inclusione dei metadati di distribuzione, sotto forma di tag timestamp all'interno dell'albero di commit del ramo principale, ti aiuterà nel debug delle regressioni rilasciate nell'applicazione di produzione. È improbabile che la persona incaricata di cercare la causa del problema sappia molto su ogni singola linea distribuita nell'applicazione di produzione. L'esecuzione di un comando git diff sugli ultimi due tag può fornire rapidamente un'istantanea di quali commit sono stati distribuiti per ultimi e chi sono gli autori dei commit che potrebbero aiutare a risolvere il problema.

I rami con timestamp sono più di quanto appaiano in superficie. Un semplice meccanismo per registrare un'implementazione di funzionalità in coda richiede una quantità sorprendente di buoni processi per guidarlo. Il processo è scalabile e funziona bene anche con un piccolo team di contributori.

Affinché questo modello di flusso di lavoro Git sia veramente efficace, è necessario che il ramo principale sia sempre distribuibile. Ciò potrebbe significare cose diverse per il tuo team, ma essenzialmente tutti i commit devono essere passati attraverso il processo di sviluppo dei tuoi progetti prima di finire nel ramo principale.

I nuovi commit che atterrano sul ramo principale si verificheranno più volte al giorno. Questo è un problema per i rami di argomenti che sono stati sottoposti al processo di sviluppo e non sono stati sincronizzati con il ramo principale durante questo periodo. Sfortunatamente un tale scenario può introdurre regressioni nel ramo principale quando i conflitti di unione vengono gestiti in modo errato.

Se si verificano conflitti di unione tra un ramo dell'argomento e il ramo principale, il rischio di introdurre un nuovo bug dovrebbe essere discusso con il proprio team prima di aggiornare il ramo principale remoto. Se c'è qualche dubbio che possa verificarsi una regressione, il ramo dell'argomento può essere ripristinato attraverso il processo di garanzia della qualità con i conflitti di unione risolti.

Per ridurre i bug di integrazione, gli sviluppatori che stanno lavorando su parti correlate del repository possono collaborare su quando è meglio unire e sincronizzare i loro rami di argomento con il ramo principale. I rami di integrazione funzionano bene anche per risolvere i conflitti dai rami di argomenti correlati: questi devono essere sottoposti al processo di test prima di essere uniti nella coda sul ramo principale in attesa di distribuzione.

I progetti di sviluppo software con molti contributori devono affrontare processi di collaborazione e gestione dei rilasci con approcci pratici ed efficienti. I metadati aggiuntivi sull'albero dei commit che otteniamo dall'utilizzo di versioni con timestamp sono un indicatore della lungimiranza dei team che si stanno preparando a rispondere ai problemi di produzione.

Ramo di versione

Se disponi di un repository che non solo esegui in produzione ma che altri utilizzano per le proprie applicazioni ospitate, l'utilizzo di rami di versione può fornire al tuo team la piattaforma per supportare gli utenti che non possono o non possono rimanere all'avanguardia degli sviluppi della tua applicazione .

Un repository che utilizza rami di versione avrà un ramo per versione secondaria dell'applicazione. Le versioni principali, secondarie e patch sono spiegate nella documentazione Semantic Versioning. I rami di versione in genere seguono una convenzione di denominazione per includere la parola "stabile" ed eliminare il numero di patch dalla versione dell'applicazione: ad esempio 2-3-stable per rendere il loro scopo e affidabilità evidenti agli utenti finali.

I tag Git possono essere applicati fino al numero di versione della patch dell'applicazione, ma i rami di versione non sono così granulari. Un ramo di versione punterà sempre al commit più stabile per una versione secondaria supportata.

Quando si presentano patch di sicurezza o la necessità di eseguire il backport delle funzionalità, metti insieme i commit necessari per funzionare per le versioni precedenti delle applicazioni supportate e inviali rispettivamente ai rami di versione.

NON utilizzare rami di versione a meno che tu non supporti più di una versione del tuo repository.

Sommario

Quando il tuo team cambia dimensione o il tuo progetto sviluppa i suoi processi attraverso una valutazione continua, non tralasciare di valutare anche il tuo processo Git. Usa i modelli in questo tutorial come punto di partenza per aiutarti a orientarti lungo il percorso della correttezza del flusso di lavoro Git.

Lo schema in questa guida può aiutarti ad avere un po' di lungimiranza nell'adattare il tuo sistema di controllo della versione distribuito in modo che funzioni per te. Se desideri leggere i flussi di lavoro di Git, assicurati di controllare Gitflow, Github Flow e, soprattutto, la straordinaria documentazione di git-scm!