Flusso di lavoro e processo quando i rami hanno dipendenze in git per le revisioni del codice

4

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:

  1. Scrivi codice per FeatureA
  2. Crea PR per FeatureA
  3. Attendi che la FeatureA venga unita al master (aggiornando FeatureA se necessario)
  4. Scrivi codice per FeatureB
  5. 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?

    
posta enderland 01.03.2016 - 19:53
fonte

1 risposta

2

Devi valutare i rischi associati alla dipendenza, ma direi che puoi permetterti di lavorare su B il prima possibile e propagare tutte le modifiche fatte in A in B quando necessario.

  • Se la richiesta pull di A è accettata (build di codice, ecc.), tutto va bene. In media, dovresti incontrare quel caso il più delle volte.
  • Altrimenti, cosa potrebbe accadere? Nel peggiore dei casi, A è completamente rotto e dovrebbe essere cancellato: ciò significa che dovresti rielaborare B più profondamente o lasciarlo cadere. Ma in modo più realistico, è necessario modificare e correggere elementi secondari in A. E se è così, è possibile unirlo al ramo B.

Se il ramo A cambia troppo spesso, non è una buona idea basare il ramo B su di esso.

    
risposta data 01.03.2016 - 20:24
fonte

Leggi altre domande sui tag