Esegui il branching da un ramo di funzionalità per lavorare su una funzionalità secondaria

Siamo attualmente nella seguente situazione, in cui un ramo di funzionalità è stato ramificato per un ramo di funzionalità secondaria (ad esempio, lavorando su elementi di backend e frontend per la stessa funzionalità):

o 
|
o development
|\
| o feature-a
| |
| o
| |\
| | o feature-a-sub
| | |
| | |
|  \
|   o merged feature-a into feature-a-sub
|  /
o feature-a-sub merged into development
| |
| o feature-a with future work on it
|
o development

Uno sviluppatore ha prima unito funzionalità-a nel suo ramo funzionalità-a-sub per essere aggiornato, quindi ha unito le sue funzionalità-a-sub allo sviluppo. Considerando che la caratteristica iniziale - un ramo è ancora esistente e non ancora terminato.

Dal mio punto di vista, ciò comporta il problema che la feature-a branch è ora resa obsoleta, poiché tutte le modifiche vengono unite in feature-a-sub e quindi nello sviluppo. Inoltre, è proseguito il lavoro sulla feature-a, che porta a futuri conflitti di fusione e un sacco di lavoro manuale.

Dove abbiamo preso la svolta sbagliata e come sarebbe un flusso di lavoro adeguato con meno problemi?

Si dovrebbe unire solo da e verso il ramo padre. Per feature-a-subquesto è feature-a, non è development.

La fusione con il ramo del nonno significa che la ragione per cui il ramo genitore è stato creato non è stata soddisfatta, e sì, come notato, questo crea problemi futuri in cui lo sviluppo continua feature-ae developmentporta ad una divergenza crescente delle linee di codice e più conflitti nel strada.

Questo presupponeva che feature-a-subdipendesse dal codice in feature-a. Se feature-a-subinvece fosse indipendente da feature-a, non avrebbe dovuto essere ramificato da feature-atutti e invece avrebbe dovuto essere ramificato (e unito) in development.

Se feature-anecessario feature-a-subper funzionare (non sono sicuro che ha fatto come feature-alavoro continuo senza una fusione di feature-a-subesso), ed feature-a-subera indipendente da feature-a, feature-a-subavrebbe dovuto invece essere feature-bcon un ramo da development, una fusione di nuovo in development, e quindi o una fusione di developmento feature-b(se uno non lo fa non voglio raccogliere altri cambiamenti dallo sviluppo) in feature-a.

Il flusso di lavoro dovrebbe essere:

o                                        
|                                        
o development                            
|\                                       
| o feature-a                            
| |                                      
| o                                      
| |\                                     
| | o feature-a-sub                      
| | |                                    
| | |                                    
| | |                                    
| | o merged feature-a into feature-a-sub
| |/                                     
| o feature-a-sub merged into feature-a  
| |                                      
| o feature-a with future work on it     
|                                        
o development 

o

o                                                  
|                                                  
o development                                      
|\                                                 
| \                                                
|  \                                               
|   o feature-a                                    
|\  |                                              
| b | feature-b                                    
| | |                                              
| | |                                              
| | |                                              
| b | feature-b complete                           
|/ \|                                              
o   o feature-b merged to development and feature-a
|   |                                              
|   o feature-a with future work on it             

Correlato: una mia lettura preferita sulla filosofia della ramificazione: strategie di ramificazione avanzate di SCM . Mentre il white paper è indirizzato ai sistemi centralizzati di controllo delle versioni, le idee alla base dei ruoli che ciascun ramo può assumere sono importanti per assicurarsi di capire cosa sta succedendo e di poter ragionare su cosa dovrebbe essere fatto in seguito con un determinato ramo.