git: mejor forma de revertir git sin confirmación revertida adicional

Question

Tengo un compromiso en una rama remota + local y quiero descartar ese compromiso del historial y poner algunos de ellos en una rama propia.

Básicamente, en este momento tengo:

  D---E---F---G master 

Y quiero:

   E---G topic 
      /
      D master 

Eso debe ser a la vez en mi local y en el (sólo hay uno, llamado origen) repositorio remoto .

¿Cuál es la forma más limpia de obtener eso?

Además, también hay otras personas que han clonado ese repositorio y que han revisado la rama principal. Si hiciera un cambio de este tipo en el repositorio remoto, ¿funcionaría 'git pull' para que ellos también lleguen al mismo estado?

Answer 1

Si ha publicado, tiene razón en que no desea volver a escribir el historial de master. Lo que desea es publicar una confirmación de dominio que la devuelva al estado en que se encontraba al D, conservando su historial actual para que otros usuarios puedan fusionar o modificar su trabajo fácilmente.

Si está pensando en algún momento en el futuro para fusionar topic en master entonces lo que probablemente también quiere hacer es realizar una nueva base común entre master y topic, de modo que cuando usted posteriormente combinar topic, usted don' t pierde las confirmaciones que se revertieron en master. La forma más fácil de hacerlo es haciendo una confirmación 'rehacer' encima de la confirmación 'deshacer' que restablece master a su estado original y basando la nueva rama topic encima de eso.

# checkout master branch (currently at G) 
git checkout master 

# Reset the index to how we want master to look like 
git reset D 

# Move the branch pointer back to where it should be, leaving the index 
# looking like D 
git reset --soft HEAD@{1} 

# Make a commit (D') for the head of the master branch 
git commit -m "Temporarily revert E, F and G" 

# Create the new topic branch based on master. 
# We're going to make it on top of master and the 'undo' 
# commit to ensure that subsequent merges of master->topic 
# or topic->master don't merge in the undo. 
git checkout -b topic 

# Revert the undo commit, making a redo commit (G'). 
git revert HEAD 

Como una alternativa que podría haber hecho, comete E 'F' y G 'rehacer cada parte por separado, sino como E, F y G están ya en su historial publicada es probablemente más comprensible si sólo referencia a la' deshacer 'cometer y decir que ese compromiso se está deshaciendo. Esto es lo que hace git revert, de todos modos.

Esencialmente, lo que sabes es esto.

D -- E -- F -- G -- D'  <-- master 
        \ 
         \ 
         G' <-- topic 

Lo importante es que usted no ha reescrito la historia y el tema principal se basa en lo que se funde no querer aplicar cualquier 'deshacer' comete. Ahora puede presionar con seguridad master y topic en su repositorio remoto.

Answer 2

Puede reescribir su historial si lo desea, pero es una mala idea si alguien más tiene copias del historial. En este caso, probablemente usarías rebase interactivo: git rebase -i master topic. Esto le dará una lista de confirmaciones de maestro a tema, con consejos sobre cómo jugar con ellos. Solo necesitarás eliminar la línea que contiene la confirmación que deseas eliminar.

Dicho esto, debo recalcar que es irresponsable hacer esto si alguien más tiene este historial. Debería forzarlo a su repo central, y todos los demás tendrían que arreglar sus repositorios para que coincidan, puede ser relativamente simple o complejo dependiendo de las circunstancias.

Hay una buena sección llamada "recuperación de rebase aguas arriba" en el git-rebase man page discutiendo cómo tratar con esto, si realmente lo decide.

Editar:

Para la historia simple, un escenario común sería, después de forzar un empuje no fastforward al repositorio central (push -f), otros desarrolladores:

• volver a su viejo maestro: git branch -m master master_old
• obtener actualizaciones y volver a crear maestro de origen: git remote update origin; git branch master origin/master
• rebase todas las ramas puntuales hacia New principal: git rebase --onto master master_old topic

si tienen trabajo en su rama principal, que no es de origen, sin embargo, van a tener que conseguir más elegante, rebase este trabajo y todas las ramas puntuales sobre la nueva posición del maestro ... esto debe darle una idea de por qué es tan horrible reescribir la historia que otras personas tienen. Realmente, una vez que algo ha pasado al repositorio público, debe considerarlo como un historial grabado y no como un trabajo en progreso.

Answer 3

encuentro git stash es bastante útil

Sólo esconder a la basura y nunca mirar de nuevo.