Git branching da un ramo di funzione per lavorare su una sottofunzione

Question

Git branching da un ramo di funzione per lavorare su una sottofunzione

#1 da (12 voti)

9

Al momento ci troviamo nella seguente situazione, in cui un ramo di funzionalità è stato diramato per un ramo di sottofunzioni (come, lavorando su backend e cose di frontend per la stessa funzione):

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

Uno sviluppatore ha prima unito la feature-a nel suo ramo di una sub-funzione per essere aggiornato, e quindi ha unito la sua caratteristica-a-sub allo sviluppo. Mentre la funzione iniziale - un ramo è ancora esistente e non ancora terminato.

Dal mio punto di vista, questo genera il problema che il ramo feature-a è ora reso obsoleto, poiché tutte le modifiche sono unite in feature-a-sub e quindi in sviluppo. Inoltre, è proseguito il lavoro su feature-a, che porta a futuri conflitti di fusione e un sacco di lavoro manuale.

Dove abbiamo preso la svolta sbagliata, e come sarebbe un flusso di lavoro adeguato con meno problemi?

git branching

posta pduersteler 18.10.2015 - 17:45

fonte

1 risposta

Leggi altre domande sui tag git branching

Perché FRACTRAN turing è completo? Il ben noto ID aziendale di un'entità deve essere rappresentato con un tipo dedicato in DDD / OOP?

score 12 · Accepted Answer

Uno dovrebbe unirsi solo al ramo padre e da esso. Per feature-a-sub , questo è feature-a , non development .

L'unione con il ramo dei nonni significa che la ragione per cui il ramo padre è stato creato non è stata soddisfatta, e sì, come notato questo crea problemi futuri in cui lo sviluppo continua su feature-a e development che porta a una maggiore divergenza delle linee di codice e più conflitti lungo la strada.

Si supponeva che feature-a-sub dipendesse dal codice in feature-a . Se feature-a-sub era invece indipendente da feature-a , non avrebbe dovuto essere ramificato da feature-a e invece dovrebbe essere stato ramificato (e unito) in development .

Se feature-a ha bisogno di feature-a-sub per funzionare (non è sicuro che abbia fatto come feature-a ha continuato il lavoro senza un'unione di feature-a-sub ) e feature-a-sub era indipendente da feature-a , feature-a-sub dovrebbe invece sono stati feature-b con un ramo da development , una fusione in development e quindi un'unione di development o feature-b (se non si desidera raccogliere altre modifiche dallo sviluppo) in feature-a .

Il flusso di lavoro dovrebbe essere:

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

Correlati - una mia lettura preferita sulla filosofia di branching: Advanced SCM Branching strategie . Mentre il white paper è mirato ai sistemi di controllo delle versioni centralizzati, le idee dietro i ruoli che ogni ramo può assumere sono importanti per essere sicuri di capire cosa sta succedendo e possono ragionare su cosa dovrebbe essere fatto successivamente con un dato ramo.