피처 브랜치에서 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를 피쳐 하위 분기에 병합하여 최신 상태로 만든 다음 피쳐를 서브 개발에 병합했습니다. 초기 기능인 분기는 여전히 존재하지만 아직 완료되지 않았습니다.

필자의 관점에서 볼 때, 모든 변경 사항이 하위 기능으로 병합 된 다음 개발로 병합되므로 기능-지점이 이제 더 이상 사용되지 않는 문제가 발생합니다. 또한 기능 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             

관련- 브랜치 철학 에 대한 내가 가장 좋아하는 읽기 : Advanced SCM Branching Strategies . 이 백서는 중앙 집중식 버전 제어 시스템을 대상으로하지만 각 지점에서 수행 할 수있는 역할에 대한 아이디어는 진행중인 사항을 이해하고 특정 지점에서 다음에 수행해야 할 사항을 추론 할 수 있도록하는 데 중요합니다.