Git-ветвление из функциональной ветки для работы над подфункцией

В настоящее время мы находимся в следующей ситуации, когда ветвь компонента была разветвлена ​​для ветви подфункции (например, работа с внутренним и внешним интерфейсом для одной и той же функции):

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

Сначала разработчик объединил элемент-a в свою ветку feature-a-sub, чтобы быть в курсе последних событий, а затем включил свой элемент-a-sub в разработку. Принимая во внимание, что начальная особенность - ветвь все еще существует, и еще не закончена.

На мой взгляд, это приводит к проблеме, заключающейся в том, что ветвь Feature-A теперь становится устаревшей, так как все изменения объединяются в Feature-a-Sub, а затем в разработку. Кроме того, продолжается работа над функцией a, которая приводит к будущим конфликтам слияний и большому количеству ручного труда.

Где мы пошли не по тому пути, и как будет выглядеть правильный рабочий процесс с меньшими трудностями?

Один должен объединить только и из родительской ветви. Ибо feature-a-subэто feature-aне так development.

Слияние с прародительской ветвью означает, что причина, по которой была создана родительская ветвь, не была выполнена, и да, как уже отмечалось, это создает будущие проблемы, когда развитие продолжается feature-aи developmentведет к увеличению расхождений строк кода и большему количеству конфликтов в дальнейшем. Дорога.

Предполагалось, что это feature-a-subзависит от кода в feature-a. Если feature-a-subвместо этого он был независим от feature-a, он вообще не должен был быть разветвленным, feature-aа должен был быть разветвлен (и объединен) development.

Если feature-aнеобходимо feature-a-subработать (не уверен, что он работал как feature-aпродолженная работа без слияния с feature-a-subним) и feature-a-subне зависел от него feature-a, feature-a-subвместо этого он должен был быть feature-bс ответвлением от development, слиянием обратно developmentи затем слиянием developmentили feature-b(если не хочу забирать другие изменения из разработки) в feature-a.

Рабочий процесс должен быть:

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 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             

Связанный - мое любимое чтение по философии ветвления: Расширенные стратегии ветвления SCM . В то время как технический документ предназначен для централизованных систем контроля версий, идеи, лежащие в основе ролей, которые может выполнять каждая ветвь, важны для того, чтобы вы понимали, что происходит, и могли рассуждать о том, что следует делать дальше с любой данной ветвью.