rama - git push tag

Rehaciendo una fusión revertida en Git (5)

Acabo de encontrar esta publicación cuando me enfrento al mismo problema. Por encima de todo, me da miedo poner remedios, etc. Terminaré borrando algo que no quiero y no podré recuperarlo.

En cambio, revisé la confirmación a la que quería que la rama volviera, por ejemplo, git checkout 123466t7632723 . Luego convertí a una rama git checkout my-new-branch . Luego borré la rama que no quería más. Por supuesto, esto solo funcionará si puedes tirar la rama que arruinaste.

Me he encontrado con un problema aquí: tenía una rama específica de un problema 28s en Git, que me fusioné en la rama de develop general. Resulta que lo había hecho demasiado rápido, así que utilicé git-revert para deshacer la fusión. Ahora, sin embargo, ha llegado el momento de fusionar 28s en el develop , pero el comando git-merge ve la fusión original, y felizmente anuncia que todo está bien y las ramas ya se han fusionado. ¿Qué hago ahora? Crear un "Revertir" Revertir "28s -> desarrollar" "''confirmar? No parece ser una buena manera de hacerlo, pero no puedo imaginarme otro en este momento.

Cómo se ve la estructura del árbol:

En lugar de usar git-revert , podrías haber usado este comando en la rama de devel para tirar (deshacer) la confirmación de fusión incorrecta (en lugar de solo revertirla).

git checkout devel git reset --hard COMMIT_BEFORE_WRONG_MERGE

Esto también ajustará el contenido del directorio de trabajo en consecuencia. Ten cuidado

Guarde sus cambios en la rama de desarrollo (ya que la combinación incorrecta) porque ellos también serán borrados por el git-reset . ¡Todos los commits después del que especifiques ya que el argumento de git reset desaparecerá!
Además, no haga esto si sus cambios ya fueron extraídos de otros repositorios porque el restablecimiento reescribirá el historial.

Recomiendo estudiar detenidamente la página man de git-reset antes de probar esto.

Ahora, después del restablecimiento, puede volver a aplicar sus cambios en devel y luego hacer

git checkout devel git merge 28s

Esta será una combinación real de 28s en devel como la inicial (que ahora está borrada de la historia de git).

Para revertir la reversión sin atornillar demasiado su flujo de trabajo:

Crea una copia de basura local de develop
Revertir el compromiso de revertir en la copia local de desarrollar
Combina esa copia en tu rama de características e inserta tu rama de características en tu servidor de git.

Su rama de características ahora debería poder fusionarse de forma normal cuando esté listo para ello. El único inconveniente aquí es que tendrás algunos commit / revert extra en tu historial.

Supongamos que tienes tanta historia

---o---o---o---M---W---x-------x-------* / ---A---B

Donde A, B falló commits y W - es revertir de M

Así que antes de empezar a solucionar los problemas que encuentro, selecciono con precisión W commit para mi sucursal

git cherry-pick -x W

Luego revertir W commit en mi rama

git revert W

Después de que pueda continuar arreglando.

La historia final podría verse así:

---o---o---o---M---W---x-------x-------* / / ---A---B---W---W`----------C---D

Cuando envío un RP, se mostrará claramente que PR se revierte y agrega algunos nuevos commits.

Tienes que "revertir la reversión". Depende de cómo revertiste eso, puede que no sea tan fácil como parece. Mire el documento oficial sobre este tema .

---o---o---o---M---x---x---W---x---Y / ---A---B-------------------C---D

permitir:

---o---o---o---M---x---x-------x-------* / / ---A---B-------------------C---D

Pero, ¿todo funciona? Claro que sí. Puede revertir una fusión, y desde un punto de vista puramente técnico, git lo hizo de forma muy natural y no tuvo problemas reales.
Simplemente lo consideró un cambio de "estado antes de la fusión" a "estado después de la fusión", y eso fue todo.
Nada complicado, nada extraño, nada realmente peligroso. Git lo hará sin siquiera pensarlo.
Por lo tanto, desde un punto de vista técnico, no hay nada de malo en revertir una combinación, pero desde un ángulo de flujo de trabajo es algo que generalmente debería evitarse .
Si es posible, por ejemplo, si encuentra un problema que se fusionó en el árbol principal, en lugar de revertir la fusión, intente realmente :
dividir el problema en dos en la rama que se fusionó, y simplemente arreglarlo,
o intente revertir la confirmación individual que lo causó.
Sí, es más complejo y no, no siempre va a funcionar (a veces la respuesta es: "Vaya, realmente no debería haberlo fusionado, porque aún no estaba listo, y realmente necesito deshacer todo el unir"). Entonces, realmente deberías revertir la fusión, pero cuando quieras volver a hacer la fusión, ahora debes hacerlo invirtiendo la reversión.