git rebase después de git merge anterior

tengo la siguiente situación:git rebase después de git merge anterior

he creado un clone (Y) de un repositorio principal (X), porque había muchas personas que trabajan en Y que no hicimos ningún rebase pero solo merge s. Cuando queremos entregar (push) Y a X nos gustaría hacer un rebase el fin de tener todo limpio y ordenado

El problema es que cuando se hace rebase se nos pide hacer todas las combinaciones que ya lo hizo en los pasos anteriores merge. ¿Hay alguna solución a esto, además de la que significa realmente volver a hacer las fusiones?

Esperaba que fuera bastante sencillo ya que ya resolvimos las fusiones conflictivas.

Fuente

2011-06-06 INS

En: "Debido a que había mucha gente trabajando en Y, no hicimos ninguna rebase pero solo se fusiona", ¿quiere decir fusionarse con la corriente ascendente? –

La recalibración para obtener un historial "limpio" está sobrevalorada. La mejor forma de preservar el historial es simplemente hacer la fusión en lugar de una rebase. De esta forma, si alguna vez necesita volver a una revisión, es exactamente la misma que la que probó durante el desarrollo. Eso también resuelve su problema sobre los conflictos de fusión resueltos previamente.

Si no le importa preservar el historial, puede crear una nueva rama fuera del maestro, verifíquela, luego haga un git read-tree -u -m dev para actualizar su árbol de trabajo para que coincida con la rama dev. Entonces puedes comprometer todo en un gran compromiso y fusionarlo en maestro como siempre.

Fuente

2011-06-06 22:16:33

Lo que has hecho efectivamente aquí es una combinación. La nueva rama es innecesaria. –

@isakgilbert Es lo mismo si se fusiona con '--squash'.Una fusión regular agregará _N_ o _N + 1_ commits para dominar si hubiera _N_ commits en la rama. La sugerencia anterior, o 'merge --squash', siempre agregará solo una confirmación para master. – peterflynn

@ytpete, sí exactamente. Siento que lo anterior es solo una forma indirecta de hacer una combinación: cambio de desarrollador a maestro. "Crear una nueva rama" solo apunta al mismo lugar que el maestro. "Comprometer todo en un gran compromiso" es simplemente hacer la calabaza. –

Dos observaciones:

puede rebasar su propio (no todavía empujados) trabajan tantas veces como desee en la parte superior de confirmaciones recién descabellada.
Puede evitar los conflictos de combinación (durante la rebase) si tiene activated git rerere, lo que se hace para este tipo de situación.
Ver más en git rerere.

Fuente

2011-06-06 07:24:04 VonC

lamentablemente no tuve 'rerere' activado ... – INS

@lulian: en ese caso, si tiene que volver a basar su trabajo, creo que tendrá que hacer esas combinaciones de resolución de conflictos nuevamente. – VonC

El enlace a la activación de rerere no funciona. – krlmlr

git merge --squash ahora es mi forma preferida de rebase después de una gran cantidad de trabajo y muchas fusiones (see this answer). Si la rama que está trabajando se llama my-branch y desea reajustar desde master a continuación, sólo hacer lo siguiente:

git checkout my-branch 
git branch -m my-branch-old 
git checkout master 
git checkout -b my-branch 
git merge --squash my-branch-old 
git commit

Fuente

2013-06-17 06:25:29

que puede tomar todos los cambios en su rama y ponerlos en un nuevo compromiso en master con lo siguiente:

git diff master > my_branch.patch 
git checkout master 
patch -p1 < my_branch.patch

Luego, organice sus archivos y comprométase.

Fuente

2017-04-28 18:56:07 dbaston

git rebase después de git merge anterior

Respuesta

Cuestiones relacionadas