¿Cómo reiniciar HEAD a una determinada confirmación sin perder el último commit (s) en Git?

enter image description here

Mi aplicación se rompe No pude encontrar dónde están los errores, sé que comenzó a romperse en la confirmación ( 2201e03 ) que hice.

No estoy seguro de cómo ir por encima de eso, así que decidí hacer un git reset --hard 619176e para restablecer mi aplicación a donde solía funcionar.

Es trabajo ahora. Recibí el post "HEAD ahora está en 619176e Fix UI in CD Create and Edit" y mi aplicación también está de vuelta ahora. Bueno !

Luego, desarrollo más, guardo, me comprometo e bash presionar nuevamente, y NO PUEDO. Tan pronto como hago cambios, y trato de presionar, recibo un post que dice que estoy detrás de 7 commits, y que debería realizar y TIRAR y luego PUSH. Pero no quiero eso.

Si lo hago, mi aplicación se romperá de nuevo. Por lo tanto, incluso si estoy detrás de 7 commits ahora. Realmente no quiero eliminar esas confirmaciones todavía, pero aún quiero avanzar desde 619176e.

Que debería hacer ? Si quiero mantener esos 7 commits Y forzar a git a pensar que 619176e es mi HEAD o MASTER? y pasar de aquí?

¿Debo usar git reset HEAD^ ?

¡Cualquier consejo o sugerencia será de gran ayuda para mí!

El problema básico es que no desea deshacerse de los git reset --hard 619176e maestro todavía, pero eso es exactamente lo que git reset --hard 619176e . Ha reiniciado su bifurcación (supongo que es el master bifurcación), pero la bifurcación remota a la que está presionando sigue apuntando al estado anterior (defectuoso), es decir, 7 commits adelante.

Como Dacotah ya sugirió, este es el caso de uso perfecto para una sucursal. Puede crear una nueva bifurcación a partir de la confirmación 619176e través de git checkout 619176e -b branchname . Luego puede introducir nuevos cambios, comprometerse y posiblemente impulsarlos.

Tan pronto como desee volver a integrar el trabajo en el master con los errores, tendrá que decidir qué partes del trabajo desea usar y cuáles no. También es posible que pueda corregir los errores en el master . Deberías confirmar esos cambios en el master y luego puedes fusionar las twigs o volver a establecer la base de tu nueva twig sobre el maestro.

En este caso, probablemente ramifique mi código una vez que regrese algunas confirmaciones. No estoy seguro de si esta es una buena práctica, pero es una solución potencial. El código para una twig es git checkout -b BranchName

Lo que voy a decirte es muy peligroso . Si utiliza:

 git push -F 

Eso debería forzar el empuje hacia el control remoto y eliminar las confirmaciones desde 619176e. Hay algunos problemas con esto. En primer lugar, si tiene otros usuarios, es posible que tengan las malas confirmaciones en su historial, y si presionan, esos compromisos incorrectos volverán a su repository. Segundo, si hay otras confirmaciones válidas en el control remoto, las perderá.

Sugiero revertir los commits malos uno por uno, y luego si quieres aplastarlos (usando una rebase interactiva) antes de empujar el repository limpio.

Mi sugerencia, dado que parece que ha pulsado varias confirmaciones para dominar después de 619176e y no desea que se eliminen, es hacer otra confirmación que revierte todos los cambios que ha realizado desde 619176e .

Primero cambie el estado de su directory de trabajo para que coincida con 619176e.

git checkout 619176e .

Esto no cambia la twig en la que se encuentra ni afecta las confirmaciones existentes. Simplemente modifica tus files para que estén EXACTAMENTE como estaban en 619176e.

Luego haz la nueva confirmación con git commit .

Otras opciones:

  • Hacer otra twig basada en 619176e. Esto funciona bien Sin embargo, será difícil integrar esa twig nuevamente en el maestro.

  • Haz 619176e maestro (es decir, git reset --hard 619176e ) y fuerza de empuje. Si ya compartió el maestro, esto puede provocar que los queueboradores se enojen contigo. Si aún no ha compartido el maestro, esta podría ser una buena opción y le daría un historial más limpio, pero si no desea perder sus siete compromisos, es mejor que guarde una reference a ellos primero.

Como se señala a menudo, generalmente no es una buena idea volver a escribir el historial de su twig principal (la principal exception es cuando aún no ha compartido el maestro con nadie). Si git reset --hard 619176e y agrega más commits, está reescribiendo el historial de su twig principal reemplazando los commits rotos con los nuevos. El restablecimiento completo está básicamente apuntando su twig principal a la confirmación especificada.