Quali sono i pro e i contro di git-flow vs github-flow? [chiuso]

Recentemente abbiamo iniziato a utilizzare GitLab.

Attualmente utilizza un flusso di lavoro "centralizzato".

Stiamo valutando la possibilità di passare al flusso github, ma voglio assicurarmene.

Quali sono i pro e i contro di git-flow vs github-flow ?

Come discusso nell'episodio 17 di GitMinutes , di Nicholas Zakas nel suo articolo sui " flussi di lavoro di GitHub all'interno di un'azienda ":

Git-flow è un processo per la gestione delle modifiche in Git che è stato creato da Vincent Driessen e accompagnato da alcune estensioni Git per la gestione di quel flusso.
L'idea generale dietro git-flusso è di avere diversi rami separati che esistono sempre, ciascuno per uno scopo diverso: master, develop, feature, release, e hotfix.
Il processo di sviluppo di funzionalità o bug scorre da un ramo all'altro prima che venga finalmente rilasciato.

Alcuni degli intervistati hanno indicato di utilizzare git-flowin generale.
Alcuni hanno iniziato git-flowe si sono allontanati da esso.

Il motivo principale dell'allontanamento è che il git-flowprocesso è difficile da gestire in un modello di distribuzione continuo (o quasi continuo).
La sensazione generale è che git-flowfunzioni bene per i prodotti in un modello di rilascio più tradizionale, in cui i rilasci vengono effettuati una volta ogni poche settimane, ma che questo processo si interrompe notevolmente quando rilasci una volta al giorno o più .

In breve:

Inizia con un modello il più semplice possibile (come tende ad essere il flusso di GitHub) e, se necessario, passa a un modello più complesso.

Puoi vedere un'interessante illustrazione di un flusso di lavoro semplice , basato su GitHub-Flow in:
" A simple git branching model ", con gli elementi principali:

1. master deve essere sempre distribuibile.
2. tutte le modifiche apportate tramite i rami delle funzionalità (pull-request + merge)
3. rebase per evitare / risolvere i conflitti; unisciti amaster

Per un flusso di lavoro effettivo più completo e robusto, vedere gitworkflow (una parola) .

Non esiste un flusso di lavoro miracoloso che tutti dovrebbero seguire, poiché tutti i modelli non sono ottimali. Detto questo, puoi selezionare il modello adatto per il tuo software in base ai punti seguenti;

Versioni multiple in produzione: usa Git-flow

Se il tuo codice ha più versioni in produzione (es. Prodotti software tipici come sistemi operativi, pacchetti Office, applicazioni personalizzate, ecc.) Puoi utilizzare git-flow. Il motivo principale è che è necessario supportare continuamente le versioni precedenti in produzione durante lo sviluppo della versione successiva.

Versione singola nel software semplice di produzione: utilizzare Github-flow

Se il tuo codice ha solo una versione in produzione in ogni momento (cioè siti web, servizi web, ecc.) Puoi usare github-flow. Il motivo principale è che non hai bisogno di cose complesse per lo sviluppatore. Una volta che lo sviluppatore termina una funzione o termina un bugfix, viene immediatamente promosso alla versione di produzione.

Versione singola in produzione ma software molto complesso: usa Gitlab-flow

Software di grandi dimensioni come Facebook e Gmail, potrebbe essere necessario introdurre rami di distribuzione tra il ramo e il ramo principale in cui potrebbero essere eseguiti gli strumenti CI / CD>, prima che entri in produzione. L'idea è quella di introdurre una maggiore protezione nella versione di produzione poiché è utilizzata da milioni di persone.

Uso il modello git-flow da oltre un anno ed è ok.

Ma dipende davvero da come verrà sviluppata e distribuita la tua applicazione.

Funziona bene quando si dispone di un'applicazione con un flusso di sviluppo / distribuzione lento.

Ma ad esempio, come GitHub, abbiamo un'applicazione che ha un flusso di sviluppo / distribuzione veloce, distribuiamo tutti i giorni e talvolta più volte al giorno, in questo caso git-flow tende a rallentare tutto secondo me e io uso GitHub flusso.

L'altra cosa da considerare è che git-flow non è git standard, quindi potresti, e quando dico che potresti, intendo davvero, troverai sviluppatori che non lo conoscono, e poi c'è la curva di apprendimento, altro possibilità di rovinare le cose. Inoltre, come accennato in precedenza, qualcuno ha sviluppato una serie di script per rendere più facile l'uso di git-flow, quindi non devi ricordare tutti i comandi, ti aiuterà con i comandi, ma ricordare il flusso effettivo è il tuo lavoro , Mi sono imbattuto più di una volta in uno sviluppatore che non sapeva se si trattava di un hotfix o di una funzionalità, o anche peggio quando non riesce a ricordare il flusso e riempire le cose.

C'è almeno una GUI che supporta git-flow per Mac e Windows SourceTree .

In questi giorni, mi sto orientando maggiormente verso il flusso di GitHub, grazie alla sua semplicità e facile da gestire. Inoltre, a causa della "distribuzione anticipata spesso" ...

Spero che questo ti aiuti