2012-02-24 14 views
31

Tengo un proyecto con una rama de desarrollo y una rama de producción. Recientemente, he estado trabajando en un nuevo conjunto de funciones en dev, por lo que no me he incorporado a la producción durante unas dos semanas. Mientras tanto, sin embargo, había algunos errores que debían corregirse en la producción.¿Cuál es la mejor manera de forzar una fusión en git?

En su mayor parte, pude hacer las correcciones en dev y seleccionarlas en la producción. A veces, sin embargo, necesitaría arreglar la producción a mano, ya que las soluciones eran sustancialmente diferentes en las dos ramas. El punto es que las dos ramas han divergido bastante desde que se separaron.

Ahora quiero simplemente empujar a todos los desarrolladores hacia la producción. No me importa mantener ninguna de las confirmaciones en producción desde la división, solo quiero que la producción se vea exactamente como dev. [EDITAR: Quiero que la producción se vea exactamente como dev desde la división, pero no quiero reescribir el historial antes de la división] Sin embargo, cuando intento fusionarme, recibo docenas de conflictos que prefiero no corregir por mano.

¿Cuál es la mejor manera de forzar una fusión en git? ¿Puedo revertir mis cambios de producción a la división y luego avanzar rápidamente a la rama de desarrollo?

Respuesta

26

Usted sólo puede empujar a su rama dev en el maestro rama de producción de recompra:

git push --force upstream-remote dev:production 

upstream-remote sólo puede ser origin si estás en un clon defecto.

Actualizado para la pregunta mod'ed:

Es probable que no quiere revert en el sentido de git, pero, sí, eso es más o menos lo que quiere hacer. Algo así como

git checkout -b merge <split hash> 
git merge dev 
git push --force origin merge:production 

< división de hash > fue la última confirmación de producción que desea mantener.

+0

Hmmm existente, en realidad creo que equivoqué cuando dije que quería "la producción se vea exactamente como prog." Lo que quería decir es que quería que la rama se viera exactamente como dev * desde la división *. Es decir, quiero tener todos los dev commits desde que la división se aplicó a la producción, sin preocuparse por los compromisos de producción. Sin embargo, no quiero reescribir el historial * antes * de la división, lo que parece que haría tu solución. –

+1

Las dos ramas fueron las mismas en la división? Así es como suena. Si es así, tenían la misma historia antes de la división y para que no pierdas nada. – smparkes

+0

El historial de la sucursal no era el mismo. Supongo que sigo hablando mal. Hace dos semanas los archivos eran todos idénticos, y acababa de fusionarme de dev en producción limpiamente. Después de eso comenzaron a divergir, eso es lo que llamaba la división. Pero la historia de las dos ramas es diferente. –

-4

Esto se fusionará su newBranch en baseBranch

git checkout <baseBranch> // checkout baseBranch 
git merge -s ours <newBranch> // this will simply merge newBranch in baseBranch 
git rm -rf . 
git checkout newBranch -- . 
+0

El lector debe tener en cuenta '-s ours' sobrescribirá el trabajo existente, mientras que' -X nuestro' permitirá que no diferencias conflictivas para fusionarse.'-s ours' hará que una rama tenga el mismo estado que la otra, mientras que' -X our' no se limita a cortar una rama. No estoy corrigiendo la respuesta propuesta, pero señalando un detalle importante. – haleonj

Cuestiones relacionadas