Git workflow per piccoli team

Sto lavorando a un flusso di lavoro git da implementare in un piccolo team. Le idee chiave nel flusso di lavoro:

Esiste un master di progetto condiviso a cui tutti i membri del team possono scrivere
Tutto lo sviluppo viene eseguito esclusivamente sui rami delle caratteristiche
I rami delle caratteristiche sono codici rivisti da un membro del team diverso dall'autore del ramo
Il ramo della funzione viene infine unito al master condiviso e il ciclo ricomincia

L'articolo spiega in dettaglio i passaggi di questo ciclo:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Ha senso o mi sto perdendo qualcosa?

— Janos
fonte

Risposte:

Mi piace il modello di ramificazione git flow . Il ramo principale viene lasciato solo per la maggior parte del tempo, contiene solo rilasci. Il ramo di sviluppo deve essere stabile in ogni momento e i rami delle caratteristiche possono essere interrotti.

Puoi anche combinare questo con l' integrazione continua unendo sviluppo nel ramo della funzionalità e il ramo della funzionalità in sviluppo. Ovviamente dovresti fondere qualcosa in sviluppo solo quando sei sicuro che le cose funzionino e non si rompano.

— Arjan
fonte

Da quanto ho capito, git flow e l'integrazione continua sono modi alternativi di lavorare e non possono davvero essere combinati. In git flow il codice viene unito allo sviluppo solo quando una funzione è completa. Nell'integrazione continua tutto il codice viene unito in un ramo condiviso almeno una volta al giorno, anche se non fornisce immediatamente alcuna nuova funzionalità.

— bdsl

Penso che manchi l'argomento Integrazione continua. Dovrebbe essere parte di ogni configurazione di sviluppo.

Con i rami delle caratteristiche hai il problema, che non ti integri continuamente, ma solo dopo che una funzione è stata completata.

Se la funzionalità ramificata ha vita breve, questo potrebbe essere accettabile, ma è sicuramente qualcosa che si dovrebbe considerare.

Un'altra alternativa è quella di impostare build CI per ciascun ramo di funzionalità. Questo sicuramente aiuta, ma non è l'integrazione. Ciò diventa evidente quando trovi il tuo primo bug che non appare nella Funzione A né nella Funzione B, ma nel momento in cui integri la Funzione A&B

Una terza alternativa è quella di rendere la fusione in un ramo di integrazione parte della build CI. Questa è una vera integrazione, e in realtà funziona ragionevolmente bene con git se il lavoro è in qualche modo separato, ma causa conflitti di unione durante la compilazione con conseguenti build fallite.

— Jens Schauder
fonte

Il ramo master può essere collegato con un elemento della configurazione per rifiutare le fusioni del ramo funzione se non superano i test di non regressione automatizzati. Grazie per il suggerimento, aggiungerò una sezione "Suggerimenti" alla fine e citerò qui.

— Jan

Certo, ma come detto, questa non è un'integrazione continua ma un'integrazione alla fine di una caratteristica che potrebbe essere una buona integrazione, ma non è la stessa

— Jens Schauder,

Penso che i rami delle caratteristiche siano molto utili, perché non devono essere stabili. Ciò significa che puoi impegnarti frequentemente invece di avere un enorme commit.

— Arjan,

Un processo di compilazione automatizzato che viene eseguito su una pianificazione (sistema CI) è indispensabile. Deve essere eseguito spesso in modo che i problemi di compilazione possano essere trovati e risolti rapidamente. I team di sviluppo dovrebbero dare la massima priorità ai fallimenti di build. È molto più facile risolvere questi tipi di problemi quando emergono per la prima volta.

— Nathan Pilling il

Per i nostri progetti che usano CI (abbiamo un paio di progetti legacy che al momento non possono usarlo), ci impegniamo TUTTO a padroneggiare per CI reali, per i nostri progetti legacy utilizziamo il modello di ramificazione git flow. I rami funzione sono un blocco CI se me lo chiedi, rendono più difficile l'integrazione CONTINUA (non solo al termine). Continuiamo a lavorare sulle funzionalità e il compito finale è quello di attivarlo sostanzialmente, ma il codice è sempre nel progetto.

— Elliot Blackburn,

Puoi essere ispirato a gitflow o Twgit .

gitflow riassume il suo approccio come:

Estensioni Git per fornire operazioni di repository di alto livello per il modello di ramificazione di Vincent Driessen.

Twgit si descrive come segue:

Twgit è uno strumento di assistenza gratuito e open source per la gestione di funzionalità, hotfix e rilasci su repository Git. Fornisce comandi semplici e di alto livello per l'adozione del modello di diramazione descritto nella nostra documentazione. Sistema operativo supportato: Debian / Ubuntu Linux, Mac OS X.

Entrambi gli strumenti sono disponibili su github .

— Duran
fonte