2008-10-20 14 views
25

he cometido, y empujó, varios parches: A1 -> A2 -> A3 -> A4 (HEAD)van hacia atrás en Git

Todo el mundo ha arrancado estos conjuntos de cambios en su copia local.

Ahora queremos "hacer retroceder" a A2, y continuar desarrollando desde allí - esencialmente tirar A3 y A4. ¿Cuál es la mejor manera de hacer esto?

Respuesta

5

Quiere git-revert y git-reset dependiendo de cómo quiera tratar A3 y A4. Para eliminar todo rastro de A3 y A4, use git-reset --hard. Para conservar A3 y A4 y registrar el hecho de que está retrocediendo, use git-revert.

edición: solución de Aristóteles Pagaltzis git-checkout es superior, aunque para pequeñas revierte No veo un problema con git-revert. No obstante, pido votaciones en el futuro se den a Aristotle Pagaltzis's answer

Encontré git magic para ser un buen recurso para git.

+0

El póster original casi seguro quiere revertir el restablecimiento. Como todos han sacado A3 y A4 de sus repositorios locales, creo que reiniciarlo podría estropear las cosas. –

+0

git-revert solo revertirá una confirmación a la vez y git-reset es una acción incorrecta para los cambios publicados. La respuesta correcta es git-checkout. –

+0

Aristóteles Pagaltzis: tienes razón, lo he eliminado de mi respuesta. – freespace

7

Tirar esas confirmaciones probable que tenga algunos efectos negativos sobre cualquier persona que está tirando de su repositorio. Como otra opción, es posible que desee considerar la creación de una rama de desarrollo alternativo a partir de A2:

 
A1-->A2-->A3-->A4 (master/HEAD) 
     \ 
     -->B1-->B2 (new-master/HEAD) 

Hacer esto es tan simple como

 
git branch new-master master~2 
45

Desde el directorio raíz de su copia de trabajo acaba de hacer

git checkout A2 -- . 
git commit -m 'going back to A2' 

Usando git revert para este propósito sería engorroso, ya que se desea deshacerse de toda una serie de commits y revert los deshace de a uno por vez.

Usted no quiere git reset tampoco. Eso simplemente cambiará su puntero de rama master: no queda ningún registro de la dirección equivocada. También resulta complicado coordinar: dado que la confirmación que modificó master no es un elemento secundario del puntero de rama del repositorio remoto master, la inserción fallará, a menos que agregue -f (forzar) o elimine primero la rama master y vuelva a crear presionando. Pero luego, todos los que intenten extraer tendrán el historial anterior en su rama local master, por lo que una vez que origin/master diverge, git pull intentará realizar una combinación. Este no es el fin del mundo: pueden salir de esta situación haciendo git rebase --onto origin/master $old_origin_master_commit master (es decir, rebase sus confirmaciones locales realizadas sobre el antiguo origin/master en la parte superior del nuevo origin/master). Pero Git no sabrá hacer esto automáticamente, así que debes coordinar con cada colaborador. En resumen, no hagas eso.