Un flusso di lavoro abbastanza comune per lavorare con git è:
- Fork master
- Apporta modifiche / aggiungi funzionalità nel ramo
- Esegui la richiesta pull per il tuo branch vs master
- Unisci richiesta pull (dopo la revisione del codice, test automatici, qualunque sia)
È anche possibile eseguirlo parallelamente ad un altro fork - forse si sta aggiungendo FeatureB e contemporaneamente si effettua una patch fix a FeatureA, si possono avere due rami separati entrambi basati sul ramo master.
Funziona bene quando hai un progetto consolidato, in cui puoi lavorare su pezzi indipendenti più facilmente. Tuttavia, quando si ha un progetto meno consolidato (forse è un nuovo progetto o orribilmente fragile) è probabile che si possa avere FeatureA e quindi disattivare FeatureB disattivando FeatureA.
Se hai un processo di revisione del codice, significa che hai qualcosa del tipo:
- Scrivi codice per FeatureA
- Crea PR per FeatureA
- Attendi che la FeatureA venga unita al master (aggiornando FeatureA se necessario)
- Scrivi codice per FeatureB
- Crea PR per FeatureB
A seconda del tempo di risposta, il passaggio (3) potrebbe richiedere un po 'di tempo - quindi è probabile che tu debba iniziare dal punto (4) e fare (3) / (4) accadere allo stesso tempo. Potresti persino essere pronto per (5) che accada.
Il problema è che stai scrivendo codice aggiuntivo che dipende dalla funzionalità non revisionata OPPURE non stai lavorando su nulla finché la revisione del codice non elabora FeatureA. E potenzialmente pronto a fare un PR per FeatureB prima che il suo PR dipendente venga unito.
Ci sono alcune possibilità per risolvere questo (fare una PR contro la filiale di FeatureA, attendere che la PR di FeatureA continui, continuare ad aggiornare la funzione PR di una caratteristica).
Che cos'è un buon flusso di lavoro per gestire le difficoltà associate alle richieste di pull dipendenti?