Le tecniche per evitare la git entangling si fondono quando si lavora su un ampio cambiamento

Il modello non è male e nella maggior parte dei casi non è davvero evitabile.

Alcuni suggerimenti:

1. Coordinate qualsiasi lavoro con altri sviluppatori? Usiamo Git al lavoro e in genere le persone modificano ciò di cui hanno bisogno, ma a volte, se qualcuno dice, hey, sono in questa zona e così facendo. Altri sviluppatori potrebbero smettere di lavorare su biglietti che toccano la stessa cosa.
2. Se sto lavorando su una funzione di grandi dimensioni che richiede un ramo di funzionalità di lunga durata. Non mi unisco quotidianamente ma sicuramente frequentemente. Come hai sottolineato, l'esecuzione di diverse unioni più piccole riduce il fattore sorpresa di OMFG e questo sembra completamente diverso.
3. Usa strumenti grafici. Sono consapevole del fatto che alcune persone eseguono ancora "git merge", svuotano un po 'di file di testo e poi riconciliano manualmente. Questo suona assolutamente aweful e non lo augurerei mai a nessuno. Nel mio precedente lavoro, abbiamo utilizzato Perforce, e quando sono entrato nel mio team attuale in cui usiamo git, la prima volta che ho dovuto fare un unione a 3 vie, sono andato online e ho trovato questo post sul blog . P4merge rende il processo di riconciliazione molto più semplice.
4. Un'altra cosa che potresti considerare è quella di suddividere il tuo compito più grande in più piccoli. Soprattutto se è necessario apportare modifiche al refactoring o all'architettura. Se riorganizzi le cose per prime, assicurati che funzioni e spinga al ramo di sviluppo comune, riceverai molte meno sorprese se il resto del tuo lavoro si trova in alcune aree specifiche del prodotto.
5. Per costruire un po 'sul punto precedente, ciò potrebbe dipendere anche dal modo in cui è stato progettato il tuo software. Avere un approccio modulare e tenere a mente i Principi di Open-Close quando si scrive codice sicuramente aiuterà a impedire agli sviluppatori di calpestare troppo gli altri. Tuttavia, se hai molte classi monolitiche che spesso devono essere modificate ogni volta che correggi un bug o aggiungi una funzionalità, ciò contribuirà ai tuoi livelli di frustrazione. In questo caso, la progettazione di fissaggi è una questione molto più importante del semplice flusso di lavoro git.

In generale, più spesso unirai le tue modifiche, meno conflitti avrai in totale e quindi meno tempo totale sarà dedicato alle unioni.

Naturalmente non ci saranno conflitti quando si uniscono parti di codice indipendenti. E questo non dice necessariamente nulla sui file. Se un file contiene due funzioni, una persona ne cambia una e l'altra cambia l'altra, l'unione automatica la risolverà bene in una frazione di secondo.

Quindi dovresti:

1. Lavorare per migliorare il design generale del codice. Più il codice è modulare, più è facile lavorare su parti diverse senza interferire tra loro.

2. Coordinate le attività nel team in modo che le attività che necessitano di toccare la stessa parte del codice non vengano eseguite contemporaneamente. Ciò sarà ovviamente facilitato mantenendo il codice modulare.

3. Dividi le attività in blocchi più piccoli che possono essere trasferiti al ramo di sviluppo principale ( develop o next o qualsiasi altra cosa tu lo chiami). Di nuovo, mantenere il codice ben strutturato ti permetterà di eseguire il refactoring localizzato in preparazione di alcune funzionalità che non infrangono nient'altro e possono essere spinte a tutti.

4. Se è necessario modificare la stessa parte del codice allo stesso tempo e non è possibile rendere le attività di piccole dimensioni, unire le persone che lavorano su di esso durante il lavoro, quindi le modifiche successive sono fatte con il lavoro precedente del altri colleghi già inclusi e non hanno bisogno di fondersi. Naturalmente devi fonderti in punti in cui il codice non è rotto al punto che gli altri non potrebbero testare le loro parti (ma durante un'attività più grande hai bisogno di punti intermedi in cui il codice funzioni abbastanza per testare comunque le modifiche parziali).

   1. Se riesci a vivere con tutte le attività da consegnare solo quando hai finito, imposta un ramo di sviluppo condiviso e invia le tue modifiche parziali lì e tieniti aggiornato con esso.
   2. Se si conosce quale funzione deve essere consegnata per prima, è possibile continuare a fondersi in un modo dal ramo delle caratteristiche della funzione prima a quella successiva. Quindi, la prima funzione può ancora essere consegnata immediatamente al termine mentre la successiva salva alcuni problemi di fusione fondendosi presto.
   3. Se è necessario mantenere separate le funzionalità, è comunque possibile ottenere aiuto unendo periodicamente tutti insieme, risolvendo eventuali conflitti, registrando le risoluzioni con git rerere (1) e scartando nuovamente il risultato dell'unione. Il prossimo tentativo di unione mostrerà solo eventuali nuovi conflitti e quando alcune delle funzionalità saranno finalmente integrate, le risoluzioni potranno essere riutilizzate per aggiornare i restanti rami delle funzionalità.

Va notato che avresti gli stessi problemi in qualsiasi altro sistema di controllo della versione, perché il funzionamento fondamentale di un'unione a 3 vie è sempre lo stesso. Git ti consentirà almeno di ritirarti facilmente e riprovare se commetti un errore utilizzando il potente git reflog (1) . Anche il git rerere (1) aiuta anche di tanto in tanto.

Stabilisci standard di codifica per il tuo team

Può sembrare banale, ma ho imparato ad amare DVCS (Git, Mercurial) il giorno in cui il nostro team ha deciso di impostare standard di codifica , che sono stati poi ottimizzati nei nostri IDE.

Ad esempio, se si codifica in questo modo:

// tabs indents

if($you+$me==$wow) {
    $answer='It\'s gonna be great';
    return $answer;
}

Considerando che i tuoi colleghi codificano in questo modo:

// spaces indents

if ($me + $you = $hey)
{
    $answer = "Let\'s talk a bit, won't you?";
    return $answer;
}

Stai subendo MOLTI problemi di fusione. Quindi, se non è ancora il caso, prenditi il tempo necessario per stabilire gli standard di codifica nel tuo team e personalizza i tuoi IDE di conseguenza per automatizzare tutto.

Un altro vantaggio degli standard di codifica

Un po 'fuori tema (è per questo che è separato dal resto) ma utile.

Se il manager del tuo team gestisce bene la tua squadra, probabilmente il tuo team organizza frequenti recensioni di codici collaborativi . Ad esempio, venerdì pomeriggio è tempo di revisione del codice .

Stabilire standard di codifica garantisce che nessuno stia cogliendo il modo di codificare di qualcun altro o che stia avendo problemi a capire uno snippet a causa di uno stile di codifica a cui non è abituato. Quindi, puoi essere certo che il tempo di revisione del codice sarà pienamente utilizzato per discutere questioni di programmazione reali, non di punteggiatura.

Sia che tu stia utilizzando git o qualsiasi altra cosa, se le persone stanno apportando modifiche incompatibili con il codebase in parallelo, la fusione del tuo lavoro sarà sempre doloroso. Questo non ha niente a che fare con il modello git in particolare.

Se ritieni che la fusione sia troppo dolorosa, probabilmente c'è qualcosa di sbagliato nel modo in cui tu e gli altri sviluppatori coordinate i vostri sforzi.

Ad esempio, i refactoring che toccano molte linee in molti file diversi (come la ridenominazione di funzioni / classi molto usate / etc) non dovrebbero essere fatti come altri stanno lavorando. Quando desideri apportare modifiche di questo tipo, comunica con gli altri sviluppatori, concorda su ciò che verrà modificato, sincronizza con tutti, apporta le modifiche, quindi esegui nuovamente la sincronizzazione.

Lo stesso è vero se si vuole ridisegnare parte del codice, separarlo completamente e poi metterlo insieme in un modo diverso, o eventualmente riscriverlo da zero. Lavorare indipendentemente in parallelo, e poi fondersi in seguito, è un modello impraticabile in quel caso. La soluzione è d'accordo sul fatto che qualcuno revisionerà determinati file / classi / moduli / ecc., Sincronizzerà, apporta le modifiche, quindi eseguirà di nuovo la sincronizzazione. Successivamente, puoi continuare a lavorare in parallelo.

Sebbene git e altri strumenti VC distribuiti consentano a qualsiasi dev di lavorare su qualsiasi parte del codice in qualsiasi momento, ciò non significa che dovresti farlo effettivamente. Ci sono momenti in cui è necessario ricorrere ad una disciplina, momenti in cui è necessario comunicare di più con gli altri sviluppatori e coordinare i propri sforzi. Sì, quel coordinamento ha un sovraccarico. Sì, a volte ti rallenterà. Questa è una conseguenza inevitabile del lavoro di squadra piuttosto che di un individuo. Naturalmente, se riesci a suddividere il lavoro in un modo che elimina la necessità di una coordinazione a grana fine, tale overhead sarà molto meno.

Spingi le modifiche al ramo di sviluppo principale almeno una volta al giorno, preferibilmente più spesso, e incoraggia altri sviluppatori a fare lo stesso. Come molti dicono, se fa male, fallo più spesso .

Ciò significa che ciò che spingi in generale non sarà l'intero cambiamento che intendi apportare, perché non hai avuto il tempo di farlo. Invece saranno alcune altre modifiche al codice che renderanno più facile per te apportare il cambiamento che desideri in futuro.

Questo flusso di lavoro richiede che ogni commit debba essere un cambiamento incrementale che almeno non peggiora il prodotto . Ad esempio, potresti eseguire un refactoring in un commit, quando ritieni che possa aiutarti a effettuare successivamente una modifica richiesta o a implementare una parte di una nuova funzione, assicurandoti che gli utenti non possano accedere a tutto ciò che non è pronto.

Questa è un'integrazione continua.