Mal di testa che utilizzano il controllo della versione distribuita per i team tradizionali?

Usiamo Mercurial da circa un anno. Anche se il mal di testa di cui parli, di gran lunga, la sfida più grande per la piena adozione per noi è stata entrare nella mentalità DVCS dei repository locali (= commit spesso.) La vecchia mentalità di "Commit una volta che hai lucidato il codice" può essere difficile da lasciare andare.

Hai detto:

In the DVCS model, each developer checks in their changes locally and at some point pushes to some other repo. That repo then has a branch of that file that 2 people changed. It seems that now someone must be put in charge of dealing with that situation.

Un'installazione predefinita di Mercurial blocca questo comportamento. Non consentirà una spinta se più di una testa verrà creata nel repository remoto, senza ulteriore conferma. Per le attività quotidiane, evitiamo questo. (Git ha nominato teste e ognuna può essere aggiornata solo se integra completamente la versione precedente, senza ulteriori conferme, quindi ancora una volta la situazione non può sorgere. Anche gli altri DVC hanno una protezione simile.)

Quindi alla fine di ogni giornata lavorativa, è necessario dedicare un po 'di tempo al commit, che è proprio queste attività:

1. Conferma le modifiche locali.
2. Estrai dal repository centrale.
3. Unisci (& commit merge.)
4. Invia al repository centrale.

Questo mantiene l'attività di fusione su una persona che stava lavorando di recente a questo codice e dovrebbe essere in grado di integrare le modifiche con la stessa rapidità di chiunque altro.

Come sottolineato nella domanda, questo aggiunge solo uno sforzo quando due persone lavorano sulla stessa area di codice. Se questo è il caso, allora ci sono più benefici nell'usare DVCS, quindi il guadagno è già evidente per quegli sviluppatori. (Ulteriori vantaggi includono che ogni sviluppatore è in grado di commettere separatamente codice e giocare con il proprio repository senza che un altro sviluppatore si intrometta.)

Un altro problema che hai menzionato:

Furthermore, since DVCS tends to make working locally so convenient, it is probable that developers could accumulate a few changes in their local repos before pushing, making such conflicts more common and more complicated.

Questo non crea un problema di unione per noi, ma potrebbe creare un altro problema:

La flessibilità di DVCS significa che sono possibili molti diversi flussi di lavoro, ma alcuni di questi sono irresponsabili. Con DVCS, aumenta la necessità di procedure o procedure chiare. L'attività di mantenere i cambiamenti locali può essere appropriata o meno, a seconda di molte cose.

Ad esempio: uno sviluppatore può lavorare su un animale domestico nel tempo libero in poche settimane? In alcuni ambienti questo è incoraggiato, in alcuni questo sarebbe inappropriato e tutti i cambiamenti dovrebbero essere presto centralizzati. Ma se un dev sta mantenendo le modifiche localmente, allora vorranno sicuramente apportare eventuali modifiche correlate per assicurarsi che il loro lavoro continui a giocare bene con l'ultimo rev. Comune.

Quando la gomma incontra la strada, i rilasci del software o le implementazioni di solito provengono da un repository centrale, quindi gli sviluppatori devono apportare i loro cambiamenti lì per test e distribuzione.

Questa è la mia storia, e ci sto attenendo, per almeno un paio di minuti ...

La premessa della tua domanda sembra essere in giro "Le fusioni sono difficili e devono essere evitate". I sistemi DVCS rimuovono questa barriera, anzi fanno di più, abbracciano l'idea di unire - non dovresti avere paura di fondere e unire conflitti come risultato, poiché diversamente dagli strumenti centralizzati, gli strumenti DVCS lo supportano in base alla progettazione.

Come conferma l'ottima risposta di Jamie F. - Il flusso di lavoro di Commit-Pull-Merge-Push fatto regolarmente (ogni giorno) significa che se stai camminando su un altro lavoro, lo vedi presto - finché è visibile, può essere gestito

I problemi che descrivi sono più come scegli di usare gli strumenti.

Siamo passati da SVN a GIT 6 mesi fa, dopo aver usato SVN e GIT localmente per un paio d'anni. Nessuno tornerà indietro e dolorosi conflitti di fusione sono una cosa del passato. Il mantra "Impegna piccoli e spesso" è la chiave.

Quando lavoravo in un team che usava git, la regola generale era questa: lavorare su un ramo privato, quindi, quando sei pronto a rendere il tuo lavoro disponibile al resto del team, ribalta il tuo ramo sul master prima tu spingi. (Quindi convalidare il ramo.)

Questa strategia significava che il master era una serie lineare di commit e che tutti i problemi di integrazione venivano riparati sulle filiali prima che fossero pubblici.

Uno strumento come SVN incoraggia strongmente un modo di lavorare strettamente integrato.

vale a dire. commettere frequentemente su un ramo condiviso (trunk o dev branch).

Questo è A-OK per la maggior parte degli ambienti di sviluppo aziendale che ho sperimentato, ed è facilitato e incoraggiato ulteriormente attraverso l'uso di Continuous Integration supportato da estesi test di integrazione, test di regressione e test unitari (Aiutare i singoli sviluppatori ad acquisire fiducia che essi non hanno rotto nulla con le loro modifiche).

DVCS ti dà la libertà di lavorare in modo più indipendente, cosa che ti serve in alcune situazioni, e il (tanto vantato) supporto migliorato per le unioni non può arrecare alcun danno di sorta.

La preoccupazione che mi rimane sempre in mente è questa: con grande libertà arriva la tentazione di usare quella libertà.

Certamente, nella mia (limitata) esperienza, trascorro molto più tempo a lavorare in modo indipendente nella mia squadra attuale (usando Mercurial) di quanto non facessi nei ruoli precedenti (dove abbiamo usato SVN, CVS e P4).

Questo è solo parzialmente attribuibile allo strumento, ma penso che sia un'osservazione ragionevole per far sì che, in assenza di un motivo convincente per spendere gli sforzi per la comunicazione e il coordinamento, le persone tenderanno a lavorare separatamente e in isolamento.

Questo non è necessariamente un aspetto negativo, ma credo che sia qualcosa che deve essere preso in considerazione.

La cosa con controllo di versione di tipo git / mercurial, è di eseguire il commit spesso, e spingere sul server centralizzato quando il codice è buono. Un grande vantaggio di questo è che crea piccole patch, che sono facili da applicare in caso di conflitti. Inoltre, il flusso di lavoro dovrebbe essere qualcosa nelle righe di:

1. Molti commit locali
2. Estrai dal server
3. Invia al server

Questa estrazione dal server potrebbe creare conflitti, ma per risolvere questo problema, tutto ciò che è necessario molte volte è un semplice rebase, invece di un'unione. Questo, credo, manterrà la cronologia della mainline abbastanza pulita e rimuoverà molti conflitti.

Questo è anche il caso quando si passa dal repository locale di un collega, in quanto potrebbero accadere due cose. O prima spinge sul server, il che va bene visto che hai già le sue patch, e non dovrebbero verificarsi conflitti, o prima spingi, il che significa che riceverà le tue patch solo quando tira.

Ovviamente, a volte un'unione è una soluzione migliore, ad esempio se lavori su un ramo di funzionalità che dovrebbe essere unito in master.

Nel tuo flusso di lavoro stai parlando di persone che devono andare esplicitamente da un altro sviluppatore e dirgli di risolvere il conflitto, ma questo non dovrebbe essere necessario. Il server centrale è il "capo" e su cosa dovresti lavorare principalmente contro. Se le modifiche si applicano al repository centrale, allora il tuo ok. Altrimenti, è il TUO lavoro a risolvere il conflitto, che potrebbe richiedere lo sviluppatore con cui si è in conflitto per aiutarlo a capire le sue modifiche. Questo è qualcosa che vedi quando provi a tirare / rebase dal server. Quindi, sii felice di aver commesso e affrontato i conflitti quando devi prelevare dal server.

Il principio di lavorare con il repository centralizzato è lo stesso quando si lavora con sistemi centralizzati o distribuiti senza blocco:

• Nel sistema centralizzato tu:
  1. Scarica l'ultima versione da mainline ("trunk" in subversion, "master" in git, ...)
  2. Modifica i file
  3. Unisci le modifiche con l'ultima versione dalla riga principale usando il comando "aggiorna"
  4. Impegna come principale
• Nel sistema distribuito voi:
  1. Scarica l'ultima versione dalla riga principale
  2. Modifica i file
  3. Applica localmente
  4. Unisci le modifiche con l'ultima versione dalla riga principale e invia il risultato localmente
  5. Invia alla linea principale.

Nessuna versione distribuita ti consentirà di spingere una revisione che non unisca completamente la revisione della testina precedente (senza sovrascrittura speciale, a volte è utile), quindi non verrà eseguita senza eseguire il passo di unione (quindi non ci sarà due versioni che qualcuno dovrebbe consolidare come te).

Ora nota che quattro dei passi sono gli stessi tranne che per la terminologia, ma i sistemi distribuiti aggiungono un ulteriore passaggio "3. Esegui commit localmente". Il grande vantaggio di questo passaggio è che quando l'aggiornamento / pull crea conflitti e non sei sicuro su come risolverli o fare un errore risolvendoli, puoi tornare indietro, rivedere ciò che hai fatto e ripetere l'unione. Subversion non ricorderà nessuno di questi, quindi se fai un errore risolvendo l'aggiornamento, sei fregato.

Per quanto riguarda l'accumulo di modifiche, le persone tendono a farlo anche con il sistema centralizzato. Soprattutto se devi passare da una funzione all'altra spesso (ad esempio interrompere un lavoro più lungo per correggere un bug o apportare alcune modifiche di cui il cliente ha bisogno urgentemente), le persone spesso hanno bisogno di mantenere le modifiche localmente semplicemente perché non sono finite. Quindi è meglio che il sistema almeno supporti un senso.

In entrambi i casi questi problemi devono essere affrontati da linee guida e comunicazioni appropriate nel team e non dagli strumenti. Con strumenti più flessibili le linee guida sono più importanti, ma gli strumenti più flessibili consentono di affrontare meglio i vari casi d'angolo.