Gestione del controllo della versione di progetti di grandi dimensioni

Il modo in cui questo viene fatto è che ogni sviluppatore deve unire le modifiche prima di impegnare un file. Non ho mai usato Mercurial quindi non conosco i comandi o il processo esatto, ma in qualsiasi serio strumento di gestione della configurazione sarai avvisato se proverai a controllare "sopra le righe" di qualcun altro. Quando ricevi questo avviso, devi unire le altre modifiche alla tua copia ritirata, controllare la compilazione e i test ecc. E poi fare il check-in.

Questo è un problema molto comune e la fusione in questo modo può essere una vera PITA, ma è la vita. L'approccio alternativo di bloccare tutti i file estratti impedisce questo problema, ma ha il grave svantaggio di bloccare chiunque altro mentre lavori su un file, che a sua volta porta a persone che modificano versioni incontrollate e poi si scatena l'inferno ...

Non sono sicuro che Mercurial sia diverso, ma git semplicemente non ti permetterà * di spingere verso una destinazione che è divergente dal tuo ramo (ad esempio nel caso in cui Bob spinga per primo , quindi il server è diverguto dal ramo di Carl). Carl deve abbattere le modifiche di Bob, impegnarle, quindi premere.

* bene, se si usa l'opzione --force. Ma se devi usarlo, dovresti sapere perché.

Con mercurial, puoi ottenere più teste nel repository upstream se Carl forza la sua spinta. Quello che dovrebbe succedere è che dopo che Bob e Carl si sono uniti in modo indipendente alle modifiche di Alice, Bob, chi prima spinge dovrebbe essere Ok, ma Carl riceverà un messaggio che gli dirà che la sua spinta creerebbe nuove teste remote e la sua spinta sarebbe stata cancellata. / p>

Ovviamente, la soluzione è che Carl tenga sotto controllo le modifiche di Bobs, le unisca e poi restituisca anche quell'unione, in modo da ottenere tutte e tre le serie di modifiche.

Quante volte vedi questo tipo di problema dipenderà da quanto è grande il tuo repository e quanto spesso gli sviluppatori lavoreranno sulle stesse cose simultaneamente. Inoltre dipende dal fatto che gli sviluppatori abbiano preso l'abitudine di forzare i push (o impostare i loro strumenti per farlo automaticamente). Se quest'ultimo è il caso, ti consiglio vivamente di non farlo.

Se vedi persone che lavorano sullo stesso codice troppo spesso, allora forse dovresti controllare se la tua applicazione ha un eccesso di accoppiamento (ad esempio un super-singleton che deve essere modificato ogni volta che qualcuno cambia qualcosa da qualsiasi altra parte nel codice) o se hai bisogno di dividere il tuo repository in un gruppo di sotto-repository.

C'è qualcosa che non va nella configurazione Mercurial (o non so come dovrebbe funzionare questo sistema). Non dovrebbe consentire l'emergere di "due teste". Dovrebbe essere Alice- > Bob- > Carl o Alice- > Carl- > Bob. Questo è il modo in cui ha funzionato in Subversion in entrambe le squadre per cui ho lavorato, e siamo sempre riusciti a risolvere i conflitti. La fusione continua aiuta molto. Il tentativo di unire il lavoro di due mesi di più sviluppatori in un altro ramo spesso fa male.

In realtà non è così male come pensi che sarebbe in pratica.

In teoria , se due persone lavoravano sullo stesso file sulle stesse linee , allora è un problema che richiede un intervento manuale.

Tuttavia, nella pratica , questa situazione è molto rara. È più probabile che stiano lavorando sullo stesso file, ma in posizioni diverse. Se i due (o tre o quattro) sviluppatori stanno lavorando su diverse sezioni del file, l'unione automatica è generalmente abbastanza intelligente da capirlo.

Ci sono occasioni in cui ho modificato una riga di codice e un collega ha modificato la riga stessa in modo tale che quando seleziono l'ultimo dal controllo del codice sorgente, devo fondermi manualmente. Ma questo è raro e di solito accade solo se ho apportato una grande modifica che tocca comunque un numero elevato di righe (ad esempio se ho modificato alcune API utilizzate da molti client).

Il tuo scenario - tre persone - un file - è un sintomo di scarsa architettura e cattiva gestione.

Questo non è un problema di strumento.

Non so se Mercurial lo supporta, ma in un piccolo team coeso, il flusso di lavoro centralizzato potrebbe essere il migliore. In questo flusso di lavoro gli sviluppatori devono aggiornare / tirare dal server centrale prima di poter inviare un nuovo commit.

In progetti più grandi o distribuiti, raccomando il flusso di lavoro gatekeeper :

• Gli sviluppatori non si fondono l'uno con l'altro. Il gatekeeper unisce i rami dello sviluppatore in un ramo designato come ramo ufficiale.
• Gli sviluppatori lavorano su feature branch e quando una funzione viene eseguita propongono al gatekeeper l'unione.
• Il gatekeeper ha una buona conoscenza generale del progetto. Se la fusione di un ramo comporta conflitti, potrebbe aver bisogno dell'aiuto dello sviluppatore per risolverli, ma forse no, poiché i conflitti dovrebbero essere causati da una proposta di fusione che si è recentemente approvata.
• Il gatekeeper è anche responsabile della qualità del codice e delle migliori pratiche a livello di progetto. Rifiuta le proposte di unione che presentano problemi, lo sviluppatore originale dovrebbe eseguire le correzioni necessarie e inviare di nuovo il suo ramo.
• Essere un gatekeeper è un'attività a tempo pieno.
• Man mano che il progetto aumenta, ci possono essere più gatekeeper che formano una gerarchia.