Io un po 'di tempo fa mi sono unito a un nuovo team di sviluppo e recentemente abbiamo avuto la nostra prima major release. Abbiamo usato Git sin dall'inizio del progetto e ormai ci siamo un po 'a nostro agio. Tuttavia, ora che il prodotto è sul campo, stiamo scoprendo nuovi problemi / processi che devono essere stabiliti. Fino a questo punto, tutto ciò che abbiamo fatto era fare riferimento al popolare post sul modello di branching di successo , che in effetti è stato molto utile
Attualmente abbiamo i seguenti rami, tutti in diretta e tutti in fase di aggiornamento:
- master - solo codice stabile rilasciato (taggato ogni volta che la versione viene tagliata)
- sviluppare - completamente aperto. usato per lo sviluppo a lungo termine
- hotfix-1.0.1 - tag branched master 1.0.0 per piccole correzioni molto mirate che si stanno già allineando
- release-1.1 - Questa è una piccola versione incrementale che vogliamo spingere relativamente presto, quindi volevamo gestirla separatamente dallo sviluppo e limitare l'ambito delle modifiche.
Queste sono le regole di fusione che stiamo stabilendo:
- Se viene effettuato un cambio di codice in release-1.1, deve essere unito per lo sviluppo.
- Se viene effettuato un cambio di codice in hotfix-1.0.1, deve essere unito a release-1.1.
- Nessuno, ad eccezione di un membro del team, dovrebbe unire qualcosa nel master e quell'unione si verifica solo quando una versione del prodotto sta per essere spedita.
Le mie domande sono:
- Quando dovrebbero avvenire le fusioni? Non appena la correzione viene applicata nel ramo di livello inferiore? O periodicamente in blocchi di cambiamenti? Se periodicamente, come si determina in genere il periodo di unione?
- Chi dovrebbe fare la fusione? La persona che modifica il codice originale? O un individuo che verrebbe designato come "Direttore dei Servizi Git"?
La ragione per cui sto chiedendo tutto questo è perché sembra che mentre Git è molto flessibile (e io amo quella parte), ti permette anche di spararti facilmente nel piede. Con solo pochi comandi, qualcuno potrebbe facilmente, e si spera non di proposito, unire nuovo sviluppo direttamente nell'hotfix che dovrebbe essere spedito in 2 giorni.
Molti di noi sono nuovi a Git e stiamo ancora provando il modo di aggirare lo strumento. Stavo pensando a come le mie altre società / team hanno gestito tali concetti in passato e penso che la differenza più grande è che la maggior parte degli altri prodotti di controllo di origine che ho usato, funzionano con commit individuali, quindi ogni sviluppatore potrebbe essere responsabile di assicurarsi che le sue correzioni sono applicati ai posti corretti. Ma con Git, quando viene eseguito uno sviluppatore:
git checkout release-1.1
git merge hotfix-1.0.1
... dopo il suo commit, quei comandi finiranno per unire un intero ramo incluso il codice che non ha mai visto prima e potrebbe non essere la persona migliore da risolvere, se ci sono conflitti.