Descrizione del flusso di lavoro per l'utilizzo di git per lo sviluppo interno

Question

La società per cui lavoro ha bisogno di avere versioni mensili e sto cercando di convincerli a passare a git. Credo che il giusto modo per gestirlo sia avere un ramo di integrazione per ogni release (ovvero mensilmente) e avere filiali di funzionalità dai rami di integrazione per nuovi sviluppi e cambiamenti. L'ambiente è pieno di interdipendenze e talvolta una caratteristica deve essere posticipata a un mese diverso a causa dei ritardi nelle funzionalità richieste da altri sistemi esterni. I progetti avranno generalmente attività su 2-3 rami di integrazione in parallelo e l'attività è limitata a un gruppo di persone che sono in stretto contatto. (Il che significa che sospetto che possiamo usare la ridistribuzione fintanto che siamo sull'ultimo ramo dell'integrazione - che è vero almeno metà del tempo per metà delle persone)

C'è una discreta quantità di persone coinvolte, quindi io abbiamo davvero bisogno di alcune linee guida dirette su come fare questo, sia una spiegazione logica della struttura branch/merge che i pratici comandi git per farlo. Qualcuno sa di una tale descrizione che è ragionevolmente ben adattata per un tale flusso di lavoro?

Answer 1

una spiegazione logica della struttura delle filiali/merge

La struttura segue sostanzialmente quello che hai detto: un ramo di integrazione, e dispone di filiali.
In questo tipo di flusso di lavoro, è fondamentale capire, come hai fatto, che tutto lo sviluppo non passerà alla prossima versione.
Ma con un DVCS, è anche la chiave per capire che un ramo può essere pubblicato e clonato.

Questo ultimo punto (la pubblicazione) avrà una grande influenza sulla fusione comandi , vale a dire:

• merge
• rebase.

Ogni volta che uno sviluppatore deve unire il suo lavoro in qualsiasi ramo di integrazione (ha tirato da un repository "centrale"), mi sento di raccomandare:

# switch back to previous release tag (from where feature branches for next release where done) 
$ git checkout previousReleaseTag 
# create one's own private 
$ git checkout -b myIntegrationBranch 
# merge or cherry-pick what we want to actually put in the next release 
$ git merge... from our feature branch 
# rebase that private integration branch on top of actual integration branch 
$ git rebase integrationBranch 

L'ultima rebase riscriverà la storia del vostro locale consolidamenti, ma in una succursale che non pubblicherete comunque (quindi nessun danno fatto).
Una volta che tutte le nuove funzionalità funzionano, è possibile unire nuovamente il ramo privato all'attuale HEAD del relativo ramo di integrazione.

Il "ramo privato - unione o ricomposizione - rebase - risoluzione locale - unione" è un flusso di lavoro necessario poiché diversi team dovranno unire il proprio lavoro a un ramo comune. Hanno bisogno di ripetere ciò che vogliono pubblicare in un ramo privato prima di unirlo al ramo comune, altrimenti ogni squadra potrebbe rompere ciò che è rappresentato dal HEAD del ramo comune.

Altri dettagli nelle domande:

• git commit frequency
• git releases management (un altro flusso di lavoro merge)
• JC Hamano articles (grazie a Jakub Narębski)