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

开发人员首先将Feature-a合并到他的Feature-a-sub分支中，然后再进行更新，然后将其Feature-a-sub合并到开发中。而初始功能-分支仍然存在，并且尚未完成。

以我的观点，这产生了一个问题，即现在所有的更改都合并到feature-a-sub中，然后合并到开发中，因此现在已经废弃了feature-a分支。此外，关于功能-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分支策略。尽管白皮书针对的是集中版本控制系统，但每个分支机构可以扮演的角色背后的思想对于确保您了解正在发生的事情以及可以推断出任何给定分支机构下一步应该做什么的想法很重要。