Rozgałęzienie Gita z gałęzi funkcji do pracy nad podfunkcją

Obecnie znajdujemy się w następującej sytuacji, w której gałąź funkcji została rozgałęziona dla gałęzi podfunkcji (np. Praca nad backendem i frontendem dla tej samej funkcji):

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

Deweloper najpierw połączył funkcję-a ze swoją gałęzią-funkcja-sub, aby być na bieżąco, a następnie połączył swoją funkcję-sub-z rozwojem. Podczas gdy początkowa funkcja - gałąź wciąż istnieje, a jeszcze nie została ukończona.

Moim zdaniem powoduje to problem polegający na tym, że gałąź funkcji staje się przestarzała, ponieważ wszystkie zmiany są scalane w funkcję sub, a następnie w rozwój. Ponadto kontynuowano prace nad funkcją a, która prowadzi do przyszłych konfliktów scalania i dużej ilości pracy fizycznej.

Gdzie obróciliśmy niewłaściwy kierunek i jak wyglądałby prawidłowy przepływ pracy przy mniejszych problemach?

One powinny łączyć tylko do iz macierzystego oddziału. Bo feature-a-subtak feature-anie jest development.

Scalenie z gałęzią dziadka oznacza, że ​​powód, dla którego gałąź rodzicielska została utworzona, nie został spełniony, i tak, jak zauważono, stwarza to przyszłe problemy, w których rozwój jest kontynuowany, feature-ai developmentprowadzi do zwiększonej rozbieżności linii kodu i większej liczby konfliktów w dół Droga.

Zakładano, że to feature-a-subzależy od kodu w feature-a. Jeśli feature-a-subzamiast tego był niezależny feature-a, nie powinien być feature-aw ogóle rozgałęziony, a zamiast tego powinien być rozgałęziony (i scalony) development.

W feature-arazie potrzeby feature-a-subdo pracy (nie jestem pewien, czy zrobiło to jako feature-akontynuację pracy bez scalenia feature-a-sub) i feature-a-subbył niezależny od feature-a, feature-a-subpowinien zamiast tego być feature-bz gałęzią development, scaleniem z powrotem do development, a następnie albo scaleniem developmentlub feature-b(jeśli ktoś nie robi nie chcę wybierać innych zmian z rozwoju) do feature-a.

Przepływ pracy powinien być albo:

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 

lub

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             

Powiązane - moja ulubiona lektura na temat filozofii rozgałęziania: Zaawansowane strategie rozgałęziania SCM . Chociaż biała księga jest skierowana do scentralizowanych systemów kontroli wersji, pomysły stojące za rolami, jakie może przyjąć każda gałąź, są ważne dla upewnienia się, że rozumiesz, co się dzieje i może uzasadnić, co należy zrobić z danym oddziałem.