Git
Analizzando i tipi di flussi di lavoro

Osservazioni

Gitflow Workflow

Originariamente proposto da Vincent Driessen , Gitflow è un flusso di lavoro di sviluppo che utilizza git e diversi rami predefiniti. Questo può essere visto come un caso speciale del flusso di lavoro Feature Branch .

L'idea di questo è di avere rami separati riservati per parti specifiche in fase di sviluppo:

• master ramo master è sempre il codice di produzione più recente. Il codice sperimentale non appartiene a questo.
• develop ramo contiene tutti gli ultimi sviluppi . Questi cambiamenti di sviluppo possono essere praticamente qualsiasi cosa, ma le funzionalità più grandi sono riservate ai propri rami. Il codice qui è sempre lavorato e unito al release prima del rilascio / distribuzione.
• hotfix rami hotfix sono per correzioni di bug minori, che non possono attendere fino alla prossima versione. hotfix rami hotfix escono dal master e vengono uniti in entrambi i master e develop .
• release rami di release vengono utilizzati per rilasciare nuovi sviluppi dallo develop al master . Eventuali modifiche dell'ultimo minuto, come il bumping di numeri di versione, vengono eseguite nel ramo di rilascio e quindi vengono unite di nuovo in master e develop . Quando si distribuisce una nuova versione, il master deve essere contrassegnato con il numero di versione corrente (ad esempio utilizzando il controllo delle versioni semantico ) per riferimento futuro e rollback semplice.
• feature rami di feature sono riservati per funzionalità più grandi. Questi sono specificamente sviluppati in rami designati e integrati con lo develop al termine. I rami di feature dedicati aiutano a separare lo sviluppo e ad essere in grado di distribuire le funzionalità fatte indipendentemente l'una dall'altra.

Una rappresentazione visiva di questo modello:

La rappresentazione originale di questo modello:

Flusso di lavoro a forcella

Questo tipo di flusso di lavoro è fondamentalmente diverso rispetto agli altri menzionati su questo argomento. Invece di avere un repository centralizzato a cui tutti gli sviluppatori hanno accesso, ogni sviluppatore ha il proprio repository che è biforcato dal repository principale. Il vantaggio di questo è che gli sviluppatori possono pubblicare i propri repository anziché un repository condiviso e un maintainer può integrare le modifiche dai repository bifronte nell'originale ogni volta che lo ritengono opportuno.

Una rappresentazione visiva di questo flusso di lavoro è la seguente:

Flusso di lavoro centralizzato

Con questo modello di flusso di lavoro fondamentale, un ramo master contiene tutto lo sviluppo attivo. I contributori dovranno essere particolarmente sicuri di avere le ultime modifiche prima di continuare lo sviluppo, perché questo ramo cambierà rapidamente. Tutti hanno accesso a questo repository e possono commettere modifiche direttamente al ramo principale.

Rappresentazione visiva di questo modello:

Questo è il classico paradigma di controllo della versione, su cui sono stati costruiti vecchi sistemi come Subversion e CVS. I software che funzionano in questo modo sono chiamati Centralized Version Control Systems, o CVCS. Mentre Git è in grado di funzionare in questo modo, esistono notevoli svantaggi, come l'esigenza di precedere ogni tiro con una fusione. È molto probabile che una squadra lavori in questo modo, ma la costante fusione della risoluzione dei conflitti può finire per consumare un sacco di tempo prezioso.

Questo è il motivo per cui Linus Torvalds ha creato Git non come CVCS, ma piuttosto come DVCS , o Distributed Version Control System , simile a Mercurial. Il vantaggio di questo nuovo modo di fare le cose è la flessibilità dimostrata negli altri esempi in questa pagina.

Flusso di lavoro Feature Branch

L'idea alla base del flusso di lavoro Feature Branch è che tutte le funzionalità devono essere sviluppate in un ramo dedicato invece del ramo master . Questo incapsulamento facilita il lavoro di più sviluppatori su una particolare caratteristica senza disturbare la base di codice principale. Significa anche che il ramo master non conterrà mai codice danneggiato, il che rappresenta un enorme vantaggio per gli ambienti di integrazione continua.

L'incapsulamento dello sviluppo di funzionalità consente inoltre di sfruttare le richieste pull, che sono un modo per avviare discussioni attorno a un ramo. Offrono ad altri sviluppatori la possibilità di firmare una funzione prima che venga integrata nel progetto ufficiale. Oppure, se rimani bloccato nel bel mezzo di una funzione, puoi aprire una richiesta di estrazione chiedendo suggerimenti ai tuoi colleghi. Il punto è che le richieste pull rendono incredibilmente facile per il tuo team commentare l'uno il lavoro dell'altro.

basato su tutorial di Atlassian .

GitHub Flow

Popolare in molti progetti open source ma non solo.

Il ramo principale di una posizione specifica (Github, Gitlab, Bitbucket, server locale) contiene l'ultima versione disponibile. Per ogni nuova funzionalità / correzione di bug / modifica dell'architettura ogni sviluppatore crea un ramo.

Le modifiche avvengono su quel ramo e possono essere discusse in una richiesta pull, revisione del codice, ecc. Una volta accettate, vengono unite al ramo principale.

Flusso completo di Scott Chacon:

• Qualsiasi cosa nel ramo principale è dispiegabile
• Per lavorare su qualcosa di nuovo, crea un ramo con nome descrittivo dal master (es .: new-oauth2-scope)
• Impegnarsi in quel ramo localmente e spingere regolarmente il proprio lavoro nello stesso ramo denominato sul server
• Quando hai bisogno di feedback o aiuto, o pensi che il ramo sia pronto per la fusione, apri una richiesta di pull
• Dopo che qualcun altro ha esaminato e firmato la funzione, è possibile unirla in master
• Una volta che è stato unito e trasferito a "master", è possibile e deve essere distribuito immediatamente

Originariamente presentato sul sito web personale di Scott Chacon .

Immagine gentilmente concessa dal riferimento GitHub Flow