Nel flusso di GitHub, è OK basare il ramo di funzionalità su un altro ramo di funzionalità?

Usiamo GitHub Flow nel nostro progetto e la maggior parte delle volte, apriamo un nuovo ramo di funzionalità dal master , facciamo un po 'di lavoro lì, apriamo un PR, rivediamo il codice e ci ricolleghiamo al master .

Tuttavia, il mio lavoro attuale dipende da un altro problema su cui si sta lavorando feature-branch-A. È kosher creare il mio ramo da quell'altro ramo o è contro lo spirito di GitHub Flow?

L'alternativa sarebbe quella di basare il mio ramo su master e unire feature-branch-A(frequentemente) le modifiche .

Quale opzione è preferita nel flusso GitHub?

Ecco il flusso di lavoro che seguo quando eseguo il ramo da un ramo di funzionalità:

1. Crea feature-branch-Bdafeature-branch-A
2. Lavorare su feature-branch-B
3. Se feature-branch-Adopo il branching vengono aggiunti altri commit , rifare feature-branch-Bsufeature-branch-A
4. Termina il lavoro feature-branch-Be attendi fino alla feature-branch-Afusione master.
5. Dopo feature-branch-Aviene unito in master, rifai feature-branch-Bsumaster
6. Unisci feature-branch-Binmaster

Seguendo il flusso di lavoro sopra riportato sembrerà che tu abbia ramificato masterdopo che è feature-branch-Astata unita. Non è necessario attendere fino feature-branch-Aalla fusione per iniziare a lavorare feature-branch-B. Tuttavia, otterrai una storia pulita senza alberi complicati.

Penso che sia completamente ok se crei la funzione su un'altra funzione.

Ma non farlo abbastanza spesso. Vedo uno sviluppatore che ha realizzato questo e una o due settimane lancia 10 PR per la fusione. Ciò è stato completamente estenuante per gli altri membri per la revisione e difficile anche per la fusione. Cerca di non fare alberi in git. Questo aiuta con bisect per trovare errori.

Una cosa chiave che Git-Flow doveva affrontare era la capacità di ragionare sul ruolo di un determinato ramo, e su ciò da cui si dirama e si fonde.

Idealmente, tutti i rami si ricollegano al codice da cui sono stati uniti. Questo è in genere un'unione dalla linea principale (in git-flow questo è dev). I rami delle funzioni si ramificano e si uniscono dallo sviluppatore, rilasciano i rami dei rami e si fondono dallo sviluppatore (con un'ulteriore unione a master). Le correzioni rapide si ramificano e si uniscono dal master (con quell'ulteriore unione in dev).

Ogni codeline si dirama e si fonde nuovamente con il suo genitore. Una codeline può estrarre il codice da altre codeline in qualsiasi momento se è necessario.

Se il ramo di un ramo di funzionalità è un "Voglio esplorare questo modo di risolvere un problema in quel ramo di funzionalità" - perfettamente bene. Si dirama dal ramo della funzione, esegue il commit di un po 'di codice e si unisce nuovamente al ramo della funzione (o viene scartato).

1. ramo dalla funzione
2. esplora l'idea
3. unisci alla funzione

Quello che vuoi evitare, tuttavia, è qualcosa che assomiglia a:

1. ramo dalla funzione richiesta
2. lavorare sul codice
3. unisci da dev una volta completata la funzionalità richiesta
4. verificare la funzionalità (e ulteriori commit) nel ramo delle funzionalità
5. unisci a dev

Il motivo è che l'inizio e la fine non coincidono - rende un po 'più difficile capire cosa sia ed era. Non impossibile, ma ci vuole solo un po 'più di tempo perché qualcuno capisca il suo ruolo.

Tuttavia, se questa è una nuova funzionalità che dipende dal codice che non è stato ancora trovato in dev, il flusso dovrebbe essere:

1. ramo da dev
2. unisci dalla funzione richiesta
3. lavorare sul codice
4. unisci da dev una volta completata la funzionalità richiesta
5. verificare la funzionalità (e ulteriori commit) nel ramo delle funzionalità
6. unisci a dev

Si noti che questo inizia con un ramo da dev e termina con un'unione a dev.

Detto questo, probabilmente la cosa migliore da fare è evitare di unire una funzionalità all'altra. Diramazione della funzione, fare qualsiasi preliminare necessario ... e attendere.

1. ramo da dev
2. lavorare sul codice
3. unisci da dev una volta completata la funzionalità richiesta
4. verificare la funzionalità (e ulteriori commit) nel ramo delle funzionalità
5. unisci a dev

Ciò fornisce l'insieme più stabile di rami e codice.

Qualcosa da considerare per il lavoro futuro sarebbe avere una funzione per pubblicare le interfacce necessarie per l'interoperabilità con altre funzionalità, anche se il codice di implementazione non è completo. Questo sarebbe unito a dev, e quindi la funzionalità richiesta potrebbe funzionare al di fuori di quelle interfacce come potrebbe la funzionalità futura. Ciò probabilmente consentirebbe alle funzionalità future di progredire ulteriormente (codifica rispetto alle interfacce, test su stub che implementano le interfacce) rispetto a quanto farebbe se dovesse attendere che la funzionalità richiesta si unisca allo sviluppo.

Un ramo di funzionalità è normalmente considerato meno stabile del trunk (sviluppo / master), quindi è possibile sottoporsi a modifiche più profonde del normale se si basa il proprio lavoro su uno.

Inoltre, mentre normalmente è disapprovato se il ramo è stato spinto, non è raro riposizionare i rami delle caratteristiche sul loro ramo padre, per ottenere una cronologia più bella, ma sarebbe molto più complicato se ci fossero rami aggiuntivi che pendono da esso, quindi tu stai essenzialmente creando una nuova restrizione per il proprietario della filiale madre, nonché potenziali mal di testa per te stesso.

Detto questo, non esiste una regola rigida contro di essa. Dopotutto, questi sono solo schemi e buone pratiche.

Modifica: mancata parte della tua domanda. Unire il ramo delle funzionalità nel proprio, che è basato sul master, non evita davvero nessuno dei problemi sopra menzionati e potrebbe effettivamente creare una storia ancora più complicata.

Quindi se fossi nei tuoi panni e potessi rimandare il lavoro fino a quando la funzione a non fosse terminata, o fare prima qualcos'altro, lo farei.