commit-pull-merge-push o pull-merge-commit-push?

Question

Abbiamo iniziato a utilizzare Mercurial alcune settimane fa. La maggior parte degli sviluppatori seguono questo flusso di lavoro:

• lavoro su una caratteristica
• commit -m "Ha lavorato in funzione di ABC"
• di pull -u
• Se ramo
  • merge
  • commettere - m "Unisci"
  • spingere

Oggi, uno dei nostri sviluppatori ha suggerito che facciamo:

• lavoro su una caratteristica
• di pull -u
• se il lato
  • merge
• commit -m "Funzionava su funzionalità ABC"
• push

In questo modo, abbiamo molto meno "Unisci" changeset nel registro.

Alcuni di noi pensano che sia solo una questione di preferenza. Alcuni di noi pensano che uno sia migliore dell'altro. Non abbiamo molta esperienza e non vogliamo vivere gli aspetti negativi del cattivo utilizzo dello strumento. Quindi se un approccio è più consigliabile allora l'altro, per favore fammi sapere perché.

Answer 1

Mi piace la procedura originale di più, ma le persone ragionevoli possono certamente non essere d'accordo. Considero la fusione di un vero pezzo di lavoro di sviluppo del software e come se fosse un cittadino di prima classe nel nostro processo.

Nella tua seconda/procedura suggerita il rischio è che il pull faccia alcune cose che davvero non vuoi e quindi hai un momento molto difficile separarlo dal lavoro che hai già fatto.

Per le persone che proprio non sopporto la storia branchy il consueto flusso di lavoro preferito è:

• lavoro su una caratteristica
• commettere
• tirare --rebase
• spinta

dove l'opzione --rebase appare in pull dopo aver abilitato lo rebase extension. Non sono un fan di rebase perché è tecnicamente una storia di riscrittura che è antitetica al modo in cui dovrebbe funzionare il mercurio, ma io sono in una minoranza che si sta riducendo rapidamente su quel punto.

In conclusione, se davvero non si desidera che una cronologia ramificata utilizzi rebase, non aggiornare in modifiche non salvate poiché è difficile da annullare.

Answer 2

Vorrei andare con il tuo primo flusso di lavoro. L'obiezione principale che ho con la seconda opzione è che se si tenta di unire prima di eseguire il commit, non c'è un modo semplice per uscire dall'unione quando le cose vanno male (cosa che accade di volta in volta) in modo da poter ricominciare.

Questo può essere particolarmente utile se si verifica un conflitto di unione con la caratteristica A e si desidera chiedere allo sviluppatore che ha lavorato a Feature A qualcosa, ma è in pausa pranzo. Con il tuo primo flusso di lavoro, puoi interrompere l'unione e continuare fino a quando lo sviluppatore è tornato e sei pronto per unire nuovamente. Con il secondo flusso di lavoro, sei semplicemente bloccato e devi andare a cercare qualcos'altro da fare (o creare un altro clone del repository e lavorare in quello fino a quando non puoi unirmi, ma questo mi sembra peggio).

Answer 3

Questo non funziona:

• lavoro su una caratteristica
• di pull -u
• se il lato
  • merge
• commit -m "Ha lavorato sulla funzione ABC "
• push

Se si dispone di modifiche locali, è possibile che non si unisca. Che cosa si/può/fare è questo:

• lavoro su una caratteristica
• di pull -u
• lavoro su una caratteristica
• di pull -u
• lavoro su una caratteristica
• di tiro - u
• ...
• commit -m "Ha lavorato in funzione di ABC"
• spinta

Si potrebbe anche voler indagare hg fetch, si tratta di un spedito con Mercurial plug-in opzionale che fa tirare/fondersi nella stessa fase. Il che va bene se ti sei dimenticato di tirare prima di impegnarti.