Git: use revertir o pagar para deshacer los cambios realizados?

Question

Git es una herramienta fenomenal, pero todavía tengo que pensar acerca de la mejor manera de deshacer los cambios realizados. Aquí está la situación.

Estoy en una sucursal y he llevado varias confirmaciones a GitHub. Desde entonces se ha decidido que he ido demasiado lejos en el agujero del conejo, y tenemos que eliminar varias de las confirmaciones que hice, y comenzar de nuevo. Esencialmente, necesito revertir todos los commits empujados, de regreso a uno anterior. Estos son los dos comandos que yo creo son apropiados

git revert # - creates a new commit that "undoes" the changes of one specific commit 
git checkout 'commit SHA' # - sets the head to that specific commit, wherein I will re-push to the repo, undoing my changes... I think 

Por lo tanto, estoy en lo cierto? ¿Debo hacer un pago por git en el compromiso específico al que deseo regresar? ¿O hay algo en este complicado proceso que no estoy comprendiendo?

Gracias.

Answer 1

Trate git reset: http://git-scm.com/docs/git-reset

Answer 2

Como Horia señaló correctamente que necesitaremos git reset.

Git checkout significa que se cambia a otra sucursal o al usar check -b puede crear una nueva sucursal y cambiar a ella de inmediato.

Answer 3

Hay dos escenarios en función del estado de lo que empujó:

• Nadie ha utilizado la rama presionado para nada. En ese caso, puede usar git reset para forzar a la sucursal local a una confirmación específica, y luego puede git push la sucursal con un parámetro --force.

• Si, sin embargo, hay alguien que ha basado su trabajo en la rama que presionó accidentalmente, entonces no puede reiniciarlo, ya que entonces estará basando sus cambios en una rama en el limbo. Aquí es donde entra en juego el git revert. Grabará un parche inverso que efectivamente deshace los cambios anteriores. La ventaja aquí es que otros pueden basar su trabajo en la rama con facilidad.

La elección del método depende de cómo esté el repositorio y durante cuánto tiempo hayan estado allí los parches accidentales. Si hay pocos desarrolladores, la comunicación y un reset es probablemente la respuesta. Pero si la cosa ha vivido durante mucho tiempo, probablemente sea mejor revertir, a menos que quieras reescribir toda la historia.

Otra forma de verlo es esto: git revert es persistente mientras que git reset/git push --force es una reescritura destructiva del historial. Hay un tiempo apropiado para ambos.

Finalmente, cuando dejo de seguir a Alice por el agujero de Conejo e investigo lo que hay más allá, suelo hacerlo en ramas creadas localmente. Entonces, si me gustan los cambios, generalmente los fusiono en una rama de prueba y los dejo revolver un poco en la rama de prueba, antes de fusionarlos al master. De esta manera evitarás el problema la mayor parte del tiempo. En resumen, a menudo tengo 20-30 sucursales locales, una para cada función en la que estoy trabajando. Tienden a probarse individualmente primero. Ocasionalmente, creo una nueva rama test y fusiono todo en esa rama y realizo todas las pruebas juntas. Para rastrear conflictos entre sucursales, uso git rerere. La ventaja es que puedo decidir cuándo una característica es lo suficientemente estable como para empujar a otros.