Git ramificação de uma ramificação de recurso para trabalhar em uma sub-característica

Atualmente, estamos na seguinte situação, em que uma ramificação de recurso foi ramificada para uma ramificação de subfuncionalidade (como trabalhar no backend e frontend do mesmo recurso):

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

Um desenvolvedor primeiro mesclou o recurso-a em sua ramificação recurso-a-sub para estar atualizado e, em seguida, mesclou seu recurso-a-sub no desenvolvimento. Enquanto o recurso inicial - um ramo ainda existe, e ainda não foi concluído.

Do meu ponto de vista, isso gera o problema de que o ramo feature-a agora se torna obsoleto, pois todas as alterações são mescladas no feature-a-sub e depois no desenvolvimento. Além disso, o trabalho continuou no recurso-a, o que leva a futuros conflitos de mesclagem e muito trabalho manual.

Onde nós tomamos a curva errada e como seria um fluxo de trabalho adequado com menos problemas?

Só se deve mesclar de e para o ramo pai. Pois não feature-a-subé feature-aisso development.

A mesclagem com a ramificação dos avós significa que a razão pela qual a ramificação pai foi criada não foi cumprida e, sim, conforme observado, isso cria problemas futuros nos quais o desenvolvimento continua feature-ae developmentleva a uma divergência maior das linhas de código e mais conflitos no processo. estrada.

Isso pressupunha que feature-a-subdependesse do código feature-a. Se, ao feature-a-subcontrário, fosse independente feature-a, não deveria ter sido ramificado feature-ae deveria ter sido ramificado (e mesclado) development.

Se feature-anecessário, feature-a-subpara trabalhar (não tenho certeza de que ele fez o feature-atrabalho contínuo sem uma mesclagem feature-a-sub), e feature-a-subera independente de feature-a, feature-a-subdeveria ter sido feature-bcom uma ramificação de development, uma mesclagem de volta para developmente, em seguida, uma mesclagem de ( developmentou, feature-bse não deseja pegar outras mudanças do desenvolvimento) no feature-a.

O fluxo de trabalho deve ser:

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 

ou

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             

Relacionado - uma leitura minha favorita sobre a filosofia da ramificação: Estratégias Avançadas de Ramificação SCM . Embora o white paper seja voltado para sistemas centralizados de controle de versão, as idéias por trás das funções que cada filial pode assumir são importantes para garantir que você entenda o que está acontecendo e possa raciocinar sobre o que deve ser feito a seguir com qualquer filial.