Git ramificando desde una rama de características para trabajar en una subfunción

Actualmente nos encontramos en la siguiente situación, en la que se ha bifurcado una rama de características para una rama de subfunciones (por ejemplo, trabajando en cosas de backend y frontend para la misma característica):

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

Un desarrollador fusionó primero la función-a en su rama de función-a-sub para estar al día, y luego fusionó su función-a-sub en el desarrollo. Mientras que la característica inicial-una rama todavía existe, y aún no está terminada.

En mi punto de vista, esto genera el problema de que la rama característica-a ahora queda obsoleta, ya que todos los cambios se fusionan en característica-a-sub y luego en desarrollo. Además, el trabajo ha continuado en la característica a, lo que conduce a futuros conflictos de fusión y mucho trabajo manual.

¿Dónde dimos el giro equivocado y cómo sería un flujo de trabajo adecuado con menos problemas?

Uno solo debe fusionarse hacia y desde la rama principal. Pues feature-a-sub, esto es feature-a, no development.

La fusión con la rama de los abuelos significa que la razón por la que se creó la rama principal no se ha cumplido, y sí, como se señaló, esto crea problemas futuros donde el desarrollo continúa feature-ay developmentconduce a una mayor divergencia de las líneas de código y más conflictos en el futuro. la carretera.

Esto suponía que feature-a-subdependía del código en feature-a. Si feature-a-sub, en cambio, era independiente de feature-a, no debería haberse bifurcado feature-ay, en su lugar, debería haberse bifurcado (y fusionado) development.

Si fuera feature-anecesario feature-a-subpara trabajar (no estoy seguro de que lo hiciera como feature-aun trabajo continuo sin una fusión feature-a-sub), y feature-a-subfuera independiente de feature-a, feature-a-subdebería haber estado feature-bcon una rama de development, una fusión de nuevo en development, y luego una fusión de developmento feature-b(si uno no No quiero recoger otros cambios del desarrollo) en feature-a.

El flujo de trabajo debería 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 

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             

Relacionado: una de mis lecturas favoritas sobre la filosofía de la ramificación: Estrategias avanzadas de ramificación SCM . Si bien el documento técnico está dirigido a los sistemas de control de versiones centralizados, las ideas detrás de los roles que puede tomar cada rama son importantes para asegurarse de que comprende lo que está sucediendo y puede razonar sobre lo que se debe hacer a continuación con cualquier rama determinada.