2012-06-27 31 views
38

He estado jugando con git (todavía muy novato) y quería saber la diferencia entre "reiniciar" y "rebase". ¿Es el uno más poderoso que el otro?¿Cuál es la diferencia entre "git reset" vs "git rebase"?

Digamos que quería eliminar los 3 commits en negrita del historial, ¿cuál será mejor usar, o debería etiquetarlo y luego eliminarlo con git tag -d <tagname>?

17a64df 2012-06-21 | Hola usa style.css (CABEZA, origen/estilo, maestro),
a6792e4 2012-06-21 | Hoja de estilo css añadida
801e13e 2012-06-21 | Se agregó README
5854339 2012-06-21 | Se agregó index.html
0b1dd4c 2012-06-21 | Se movió hello.html a lib
55649c3 2012-06-21 | Agregue un comentario de autor/correo electrónico
9b2f3ce 2012-06-21 | Agregó un comentario del autor
cdb39b0 2012-06-21 | Commit p etiquetas con el texto (v1.1)
b7b5fce 2012-06-21 | Esto revierte commit a6faf60631b5fbc6ee79b52a1bdac4c971b69ef8.
a6faf60 2012-06-21 | Revertir "Vaya, no queríamos que este compromiso"
a006669 2012-06-21 | Vaya, no queríamos esta confirmación
262d1f7 2012-06-21 | Se agregó el encabezado HTML (v1)
b1846e5 2012-06-21 | Se agregaron etiquetas de página HTML estándar (v1-beta)
bf1131e 2012-06-21 | Se agregó HI TAG
02b86d0 2012-06-21 | En primer lugar Commit

Respuesta

43

Son completamente diferentes. git-reset trabaja con referencias, en su directorio de trabajo y el índice, sin tocar ningún objeto de confirmación (u otros objetos). git-rebase, por otro lado, se usa para reescribir objetos de confirmación previamente creados.

Así que si quieres reescribir el historial, git-rebase es lo que quieres. Tenga en cuenta que debe nunca reescribir el historial que se envió y que estaba disponible para otra persona, ya que el reescritura reescribe los objetos haciéndolos incompatibles con los objetos antiguos, lo que resulta en un desastre para cualquier otra persona involucrada.

Una vez dicho esto, lo que quiere hacer es interactive rebasing. Invocarlo usando git rebase -i 262d1f7 y que debe recibir un aviso con este aspecto:

pick 262d1f7 Added HTML header (v1) 
pick a006669 Oops, we didn't want this commit 
pick a6faf60 Revert "Oops, we didn't want this commit" 
pick b7b5fce This reverts commit a6faf60631b5fbc6ee79b52a1bdac4c971b69ef8. 
pick cdb39b0 Commit p tags with text (v1.1) 
pick 9b2f3ce Added an author comment 
pick 55649c3 Add an author/email comment 
pick 0b1dd4c Moved hello.html to lib 
pick 5854339 Added index.html 
pick 801e13e Added README 
pick a6792e4 Added css stylesheet 
pick 17a64df Hello uses style.css (HEAD, origin/style, master), 

Allí, sólo tiene que borrar las líneas para las confirmaciones que desea eliminar, guardar y salir del editor y Git volverá a escribir su historia. De nuevo, no haga esto si ya ha enviado los cambios. En general, tener tales compromisos en la historia está perfectamente bien.

+0

Gracias por la respuesta y aclarando cuáles son las diferencias. – Q10

+0

está borrando las líneas de la rebase igual que cambiar la palabra "pick" por "s" para squash? – Ninjaxor

+4

@Ninjaxor No, borrar líneas eliminará completamente las confirmaciones y los cambios que introdujeron del historial. Es como si el compromiso nunca se hubiera realizado. Por ejemplo, si elimina una confirmación que agregó una línea, esa línea no aparecerá en ninguna confirmación posterior después de la rebase. Por otro lado, aplastar aún mantendrá los cambios introducidos en la confirmación mientras se deshace de ese compromiso separado. – poke

8

Aunque esto no compara las diferencias entre los dos, here's es un excelente artículo que explica el rebase que es fácil de entender.

+1

URL ahora es http://www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html – AnneTheAgile

+1

Ese artículo dice que el único beneficio es tener menos fusión commits, y los commit de fusión restantes son más significativos. Esto no parece valer la pena el riesgo. ¿Hay alguna otra ventaja? –

+0

Ese artículo fue muy útil. La mejor explicación que he visto en Internet hasta ahora. –

Cuestiones relacionadas