Git se fusionan y se mantienen separados?

¿Hay alguna forma de actualizar una twig secundaria con información de otra (maestra u otra), y luego hacer que las dos continúen? ¿Como una rebase, pero manteniendo los datos antiguos allí?

Original:

A---B---C---G---H master \ D---E---F branchA 

Resultado:

 A---B---C---G---H---L master \ \ D---E---F---J---K branchA 

Tal que branchA obtiene la información de commit C, G y H, (Commit J es esa fusión) tal que commit K sigue siendo una twig secundaria (y el futuro commit L aún está en master), pero tiene la información actualizada de master?

No quiero hacer una rebase, porque eso terminaría con:

 A---B---C---G---H---L master \ D'---E'---F'---K branchA 

Creando "nuevas versiones" de D, E y F como si sucedieran sobre H en lugar de B, y el problema es que confirma C y E es el cambio de nombre de una carpeta de key en el repository, y quiero queuepsarlas juntos , sin combinar las otras actualizaciones de branchA de branchA momento. Rebase significa que H usa el nuevo nombre de carpeta, D 'crea el nombre de la carpeta anterior y E' lo elimina nuevamente, que no es el más limpio.

El punto es que quiero que esa carpeta cambie de nombre (C y E) en el pasado y deje de llevarlo adelante. ¿Eso tiene sentido? ¿Estoy mirando hacia atrás? ¿O debería tratar con el desorderado rebase "name, rename" truco hasta que se fusione la twig?

Solutions Collecting From Web of "Git se fusionan y se mantienen separados?"

Si su historial va a H o L en el maestro y F en la twig A (es decir, J y K aún no existen), entonces sí, simplemente revise la twig A y fusione:

 git checkout branchA git merge H # Use H's commit identifier if it's not the tip of master 

Esto fusionará los cambios en branchA y no perturbará en absoluto la twig principal.

Si ya ha creado commit K y desea insert una combinación entre él y F, entonces hay un poco más de trabajo por hacer:

 git checkout -b temp F # Create a new branch at commit F git merge H # Merge from commit H into the new branch git cherry-pick K # Apply the K commit to the merged commit # And the rest simply replaces the temp branch with branchA git checkout branchA git reset --hard temp git branch -d temp 

En ambos casos, si luego se fusiona en cualquier dirección, la confirmación H será el ancestro común más cercano de ambas twigs de historial, por lo que las fusiones futuras no mirarán más allá de este compromiso (o pasarán de J a F tampoco) al decidir cómo fusionarse.

Un simple git merge master en branchA debería hacer (o git merge H donde H es commit-ref de H si H no es el último en master).

Habrá conflictos si tanto C como E renombran la misma carpeta que tendrás que resolver, pero aparte de eso, deberías estar bien.