Git fusionarse y mantenerse separado?

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

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 desde comete C, G, y H, (Commit J es que fusión) de tal manera que cometen K es todavía una rama lateral (y la futura confirmación L aún está en el maestro), pero ¿tiene la información actualizada del maestro?

no quiero hacer un rebase, porque eso sería terminar con:

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

crear "nuevas versiones" de D, E, y F como si ocurrió en la parte superior de la H en lugar de B y el problema es que confirma C y E es el cambio de nombre de una carpeta de clave en el repositorio, y quiero colapsarlos juntos, sin combinar las otras actualizaciones de funciones desde branchA por el 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 recuperar esa carpeta de nombre (C y E) en el pasado y dejar de avanzar. ¿Eso tiene sentido? ¿Estoy mirando hacia atrás? ¿O debería tratar con el truco desordenado de rebase "name, rename" hasta que la rama se fusione?

Fuente

2011-01-05 MidnightLightning

git merge es la respuesta más simple; Lo estaba experimentando fusionando las dos ramas, e incapaz de continuar las dos por separado ... ¡Pero eso no está sucediendo ahora! – MidnightLightning

También pensé que 'git merge' había combinado dos ramas juntas, en lugar de simplemente fusionar * cambios en * una sola rama. Pero luego descubrí que sin saberlo había creado una rama de tema - * B * - mientras tenía otra rama de tema - * A * - desprotegido, y luego fusioné * B * en * maestro *, sin darme cuenta de que también estaba ¡fusionando todas las confirmaciones en * A *! –

Si su historial sube H o L en el amo y F en branchA (es decir, J y K aún no existen), entonces sí, sólo echa un vistazo a la rama A y combinar:

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 rama principal.

Si ya ha creado cometer K y que desea insertar una fusión entre ésta y F, entonces hay un poco más trabajo que 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 más adelante se funden en uno u otro sentido , commit H será el ancestro común más cercano de ambas ramas 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) cuando decidan cómo fusionarse.

Fuente

2011-01-05 22:33:41 cdhowie

Un simple git merge master en branchA debe hacer (o git merge H donde H es H de cometer-ref si H no es el último en el Master).

Habrá conflictos si tanto C como E cambian el nombre de la misma carpeta que deberá resolver, pero aparte de eso, debería estar bien.

Fuente

2011-01-05 22:36:00

Git fusionarse y mantenerse separado?

Respuesta

Cuestiones relacionadas