Git mantenendo rami separati in sincronia

Question

Ho lavorato su un ramo new_feature:

A -- B -- C -- D master 
     \ \ 
     \ 1 -- 2 -- 3 new_feature 
     \ 
     E -- F -- G port 

Il nostro codice di base ha anche un ramo più vecchio port dove un altro sviluppatore portato il nostro prodotto ad un altro RDBMS. port non è ancora pronto per essere unito a master.

Recentemente è diventato necessario disporre di new_feature in port. Così ho fuso quei due in un nuovo ramo port/new_feature, e fatto alcuni commit lì (I, J) per farlo funzionare:

A -- B -- C -- D master 
     \ \ 
     \ 1 -- 2 -- 3 -- I* -- J* -- K new_feature 
     \    \ 
     E -- F -- G -- H -- I -- J -- K* port/new_feature 
        port 

I ciliegia raccolte I e J di nuovo in new_feature (come I *, J *) perché hanno implicato un significativo refactoring che volevo avere anche in new_feature. Ho anche effettuato nuovi commit (K) a new_feature che devono essere riportati a port/new_feature (K *).

Andando avanti, qual è il piano migliore per mantenere new_feature e port/new_feature in sincronia (ma solo per quanto riguarda le modifiche apportate a)? Devo mantenere il cherry-picking che commette da uno all'altro (e viceversa)? O c'è un modo conveniente per farlo unendo?

Answer 1

Cherry-picking è pericolosa a causa di:

• duplicato impegna (la prossima fusione sarà complicato perché Git tenterà di riapplicare I-J-K sulla parte superiore del ... I-J-K).
  Non sarebbe il caso se si ribalta un ramo sopra l'altro (vedere "Git cherry pick and datamodel integrity"), ma ciò non è possibile nel tuo caso.

• dipendenze funzionali (vedere "How to merge a specific commit in git"), ma ho il sospetto che non è un problema nel tuo caso: I e J non dipendono da H, e può essere applicato in modo sicuro per 3.

Il cherry picking è utile se non si intende unire la porta e la nuova funzione.
Se è il caso, continua a raccogliere le ciliegie.