Buon flusso di lavoro Mercurial per un team di 15 sviluppatori

Question

Sono in un gruppo di 15 sviluppatori che attualmente utilizzano Allfusion Harvest. Non siamo contenti e guardandoci attorno abbiamo deciso di passare a Mercurial grazie ai frontend disponibili TortoiseHg e MercurialEclipse.

Attualmente stiamo utilizzando una versione di Harvest di dodici anni e trovo difficile tradurre il flusso di lavoro corrente in Mercurial. Ho esperienza precedente con ClearCase dove abbiamo usato un modello simile a:

A A A 
| | | 
B C | 
| /| | 
C | E 
| |/ 
D E 
|/
E 

Dove il tronco a sinistra è instabile, centrale è prova e destra è stabile. Ora non ho problemi a ricreare questo modello di ramificazione in Mercurial (in un repository centrale). L'idea è che gli sviluppatori clonino quindi questo repository, derivano da unstable, fanno il loro lavoro e quindi si uniscono con unstable. Leggere sul web Devo ancora vedere un flusso di lavoro Mercurial rivolto a team con più di tre sviluppatori, quindi non sono sicuro che si tratti di un buon flusso di lavoro.

Quindi due domande:

È questo un buon modello di lavoro?

Come lavori con Mercurial e quanti ci sono nella tua squadra?

MODIFICA: Da quando ho fatto questa domanda ho usato sia Gitflow e Github flow. Entrambi sono stati utili a seconda della complessità del rilascio e della dimensione del team. E quando uso Mercurial, ho smesso di usare i rami (per altri che non sono stabili/instabili) e ho usato invece i segnalibri influenzati da Git.

Answer 1

Qui a Fog Creek, utilizziamo un flusso di lavoro simile, con una grande differenza. Poiché in Mercurial non ci sono rami veramente leggeri (i rami nominati mantengono il loro nome, anche dopo essere stati uniti) tendiamo a utilizzare più repository per i nostri rami. Ho scoperto che questo rende più facile sapere su quale ramo si sta lavorando, e rende anche più difficile l'unione accidentale tra i rami, dal momento che ciascuno dei vostri rami potrebbe avere rami propri ad-hoc.

Invece, abbiamo repository Stable, QA e Devel con cui lavoriamo. Il lavoro sulle caratteristiche va a Devel e si fonde con il QA e lo Stable, mentre le correzioni dei bug passano in Stabile e QA, e vengono reintegrate in Devel.

Molti dei nostri sviluppatori mantengono i propri repository di filiali per progetti a esecuzione più lunga, o qualsiasi cosa su cui stanno lavorando potrebbe violare il codice di qualcun altro.

Alcuni dei nostri sviluppatori hanno ogni ramo in una directory diversa, quindi passano esplicitamente da uno all'altro. Altri preferiscono riunire tutti e tre in un repository, usando l'estensione remote-branches per gestire le varie teste.

Questo ci ha dato un po 'di problemi quando stavamo usando il basic hg serve per ospitare i nostri repository, poiché la creazione di un nuovo repository di sviluppo o di ridenominazione dei repository richiedeva un amministratore di sistema. Questo è parte del motivo per cui abbiamo fatto in modo che chiunque possa creare repository di filiali in Kiln.

Sarebbe bello se Mercurial avesse un modello di ramificazione migliore e ci fosse del lavoro per aiutarlo, ma questo è ciò che funziona per noi.

Answer 2

• Per quanto ne so, il tuo flusso di lavoro è abbastanza buono.