Nel flusso GitHub, è corretto basare il ramo di funzione su un altro ramo di funzione?

Ecco il flusso di lavoro che seguo quando si diramano da un ramo di funzione:

1. Crea feature-branch-B da feature-branch-A
2. Lavora su feature-branch-B
3. Se vengono aggiunti più commit a feature-branch-A dopo la diramazione, rebase feature-branch-B a feature-branch-A
4. Completa il lavoro su feature-branch-B e aspetta che feature-branch-A venga unito in master .
5. Dopo feature-branch-A viene unito in master , rebase feature-branch-B in master
6. Unisci feature-branch-B in master

Seguendo il flusso di lavoro sopra riportato sembrerà che tu abbia ramificato da master dopo che feature-branch-A è stata unita. Non devi aspettare fino a quando feature-branch-A viene unito per iniziare il lavoro su feature-branch-B . Eppure, otterrai una storia pulita senza alberi complicati.

Penso che tutto sia a posto se crei la funzione su un'altra funzione.

Ma non farlo abbastanza spesso. Vedo uno sviluppatore che ha fatto questo e una o due settimane ha buttato fuori 10 PR per la fusione. Questo è stato completamente estenuante per gli altri membri per la revisione e difficile anche per la fusione. Prova a non rendere gli alberi in git. Questo aiuta a bisect per trovare errori.

Una cosa fondamentale a cui Git-Flow doveva rispondere era la capacità di ragionare sul ruolo di un determinato ramo, e su ciò da cui si dirama e si fonde con esso.

Idealmente, tutti i rami si uniscono alla codeline dalla quale sono stati fusi. Questa è tipicamente un'unione dalla linea principale (in git-flow questo è dev ). Branche delle feature diramano e fondono da dev, rilasciano branch branch e si uniscono da dev (con un'ulteriore unione a master ). Le correzioni rapide si diramano e si uniscono dal master (con quella unione aggiuntiva a dev).

Ogni codeline si dirama da e si ricongiunge al suo genitore. Una codeline può inserire 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 a posto. Si dirama dal ramo della funzione, esegue il commit di un codice e si collega al ramo della funzione (o viene scartato).

1. branch from feature
2. esplora l'idea
3. Unisci a funzionalità

Quello che vuoi evitare è qualcosa che assomiglia a:

1. derivazione dalla funzione richiesta
2. lavora sul codice
3. unisci da dev una volta richiesto-la funzione è completa
4. verifica la funzionalità (e ulteriori commit) nel ramo di funzione
5. unisci a dev

Il motivo è che l'inizio e la fine non coincidono - rende un po 'più difficile capire cosa sia e cosa sia. Non impossibile, ma semplicemente lo rende prendi un po 'più di tempo per far capire a qualcuno il suo ruolo.

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

1. branch from dev
2. Unisci dalla funzione richiesta
3. lavora sul codice
4. unisci da dev una volta richiesto-la funzione è completa
5. verifica la funzionalità (e ulteriori commit) nel ramo di funzione
6. unisci a dev

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

Tutto ciò che è stato detto, probabilmente la cosa migliore da fare è evitare di fare un'unione da una funzione a un'altra. Separa la funzione, fai i preliminari necessari ... e aspetta.

1. branch from dev
2. lavora sul codice
3. unisci da dev una volta richiesto-la funzione è completa
4. verifica la funzionalità (e ulteriori commit) nel ramo di funzione
5. unisci a dev

Questo fornisce il set più stabile di rami e codice.

Qualcosa da considerare per il lavoro futuro sarebbe avere una funzionalità 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 funzione richiesta potrebbe funzionare su quelle interfacce come potrebbe la funzione futura. Questo probabilmente consentirebbe alle funzionalità future di progredire ulteriormente (codificare contro le interfacce, testare gli stubbs che implementano le interfacce) di quanto sarebbe se dovesse aspettare che la funzione richiesta si unisca a dev.

Un ramo caratteristica è normalmente considerato meno stabile del tronco (sviluppo / master), quindi è possibile sottoporsi a più cambiamenti sottostanti del normale se si basa il lavoro su di uno.

Inoltre, mentre normalmente si disapprovano se il ramo è stato premuto, non è raro rebase i rami delle funzionalità sul ramo padre, per ottenere una cronologia migliore, ma sarebbe più complicato se ci fossero altri rami che ne pendevano. , quindi stai essenzialmente creando una nuova restrizione per il proprietario del ramo principale, oltre a potenziali mal di testa per te stesso.

Detto questo, non esiste una regola severa contro di essa. Questi sono solo modelli e buone pratiche, dopotutto.

Modifica: parte mancante della tua domanda. L'unione tra il ramo della funzione e il proprio, basato sul master, non evita in realtà nessuno dei problemi menzionati sopra e potrebbe effettivamente creare una cronologia ancora più complessa.

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