Git workflow per più team

Inizieremo a utilizzare Git (non ancora utilizzato) e desidero definire il flusso di lavoro.

Abbiamo 4 team in 4 diverse sedi globali, sviluppando insieme lo stesso prodotto. Ogni team possiede una parte del codice del prodotto, ma a volte deve anche apportare modifiche al codice di proprietà di altri team.

Esiste una raccomandazione per un flusso di lavoro Git per tale ambiente?

Ho già visto questo articolo , ma l'approccio qui è "creiamo più rami il più raramente possibile" e credo di più nell'approccio "ramo per ogni user story".

Inoltre, questo articolo presenta un approccio gradevole.

Avevo in mente di avere un ramo principale, un ramo permanente per ogni squadra che si fondeva periodicamente con il maestro e una branca per utente che si univa ai rami delle squadre. Ha senso o non funzionerebbe?

git version-control

— Igor Oks
fonte

Usiamo questo modello di ramificazione , ma penso che se leggi "ramo delle caratteristiche" come "ramo della storia", si adatta molto bene al tuo secondo articolo.

Sono sicuro che 10 persone potrebbero rispondere a questo con 10 risposte diverse. Ecco cosa funziona per me: abbiamo un repository master ospitato su github che indica la versione "corrente". Le versioni precedenti sono ramificate (anche se la codifica funziona anche). I membri del team sono incoraggiati a creare filiali per le attività su cui stanno lavorando. Una volta completato, fanno una richiesta pull al master (o dove mai è necessario unirlo) e quindi qualcun altro rivede la richiesta pull ed è responsabile per unirla al master. Sono anche responsabili dell'eliminazione del ramo una volta che è stato unito.

Potresti essere interessato ai sottomoduli per tenere separate le basi di codice dei diversi team. Possono quindi scambiarsi le basi dei codici a vicenda e inviare patch quando si modificano le parti a vicenda del codice.

— Fred Foo,

@larsmans & carbonbasednerd - I tuoi commenti avrebbero dovuto essere risposte, avrebbero ottenuto voti positivi da parte mia. * 8 ')

— Mark Booth

Risposte:

Dai un'occhiata a Successful Git Branching Model , che ha una bella strategia di branching per lo sviluppo di funzionalità tra le versioni.

Un modello di ramificazione git di successo

Potresti implementare qualcosa di simile con un livello aggiuntivo per i rami del team tra il ramo "sviluppo" e i "rami funzione". Avere filiali di team consentirebbe anche a due team di collaborare in modo più efficace unendo le loro filiali.

— Nick Haddad
fonte

Direi che ogni team ha la propria versione del repository, con un repository globale in cui tutti si impegnano (come nel kernel Linux, in cui il repository Linus È il kernel e il repository centrale).

Quindi per mantenere il codice prodotto, è possibile utilizzare i sottomoduli come ha detto @larsmans, quindi ogni squadra può lavorare principalmente solo sulla parte che è più importante per loro e se devono lavorare con un'altra parte, possono farlo, ma loro dovremo ricordare di aggiornare il sottomodulo, ed è qui che si trova il problema (poiché è molto facile sbagliare quando si usa git, per fortuna è anche facile allontanarsene).

Ma poiché i tuoi team sono abituati a questo e sono consapevoli che stanno cambiando il codice di altri team, è più facile per loro ricordare di fare l'aggiornamento del sottomodulo, prima di cambiare un modulo esterno.

— Coyote21
fonte