Dividendo il lavoro di un grande codice si fondono tra più persone?

3

Questa domanda è correlata a questa:

Perché non commettere modifiche non risolte?

Quando è necessario unire una grande base di codice con molti conflitti, mi piacerebbe avere un modo per commettere progressi da condividere attraverso un gruppo di persone che eseguono l'unione mantenendo la possibilità di utilizzare tutti i nostri strumenti di unione durante il processo. Ci capita di usare mercurial, ma questa è davvero una domanda generale su DVCS.

Il processo che abbiamo scelto di utilizzare, ma che non ci piace, è che realizziamo una condivisione e dividiamo il lavoro assegnando specifici gruppi di file a singoli o sottogruppi. Lavoreremo quindi dal vivo in un luogo "locale" ma condiviso in rete, tutti i file di modifica direttamente. L'unica applicazione del buon comportamento è la fiducia e non c'è modo di impegnarsi e tracciare i nostri progressi oltre la chiusura lampo di tutte le sere. In breve, il nostro processo scelto abbandona i vantaggi della gestione del repository mentre risolve i conflitti di fusione.

Un'alternativa è quella di deselezionare tutti i file e impegnarli con i conflitti. Ma questo è disconnettere il processo di fusione dagli strumenti di fusione e risolvere i conflitti diventa un esercizio di modifica manuale. Abbiamo deciso che è peggio del processo sopra indicato perché ci disconnette dagli strumenti di fusione e risoluzione dei conflitti.

C'è un modo migliore?

Grazie.

    
posta PaulRuby 17.03.2016 - 16:08
fonte

1 risposta

2

Nota: Non ho usato personalmente Mercurial, ma l'approccio generale dovrebbe essere lo stesso per qualsiasi tipo di sistema di controllo della versione.

Enormi fusioni dovrebbero essere evitate esattamente per la ragione che stai vedendo in questo momento. Forse questo episodio sarebbe un utile esempio di deterrente per tutti i lavori futuri, e un esempio di quanto sia importante fondersi su base regolare.

Crea un ramo intermedio di fusione dall'ultima revisione del tronco.

  • Puoi destabilizzarlo liberamente durante l'unione senza intaccare il tronco.

  • Puoi fare unioni parziali e combinarle successivamente in un singolo commit. (Credo che questo richieda un plugin per Mercurial)

  • Puoi (più facilmente) dividere l'unione tra più membri del team e il check-in quando è conveniente.

  • È possibile effettuare il check-in del codice che non funziona o compilare, ma come per qualsiasi succursale, è meglio effettuare il codice di check-in il più completo possibile.

  • Se il tuo tentativo di risolvere un conflitto crea problemi, puoi rifattarlo nel ramo intermedio senza intaccare il tronco.

  • Se unire troppo in una volta causa problemi, puoi eseguire il rollback e provare a unire meno changeset; di nuovo senza rovinare la storia del tronco.

  • Puoi risincronizzare il ramo intermedio con il tronco principale in qualsiasi momento per rilevare eventuali modifiche avvenute nel frattempo e risolvere anche questi conflitti.

  • Una volta completata l'unione, è possibile completare pacchetti di lavoro aggiuntivi per funzionalità "interrotte" che richiedono una nuova implementazione (ad esempio conflitti dei requisiti o codice che è stato sostituito nel trunk più recente).

  • Hai un controllo migliore sul modo in cui la cronologia viene visualizzata nel trunk per l'unione finale

Pensa al ramo intermedio di fusione come a una "sandbox" in cui puoi creare un pasticcio temporaneo senza inquinare il tronco, a patto che lo pulisci successivamente e infine unire quello ripulito versione nel bagagliaio, quindi rimuovere la sandbox.

Ricorda che un'unione non dovrebbe essere una scusa per creare un codice più disordinato. Dopo aver risolto i conflitti, dovresti rifattorici se necessario, sottoponilo a revisione paritaria e tutte le altre cose che faresti quando imposti un nuovo codice per mantenerlo pulito almeno quanto il modo in cui lo hai trovato.

    
risposta data 17.03.2016 - 17:59
fonte

Leggi altre domande sui tag