Gestire una grande richiesta pull

Attualmente sto lavorando a un progetto con un team che utilizza un flusso di lavoro git. È abbastanza semplice, il master dovrebbe essere in uno stato distribuibile e i rami vengono utilizzati per creare funzionalità e hotfix. Ogni volta che una funzionalità o correzione di bug è stata completata e testata, la spostiamo sul master il più presto possibile. L'idea è che i rami dovrebbero essere il più piccoli possibile per rendere più semplice la loro fusione nel master. Abbiamo una politica secondo cui qualsiasi codice inviato al ramo master dovrebbe trovarsi in uno stato distribuibile e superare i test.

Abbiamo avuto una situazione in cui uno degli sviluppatori ha lavorato molto (vale la pena alcuni mesi) su un singolo ramo e questo ramo non è stato ancora riunito nel master. Ora ci sono alcune funzionalità separate e un sacco di commit su questo ramo, in sostanza questo ramo avrebbe dovuto davvero essere fuso di nuovo in alcune volte, ma finora non lo è stato. La maggior parte del codice è in buono stato con unit test che potrebbero essere uniti in master, ma le modifiche più recenti non dovrebbero certamente essere poiché non sono state completate e non sono state testate.

Qual è il modo migliore per affrontare una situazione del genere in cui un ramo è davvero molto lontano dagli altri? In quali modi possiamo evitare che le filiali possano ottenere un numero molto elevato di commit dal master in futuro?

Lascia che lo sviluppatore che è andato per un paio di mesi senza fondersi lo risolva. Forse possono ottenere un grosso pezzo di codice da unire, forse possono ottenere un sacco di piccoli pezzi per unirne uno alla volta. In ogni caso, dovrebbero fare le gambe per risolvere il problema, dal momento che lo hanno causato.

Qual è il modo migliore per affrontare una situazione del genere in cui un ramo è davvero molto lontano dagli altri?

In generale, non preoccuparti: è il problema dell'altro sviluppatore. Se due rami sono davvero troppo distanti per unire, allora non fanno più parte dello stesso progetto e hai un fork defacto. Se si tratta di un progetto open source, potrebbe non essere nemmeno un problema.

Se questo sviluppatore è davvero brillante e il loro codice è migliore / più intelligente / più importante del resto del team combinato, allora vale la pena renderlo il tuo problema anziché il loro. Altrimenti no.

Per rispondere alla domanda letterale: il modo migliore per affrontare questo tipo di situazione è non entrare in quel tipo di situazione.

In quali modi possiamo evitare che le filiali possano ottenere un numero molto elevato di commit dal master in futuro?

Assicurati che tutti notino che lo sviluppatore che è andato per mesi senza fusione deve risolvere il problema che ha causato. Assicurati che tutti sappiano che è più facile impegnarsi a padroneggiare frequentemente che raramente, dal momento che un minor numero di modifiche significa meno opportunità di conflitti.

Assicurati che le persone sappiano che possono andare dal maestro per rimanere aggiornato con i cambiamenti degli altri.

"Se ti unisci ogni giorno, all'improvviso non arrivi mai al punto in cui hai enormi conflitti che sono difficili da risolvere." --Linus Torvalds

Quella citazione è tratta da un discorso che ha tenuto a Google, ecco la trascrizione ed ecco il video .

Se hai un commit che conosci questo e tutti i commit precedenti sono ben testati e dovrebbero essere uniti, allora semplicemente esci da quest'ultimo ultimo commit e unisci il nuovo ramo con master.

Se hai alcuni commit che vorresti unire, ma sono intervallati da altri commit che non sono pronti per la produzione, allora vedo 2 possibilità:

1. Crea una nuova filiale e raccogli i buoni commit della ciliegia, fondendoli con il master.
2. Prova a reimpostare i commit indesiderati verso l'alto (forse sul nuovo ramo solo per sicurezza).

Per quanto riguarda i metodi di prevenzione, prova a definire alcune regole di squadra divertenti come "Uno che non si fonde con il maestro entro una settimana ordinerà la pizza per un mese".

Per prima cosa, vedi se ci sono davvero commit separati che possono essere uniti o selezionati in ciliegio, come suggerito da @Maciej Chalpuk. Se questo è il caso, la situazione non è poi così grave e non mi preoccuperei troppo in futuro.

Tuttavia, se la situazione reale è che più funzioni sono state sviluppate contemporaneamente in un singolo ramo, all'interno dello stesso commit, allora diventa un dolore molto più grande da affrontare. Fortunatamente, il metodo di prevenzione è integrato: impone allo sviluppatore di separare le modifiche per ciascuna funzionalità in rami separati e di estrarre le richieste prima di unirle. Otterrai entrambe le fusioni atomiche e dissuaderai lo sviluppatore dal farlo in il futuro.

Il processo effettivo di separazione delle funzionalità è interamente manuale. Crea nuovi rami al di fuori del master e copia in qualsiasi modifica del mega ramo ad esso correlato. Compila, testa la funzione, invia e invia una richiesta pull. Meno si mescolano le modifiche al codice, più facile sarà farlo. Se stava hackerando un solo metodo per tutti, beh, divertiti. Non lo farà di nuovo.

Ecco una soluzione semplice.

Tieni traccia delle funzionalità che questa persona ha implementato e vai a ciascun commit su quel ramo che è stato aggiornato per funzionalità. Prendi questo commit e uniscilo con il repository principale.

Consentitemi di scomporlo sotto forma di esempio.

Sia: Branch A sia il branch dal master Branch A + = Branch A + nuova funzionalità 1 Branch A ++ = Branch A + nuova funzionalità 2 e così via e così via

Quello che devi fare è tornare a: Branch A +

Prendi il ramo A + e uniscilo al Maestro.

Ora vai a Branch A ++ e uniscilo con (Master + Branch A +).

Ripeti fino a quando non hai raggiunto il ramo finale A + ... + che è stabile.

Questo metodo può sembrare inizialmente intuitivo, ma se unisci ciascuna nuova funzionalità separata con il master, diventa facile scorrere tra il ramo master " per funzionalità aggiunta "

In quali modi possiamo evitare che le filiali possano ottenere un numero molto elevato di commit dal master in futuro?

Penso che la mia soluzione sopra indichi quale futuro metodo dovresti adottare. Scegli un metodo per funzione o per attività per ciascun ramo.

Suggerirei di utilizzare un approccio di:

pre-master e master

master: livello finale / di produzione. Viene modificato non spesso. È considerato sempre stabile

pre-master: l'area in cui una nuova funzionalità viene aggiunta al codice esistente. È stato testato a fondo per funzionare con la base di codice esistente ed è il luogo in cui altri rami possono fork per l'implementazione di nuove funzionalità.

Dovresti anche provare a raggruppare le funzioni e mirare al targeting per versione.

Targeting per versione: specificare un numero arbitrario che fungerà da segnaposto per il ramo principale. "In V1.0.0, vorremmo ottenere le funzionalità X, Y, Z. V1.0.0 avrà anche tutte queste funzionalità disponibili: ..."

Mantenendo una versione contro master, può anche essere un modo per mantenere "master" stabile e pronto per la produzione in ogni momento.

Risolvere il problema della grande richiesta pull è una cosa e ci sono alcune buone risposte a riguardo. Ma per quanto riguarda la gestione di filiali che non sono molto aggiornate, potresti voler rivisitare i tuoi processi per gestire il lavoro di gruppo.

Se lavori in un framework Agile o SCRUM, il team dovrebbe davvero chiederti perché la funzione non è stata completata e unita come parte dell'iterazione / sprint. Se fosse "troppo grande" per rientrare in un'iterazione, avrebbe dovuto essere suddiviso in blocchi più piccoli.

Solleva anche una questione di proprietà del codice: all'interno del tuo team, i singoli sviluppatori possiedono il proprio lavoro separatamente o il team completo lavora insieme per garantire che gli articoli vengano completati?

Naturalmente, quanto sopra presuppone che il tuo team sia all'interno di una sorta di struttura aziendale. Se questo è un progetto open source con collaboratori volontari, questa è un'altra storia. In genere, tali progetti hanno un controllo più lento sui flussi di lavoro, ma l'onere di generare richieste pull accettabili ricade più spesso sui singoli collaboratori.

In molti modi questo diventa una domanda di processo. Forse il processo necessario include il controllo periodico (settimanale? Mensile?) Di filiali di lunga durata, non unite. Alcuni strumenti lo rendono semplice da controllare visivamente; ad esempio su github visita il link "rami" e mostra quanto è avanti / dietro ogni ramo.