Gestire una richiesta pull di grandi dimensioni

Lascia che lo sviluppatore che è andato in giro per un paio di mesi senza una fusione lo risolva. Forse riescono a ottenere un grosso pezzo di codice da unire, forse possono ottenere un po 'di piccoli pezzi da unire uno alla volta. In ogni caso, dovrebbero fare i legwork per risolvere il problema, dal momento che lo hanno causato.

What is the best way to deal with such a situation where one branch is really far away from the others?

In generale, non preoccuparti: è il problema dell'altro sviluppatore. Se due rami sono veramente troppo distanti tra loro da 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 di renderlo il tuo problema invece del loro. Altrimenti, non lo è.

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

What ways can we avoid branches getting a very large number of commits away from master in the future?

Assicurati che tutti si accorgano che lo sviluppatore che è andato in giro per mesi senza unire deve risolvere il problema causato. Assicurati che tutti sappiano che è più facile impegnarsi a padroneggiare frequentemente piuttosto che raramente, poiché un minor numero di modifiche comporta minori opportunità di conflitti.

Assicurati che le persone sappiano di poter estrarre dal master per rimanere aggiornati con le modifiche di altre persone.

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

Quella citazione proviene da un discorso che ha pronunciato a Google, ecco la trascrizione e ecco il video .

Se hai un commit che conosci questo e tutti i precedenti commit sono ben testati e devono essere uniti, quindi esegui semplicemente il branch-out da quest'ultimo commit buono e unisci il nuovo branch con master.

Se hai qualche commit che vorresti unire, ma sono intercalati con altri commit che non sono pronti per la produzione, allora vedo 2 possibilità:

1. Crea un nuovo ramo e seleziona i buoni commit, unisci con il master.
2. Prova a ribaltare i commit indesiderati in alto (magari sul nuovo ramo solo per sicurezza).

Per quanto riguarda i metodi di prevenzione, prova a definire alcune regole divertenti del team 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, come suggerito da @Maciej Chalpuk. Se questo è il caso, allora la situazione non è poi così male, e in futuro non mi preoccuperei più di tanto.

Tuttavia, se la situazione reale è che più funzionalità sono state sviluppate contemporaneamente in un singolo ramo, all'interno degli stessi commit, allora diventa un dolore molto più grande da affrontare. Fortunatamente, il metodo di prevenzione è integrato: richiede allo sviluppatore di separare le modifiche per ogni funzione in rami separati e di richiamare le richieste prima di unirle. Entrambe le tue fusioni atomiche, oltre a dissuadere questo sviluppatore dal farlo in il futuro.

L'effettivo processo di separazione delle funzionalità è interamente manuale. Crea nuovi rami fuori dal master e copia in qualsiasi cambiamento dal ramo mega ad esso correlato. Compilare, testare la funzionalità, inviare ed emettere una richiesta di pull. Meno sono mescolate le modifiche al codice, più facile sarà da fare. Se stava hackerando un singolo metodo per tutti loro, beh, divertiti. Non lo farà più.

Ecco una soluzione semplice.

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

Permettetemi di suddividerlo sotto forma di un esempio.

Let: Branch A be the branch from the master Branch A+ = Branch A + new feature 1 Branch A++ = Branch A + new feature 2 and so on and so forth

What you need to do is to go back to: Branch A+

Take Branch A+ and merge it with Master.

Now go to Branch A++ and merge it with (Master + Branch A+).

Repeat until you've reached the final Branch A+...+ that is stable.

In un primo momento questo metodo può sembrare contro-intuitivo, ma se si uniscono ciascuna nuova caratteristica separata con il master, diventa facile passare in rassegna il ramo master " per caratteristica aggiunta "

What ways can we avoid branches getting a very large number of commits away from master in the future?

Penso che la mia soluzione qui sopra indichi quale metodo futuro dovresti adottare. Vai con una funzione per ogni metodo di attività per ogni ramo.

Suggerirei di utilizzare un approccio di:

pre-master e master

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

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

Dovresti anche provare a raggruppare le funzionalità e puntare al targeting per versione.

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

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

Risolvere il problema della richiesta pull di grandi dimensioni è una cosa, e ci sono alcune buone risposte in merito. Ma per quanto riguarda i rami che non sono aggiornati, potresti voler rivisitare i tuoi processi per gestire il lavoro di squadra.

Se lavori in un framework Agile o SCRUM, il team dovrebbe davvero chiedersi il motivo per cui la funzionalità non è stata completata e unita come parte dell'iterazione / sprint. Se fosse "troppo grande" per rientrare in una 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 elementi siano fatti?

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

In molti modi questa diventa una domanda di processo. Forse il tuo processo necessario include periodicamente il controllo (settimanale? Mensilmente?) Per le filiali di lunga durata e non interrotte. Alcuni strumenti rendono questo semplice da controllare visivamente; per esempio. su github visita il link "rami" e mostra quanto è avanti / dietro ogni ramo.