Flusso di lavoro mercuriale per piccola squadra

Question

Sto lavorando in un team di 3 sviluppatori e di recente siamo passati da CVS a Mercurial. Stiamo utilizzando Mercurial con repository locali su ciascuna delle nostre workstation e spingendo/spingendo verso un server di sviluppo. Non sono sicuro che questo sia il miglior flusso di lavoro, in quanto è facile dimenticare Push dopo un commit e i conflitti di unione a 3 vie possono causare un vero mal di testa. C'è un flusso di lavoro migliore che potremmo usare, poiché penso che la complessità del VC distribuito superi i benefici al momento.

Grazie

Answer 1

Se si esegue in un sacco di 3 vie si fonde potrebbe essere perché avete troppo sovrapposizione in ciò che voi ed i vostri membri del team sta lavorando. Mercurial è piuttosto bravo a gestire le fusioni, a patto che non stiate modificando esattamente le stesse linee di un file. Se possibile, potresti dividere il lavoro più chiaramente ed evitare alcuni dei grattacapi di grandi fusioni. Si noti inoltre che questo sarebbe ancora un problema con CVS dal momento che è discutibilmente peggiore alla fusione di mercuriale.

Inoltre, non è necessario eseguire il push dopo ogni commit. Il tuo flusso di lavoro potrebbe essere simile a questo:

• Confermare parte di alcune funzionalità.
• Impegna ancora alcune funzionalità.
• Impegna l'ultima parte della funzione.
• Correggere i bug risolti per errori stupidi.
• Spingere la funzionalità completa per il repo.

In un certo senso, questo assomiglia a Going Dark, ma ciò può essere alleviato assicurandosi che le funzionalità nell'esempio precedente siano di dimensioni ridotte.

Answer 2

1. Dimenticate tutto quello che sapete su CVS. Mercurial non è niente di simile anche se alcuni comandi si sentono in qualche modo simili.

2. Leggi http://hginit.com/. Segui gli esempi.

3. Dimentica tutto ciò che sai di CVS.

4. Intendo. Questa è la parte più difficile. Impara a fidarti del tuo strumento.

Answer 3

Sembra che tutti stiano apportando le modifiche allo stesso ramo. Questo ha l'insoddisfacente effetto collaterale che stai unendo le modifiche degli altri su quasi ogni singolo commit, il che andrebbe bene, tranne che intervenire manualmente per i conflitti non è qualcosa che vuoi fare ogni volta che fai push su.

Ecco il flusso di lavoro che suggerirei. L'idea è di usare la ramificazione più pesantemente, quindi è necessario unirli al ramo principale meno spesso.

1. Chiedi a tutti gli sviluppatori di sviluppare tutte le funzionalità in un ramo separato.In questo modo:

   • si evita costantemente la fusione modifiche da altre persone, e

   • siete liberi di pressione per spingere lavoro incompleto prima che la persona accanto, "rende difficile unire."

2. Quando una funzione è "fatto" e se i cambiamenti apparirebbero di applicare in modo pulito (una chiamata in giudizio), unire il ramo di caratteristica direttamente nel ramo principale ed eliminare il ramo di caratteristica.

3. Se una funzione cade in ritardo ramo principale (molte caratteristiche fuse), o se l'unione appare altrimenti difficile:

   1. unione master nel ramo funzione.

   2. Trova e correggi eventuali bug nell'isolamento contenuto da altri sviluppatori.

   3. Supponendo che la funzione sia pronta, fonderla in master (avviso: ora l'unione in questa direzione sarà pulita per definizione). Altrimenti, puoi continuare a sviluppare.

Answer 4

stiamo usando Mercurial avendo repository locali su ciascuno dei nostri posti di lavoro e tirando/spingendo ad un server di sviluppo.

Suona bene per me. La mia squadra ha circa il doppio delle dimensioni e funziona benissimo.

Non sono sicuro che questo è il miglior flusso di lavoro, come è facile dimenticare di spingere dopo un commit,

Non è necessario spingere dopo ogni commit; spingi quando vuoi spingere. Questa è la grande idea di DVCS: che Commit e Push sono distinti!

e conflitti di unione a 3 vie possono causare un vero mal di testa.

Stai lavorando alle stesse linee di codice? Nella mia squadra di 5-6 programmatori, spingendo/tirando alcune volte al giorno e impegnandomi fino a un paio di volte al giorno, non riesco a ricordare l'ultima volta che ho dovuto risolvere manualmente i conflitti di unione. Certamente non negli ultimi due mesi.

C'è un flusso di lavoro migliore che potremmo usare, poiché penso che la complessità del VC distribuito superi i benefici al momento.

Forse dovresti descrivere il tuo flusso di lavoro in modo più dettagliato, perché l'unica complessità rispetto al controllo di versione centralizzato che incontro in un tipico giorno di lavoro è forse un comando, ei vantaggi sono enormi. Fare "hg blame" solo una volta mi fa risparmiare più tempo sulla versione centralizzata di tutte le "hg push" che ho dovuto digitare tutto l'anno!

Answer 5

Per quello che vale, siamo un team di dimensioni simili che collabora con Mercurial per la prima volta e abbiamo iniziato con lo stesso problema.

Abbiamo insistito e le cose ora sono decisamente migliori. Penso che la maggior parte dei problemi si siano verificati quando il codebase era piccolo e tutti cercavano di lavorare sulla stessa cosa. Ora che è un po 'più stabile, le persone non si calpestano a vicenda le dita dei piedi così tanto e la Parigi è molto ridotta.

Spero che tu abbia risolto il problema!