Reescribiendo la historia de Git con confianza: una guía

Como desarrollador, trabajas con Git todo el tiempo. ¿Alguna vez llegaste a un punto en el que dijiste: "Uh-oh, qué acabo de hacer?" Esta publicación le dará las herramientas para reescribir la historia con confianza. Notas antes de comenzar También di una charla en vivo cubriendo el contenido de esta publicación. Si prefiere un video (o desea verlo junto con la lectura), puede encontrarlo . aquí ¡Estoy trabajando en un libro sobre Git! ¿Está interesado en leer las versiones iniciales y proporcionar comentarios? Envíame un correo electrónico: gitting.things@gmail.com Registro de cambios en Git Antes de comprender cómo cosas en Git, primero debe comprender cómo los cambios en Git. Si ya conoce todos los términos, no dude en omitir esta parte. deshacer registramos Es muy útil pensar en Git como un sistema para registrar instantáneas de un sistema de archivos en el tiempo. Considerando un repositorio Git, tiene tres “estados” o “árboles”: Por lo general, cuando trabajamos en nuestro código fuente, lo hacemos desde un . Un (o ) es cualquier directorio en nuestro sistema de archivos que tiene un asociado. directorio de trabajo directorio de trabajo (ectrory) árbol de trabajo repositorio Contiene las carpetas y archivos de nuestro proyecto y también un directorio llamado . Describí el contenido de la carpeta con más detalle en . .git .git una publicación anterior Después de realizar algunos cambios, es posible que desee registrarlos en su . Un (en resumen: ) es una colección de , cada una de las cuales es un archivo de cómo se veía el del proyecto en una fecha pasada, ya sea en su máquina o en la de otra persona. repositorio repositorio repo confirmaciones árbol de trabajo Un también incluye otras cosas además de nuestros archivos de código, como , ramas, etc. repositorio HEAD En el medio, tenemos el o ; estos dos términos son intercambiables. Cuando una rama, Git completa el con todo el contenido del archivo que se desprotegió por última vez en nuestro y cómo se veía cuando se desprotegió originalmente. índice área de ensayo checkout índice directorio de trabajo Cuando usamos , el se crea basado en el estado del . git commit commit índice Entonces, el o el es su campo de juego para la próxima confirmación. Puede trabajar y hacer lo que quiera con el , agregarle archivos, eliminar cosas de él y luego, solo cuando esté listo, continuar y comprometerse con el repositorio. índice, área de preparación, índice Es hora de ponerse manos a la obra 🙌🏻 Use para inicializar un nuevo repositorio. Escriba algo de texto en un archivo llamado : git init 1.txt De los tres estados de árbol descritos anteriormente, ¿dónde está ahora? 1.txt En el árbol de trabajo, ya que aún no se ha introducido en el índice. Para , para agregarlo al índice, use . organizarlo git add 1.txt Ahora, podemos usar para confirmar nuestros cambios en el repositorio. git commit Ha creado un nuevo objeto de confirmación, que incluye un puntero a un árbol que describe todo el árbol de trabajo. En este caso, será solo dentro de la carpeta raíz. Además de un puntero al árbol, el objeto de confirmación incluye metadatos, como marcas de tiempo e información del autor. 1.txt Para obtener más información sobre los objetos en Git (como confirmaciones y árboles), . echa un vistazo a mi publicación anterior (Sí, "echa un vistazo", juego de palabras 😇) Git también nos dice el valor SHA-1 de este objeto de confirmación. En mi caso, fue (que son solo los primeros 7 caracteres del valor SHA-1, para ahorrar espacio). c49f4ba Si ejecuta este comando en su máquina, obtendrá un valor SHA-1 diferente, ya que es un autor diferente; Además, crearía la confirmación en una marca de tiempo diferente. Cuando inicializamos el repositorio, Git crea una nueva rama (llamada por defecto). Y . Entonces, de manera predeterminada, solo tiene la rama . ¿Qué pasa si tienes varias sucursales? ¿Cómo sabe Git qué rama es la rama activa? main una rama en Git es solo una referencia con nombre a una confirmación main Git tiene otro puntero llamado , que apunta (generalmente) a una rama, que luego apunta a una confirmación. Por cierto, Incluye el nombre de la sucursal con algunos prefijos. HEAD bajo el capó, HEAD es solo un archivo. ¡Es hora de introducir más cambios en el repositorio! Ahora, quiero crear otro. Entonces, creemos un nuevo archivo y agréguelo al índice, como antes: Ahora es el momento de usar . Es importante destacar hace cosas: git commit git commit dos Primero, crea un objeto de confirmación, por lo que hay un objeto dentro de la base de datos interna de objetos de Git con un valor SHA-1 correspondiente. Este nuevo objeto de confirmación también apunta a la confirmación principal. Esa es la confirmación a la que apuntaba cuando escribiste el comando . HEAD git commit En segundo lugar, mueve el puntero de la rama activa; en nuestro caso, eso sería , para apuntar al objeto de confirmación recién creado. git commit main Deshacer los cambios Para reescribir el historial, comencemos por deshacer el proceso de introducir una confirmación. Para eso, conoceremos el comando , una herramienta súper poderosa. git reset git reset --soft Entonces, el último paso que hiciste antes fue , lo que en realidad significa dos cosas: Git creó un objeto de confirmación y movió , la rama activa. Para deshacer este paso, usa el comando . git commit main git reset --soft HEAD~1 La sintaxis se refiere al primer padre de . Si tuviera más de una confirmación en el gráfico de confirmación, diga "Commit 3" apuntando a "Commit 2", que, a su vez, apunta a "Commit 1". HEAD~1 HEAD Y digamos que estaba apuntando a "Commit 3". Podría usar para referirse a "Commit 2", y se referiría a "Commit 1". HEAD HEAD~1 HEAD~2 Entonces, volvamos al comando: git reset --soft HEAD~1 Este comando le pide a Git que cambie lo que apunta . (Nota: en los diagramas a continuación, uso para "lo que sea que esté señalando"). En nuestro ejemplo, apunta a . Entonces Git solo cambiará el puntero de para que apunte a . Es decir, apuntará a "Commit 1". HEAD *HEAD HEAD HEAD main main HEAD~1 main Sin embargo, este comando afectó el estado del índice o el árbol de trabajo. Entonces, si usa verá que está preparado, al igual que antes de ejecutar . no git status 2.txt git commit ¿Qué pasa con Comenzará desde , irá a y luego a "Commit 1". Tenga en cuenta que esto significa que "Commit 2" ya no es accesible desde nuestro historial. git log? HEAD main ¿Significa eso que se elimina el objeto de confirmación de "Commit 2"? 🤔 No, no se elimina. Todavía reside dentro de la base de datos interna de objetos de Git. Si envía el historial actual ahora, usando , Git no enviará "Commit 2" al servidor remoto, pero el objeto de confirmación todavía existe en su copia local del repositorio. git push Ahora, confirme nuevamente y use el mensaje de confirmación de "Commit 2.1" para diferenciar este nuevo objeto del "Commit 2" original: ¿Por qué son diferentes "Commit 2" y "Commit 2.1"? Incluso si usamos el mismo mensaje de confirmación, y aunque apunten a (de la carpeta raíz que consta de y ), todavía tienen marcas de tiempo diferentes, ya que se crearon en momentos diferentes. el mismo objeto de árbol 1.txt 2.txt En el dibujo de arriba, mantuve "Commit 2" para recordarte que todavía existe en la base de datos interna de objetos de Git. Tanto "Commit 2" como "Commit 2.1" ahora apuntan a "Commit 1", pero solo se puede acceder a "Commit 2.1" desde . HEAD Restablecimiento de Git - Mixto Es hora de ir incluso hacia atrás y deshacer más. Esta vez, use (nota: es el interruptor predeterminado para ). git reset --mixed HEAD~1 --mixed git reset Este comando comienza igual que . Lo que significa que toma el puntero de lo que esté apuntando ahora, que es la rama , y lo establece en , en nuestro ejemplo, "Commit 1". git reset --soft HEAD~1 HEAD main HEAD~1 Luego, Git va más allá y deshace efectivamente los cambios que hicimos en el índice. Es decir, cambiando el índice para que coincida con el actual, el nuevo después de configurarlo en el primer paso. HEAD HEAD Si ejecutamos , significa que se establecería en ("Commit 1"), y luego Git haría coincidir el índice con el estado de "Commit 1"; en este caso, significa que ya no formará parte del índice. git reset --mixed HEAD~1 HEAD HEAD~1 2.txt Es hora de crear un nuevo compromiso con el estado del "Commit 2" original. Esta vez necesitamos volver a preparar antes de crearlo: 2.txt Restablecimiento de Git - Difícil ¡Adelante, deshazte aún más! Continúe y ejecute git reset --hard HEAD~1 Nuevamente, Git comienza con la etapa , configurando cualquier al que apunte ( ), a ("Commit 1"). --soft HEAD main HEAD~1 Hasta ahora, todo bien. A continuación, pasar a la etapa , haciendo coincidir el índice con . Es decir, Git deshace la preparación de . --mixed HEAD 2.txt Es hora del paso donde Git va más allá y hace coincidir el directorio de trabajo con la etapa del índice. En este caso, significa eliminar también del directorio de trabajo. --hard 2.txt (**Nota: en este caso específico, el archivo no se por lo que no se eliminará del sistema de archivos; sin embargo, no es realmente importante para comprender ). rastrea, git reset Entonces, para introducir un cambio en Git, tienes tres pasos. Cambia el directorio de trabajo, el índice o el área de preparación y luego confirma una nueva instantánea con esos cambios. Para estos cambios: deshacer Si usamos , deshacemos el paso de confirmación. git reset --soft Si usamos , también deshacemos el paso de preparación. git reset --mixed Si usamos , deshacemos los cambios en el directorio de trabajo. git reset --hard ¡Escenarios de la vida real! Escenario 1 Entonces, en un escenario de la vida real, escriba "Me encanta Git" en un archivo ( ), ya que todos amamos a Git 😍. Adelante, prepara y comete esto también: love.txt ¡Uy! En realidad, no quería que lo cometiera. Lo que realmente quería que hicieras es escribir algunas palabras de amor más en este archivo antes de enviarlo. ¿Qué puedes hacer? Bueno, una forma de superar esto sería usar , deshaciendo efectivamente las acciones de confirmación y puesta en escena que tomó: git reset --mixed HEAD~1 Entonces, los puntos para "Commit 1" nuevamente, y ya no es parte del índice. Sin embargo, el archivo permanece en el directorio de trabajo. Ahora puede continuar y agregarle más contenido: main love.txt Continúe, organice y confirme su archivo: Bien hecho 👏🏻 Obtuviste esta historia clara y agradable de "Commit 2.4" apuntando a "Commit 1". Ahora tenemos una nueva herramienta en nuestra caja de herramientas, 💪🏻 git reset Esta herramienta es súper, súper útil y puedes lograr casi cualquier cosa con ella. No siempre es la herramienta más conveniente para usar, pero es capaz de resolver casi cualquier escenario de reescritura de la historia si la usa con cuidado. Para los principiantes, recomiendo usar solo durante casi cualquier momento que desee deshacer en Git. Una vez que se sienta cómodo con él, es hora de pasar a otras herramientas. git reset Escenario #2 Consideremos otro caso. Cree un nuevo archivo llamado ; etapa y cometer: new.txt Ups. En realidad, eso es un error. Estabas en y quería que crearas esta confirmación en una rama de características. Mi mal 😇 main Hay dos herramientas más importantes que quiero que tome de esta publicación. El es . El primero y mucho más importante es el estado actual con el estado en el que desea estar. segundo git reset comparar Para este escenario, el estado actual y el estado deseado se ven así: Notarás tres cambios: puntos a "Commit 3" (el azul) en el estado actual, pero a "Commit 2.4" en el estado deseado. main La rama no existe en el estado actual, pero existe y apunta a "Commit 3" en el estado deseado. feature apunta a en el estado actual y a en el estado deseado. HEAD main feature Si puede dibujar esto y sabe cómo usar , definitivamente puede salir de esta situación. git reset De nuevo, es respirar y sacar esto. lo más importante Observando el dibujo de arriba, ¿cómo pasamos del estado actual al deseado? Por supuesto, hay algunas formas diferentes, pero presentaré una opción solo para cada escenario. Siéntase libre de jugar con otras opciones también. Puede comenzar usando . Esto establecería para apuntar a la confirmación anterior, "Commit 2.4": git reset --soft HEAD~1 main Mirando de nuevo el diagrama actual-vs-deseado, puede ver que necesita una nueva rama, ¿verdad? Puede usar para ello o (que hace lo mismo): git switch -c feature git checkout -b feature Este comando también actualiza para apuntar a la nueva rama. HEAD Dado que usó , no cambió el índice, por lo que actualmente tiene exactamente el estado que desea confirmar, ¡qué conveniente! Simplemente puede comprometerse con la rama : git reset --soft feature Y llegaste al estado deseado 🎉 Escenario #3 ¿Listo para aplicar su conocimiento a casos adicionales? Agregue algunos cambios a y también cree un nuevo archivo llamado . Ponlos en escena y comprométete: love.txt cool.txt Vaya, en realidad quería que crearas dos confirmaciones separadas, una con cada cambio 🤦🏻 ¿Quieres probar este tú mismo? Puede deshacer los pasos de compromiso y preparación: Siguiendo este comando, el índice ya no incluye esos dos cambios, pero ambos todavía están en su sistema de archivos. Así que ahora, si solo preparas , puedes enviarlo por separado y luego hacer lo mismo con : love.txt cool.txt Bonito 😎 Escenario #4 Cree un nuevo archivo ( ) con algo de texto y agregue algo de texto a . Preparar ambos cambios y confirmarlos: new_file.txt love.txt Uy 🙈🙈 Entonces, esta vez, quería que fuera en otra rama, pero no en una rama , sino en una rama ya existente. nueva ¿Entonces que puedes hacer? Te daré una pista. La respuesta es muy corta y muy fácil. ¿Qué hacemos primero? No, no . Dibujamos. Eso es lo primero que debe hacer, ya que haría que todo lo demás fuera mucho más fácil. Así que este es el estado actual: reset ¿Y el estado deseado? ¿Cómo se pasa del estado actual al estado deseado, qué sería más fácil? Entonces, una forma sería usar como lo hizo antes, pero hay otra forma que me gustaría que probara. git reset Primero, mueva para señalar la rama : HEAD existing Intuitivamente, lo que desea hacer es tomar los cambios introducidos en la confirmación azul y aplicar estos cambios ("copiar y pegar") en la parte superior de la rama . Y Git tiene una herramienta solo para eso. existing Para pedirle a Git que tome los cambios introducidos entre esta confirmación y su confirmación principal y simplemente aplique estos cambios en la rama activa, puede usar . Este comando toma los cambios introducidos en la revisión especificada y los aplica a la confirmación activa. git cherry-pick También crea un nuevo objeto de confirmación y actualiza la rama activa para apuntar a este nuevo objeto. En el ejemplo anterior, especifiqué el identificador SHA-1 de la confirmación creada, pero también podría usar , ya que la confirmación cuyos cambios estamos aplicando es la a la que apunta. git cherry-pick main main Pero no queremos que estos cambios existan en la rama . solo aplicó los cambios a la rama . ¿Cómo puedes eliminarlos de ? main git cherry-pick existing main Una forma sería a y luego usar : switch main git reset --hard HEAD~1 ¡Lo hiciste! 💪🏻 Tenga en cuenta que en realidad calcula la diferencia entre la confirmación especificada y su padre, y luego los aplica a la confirmación activa. Esto significa que, a veces, Git no podrá aplicar esos cambios, ya que puede generar un conflicto, pero ese es un tema para otra publicación. git cherry-pick Además, tenga en cuenta que puede pedirle a Git que los cambios introducidos en cualquier confirmación, no solo las confirmaciones a las que hace referencia una rama. cherry-pick Hemos adquirido una nueva herramienta, por lo que tenemos y en nuestro haber. git reset git cherry-pick Escenario #5 Bien, otro día, otro repositorio, otro problema. Crear un compromiso: Y al servidor remoto: push Um, ups 😓... Acabo de notar algo. Hay un error tipográfico allí. Escribí en lugar de . ¡Vaya! Entonces, ¿cuál es el gran problema ahora? ed, lo que significa que alguien más podría haber esos cambios. This is more tezt This is more text push pull Si anulo esos cambios usando , como lo hemos hecho hasta ahora, tendremos diferentes historias y todo podría desatarse. Puede reescribir su propia copia del repositorio tanto como desee hasta que lo . git reset push Una vez que el cambio, debe estar seguro de que nadie más haya obtenido esos cambios si va a reescribir el historial. push muy Alternativamente, puede usar otra herramienta llamada . Este comando toma la confirmación que le proporcionas y calcula la diferencia a partir de su confirmación principal, al igual que , pero esta vez calcula los cambios inversos. git revert git cherry-pick Entonces, si en la confirmación especificada agregaste una línea, lo contrario eliminaría la línea y viceversa. creó un nuevo objeto de confirmación, lo que significa que es una adición al historial. Al usar , no reescribió el historial. Admitiste tu error pasado, y este compromiso es un reconocimiento de que cometiste un error y ahora lo arreglaste. git revert git revert Algunos dirían que es la forma más madura. Algunos dirían que no es un historial tan limpio como el que obtendrías si usaras para reescribir la confirmación anterior. Pero esta es una forma de evitar reescribir la historia. git reset Ahora puede corregir el error tipográfico y confirmar de nuevo: Su caja de herramientas ahora está cargada con una nueva herramienta brillante, : revert Escenario #6 Trabaja un poco, escribe un código y agrégalo a . Realice este cambio y confírmelo: love.txt Hice lo mismo en mi máquina, y usé la tecla de flecha en mi teclado para desplazarme hacia atrás a los comandos anteriores, y luego presioné y... Wow. Up Enter ¡Vaya! ¿Acabo de usar ? 😨 git reset --hard ¿Qué sucedió ? Git movió el puntero a , por lo que no se puede acceder a la última confirmación, con todo mi trabajo, desde el historial actual. Git también eliminó todos los cambios del área de preparación y luego hizo coincidir el directorio de trabajo con el estado del área de preparación. realmente HEAD~1 precioso Es decir, todo coincide con este estado en el que mi trabajo se ha... ido. Tiempo de enloquecer. enloqueciendo Pero, realmente, ¿hay alguna razón para enloquecer? No realmente… Somos gente relajada. qué hacemos? Bueno, intuitivamente, ¿se ha ido el compromiso? ¿No por qué no? Todavía existe dentro de la base de datos interna de Git. realmente Si supiera dónde está, sabría el valor SHA-1 que identifica este compromiso, podríamos restaurarlo. Incluso podría deshacer la deshacer y de nuevo a este compromiso. reset Entonces, lo único que realmente necesito aquí es el SHA-1 del compromiso "eliminado". Entonces la pregunta es, ¿cómo lo encuentro? ¿Sería útil ? git log Bueno en realidad no. iría a , que apunta a , que apunta a la confirmación principal de la confirmación que estamos buscando. Luego, rastrearía a través de la cadena principal, que no incluye la confirmación con mi valioso trabajo. git log HEAD main git log Afortunadamente, las personas muy inteligentes que crearon Git también crearon un plan de respaldo para nosotros, y se llama . reflog Mientras trabaja con Git, cada vez que cambia , lo que puede hacer usando , pero también otros comandos como o , Git agrega una entrada al . HEAD git reset git switch git checkout reflog ¡Encontramos nuestro compromiso! Es el que comienza con . 0fb929e También podemos relacionarnos con él por su "apodo": . Por ejemplo, Git usa para llegar al primer padre de , y para referirse al segundo padre de y así sucesivamente, Git usa para referirse al primer padre reflog de , donde señaló en el paso anterior. HEAD@{1} HEAD~1 HEAD HEAD~2 HEAD HEAD@{1} HEAD HEAD También podemos pedirle que nos muestre su valor: git rev-parse Otra forma de ver el es usar , que le pide a que realmente considere el : reflog git log -g git log reflog Vemos arriba que , al igual que , apunta a , que apunta a "Commit 2". Pero el padre de esa entrada en el apunta a "Commit 3". reflog HEAD main reflog Entonces, para volver a "Commit 3", solo puede usar (o el valor SHA-1 de "Commit 3"): git reset --hard HEAD@{1} Y ahora, si : git log ¡Salvamos el día! 🎉👏🏻 ¿Qué pasaría si volviera a usar este comando? ¿Y ejecutó ? Git configuraría a donde apuntaba antes del último , es decir, "Commit 2". Podemos seguir todo el día: git commit --reset HEAD@{1} HEAD HEAD reset Mirando nuestra caja de herramientas ahora, está cargada de herramientas que pueden ayudarlo a resolver muchos casos en los que las cosas salen mal en Git: Con estas herramientas, ahora comprenderá mejor cómo funciona Git. Hay más herramientas que te permitirían reescribir el historial específicamente, ), pero ya aprendiste mucho en esta publicación. En publicaciones futuras, también me sumergiré en . git rebase git rebase La herramienta más importante, incluso más importante que las cinco herramientas enumeradas en esta caja de herramientas, es comparar la situación actual con la deseada. Confía en mí, hará que cada situación parezca menos desalentadora y la solución más clara. Más información sobre Git También di una charla en vivo cubriendo el contenido de esta publicación. Si prefiere un video (o desea verlo junto con la lectura), puede encontrarlo . aquí En general, cubre muchos aspectos de Git y sus componentes internos; eres bienvenido a (juego de palabras intencionado 😇) mi canal de youtube Échale un vistazo Sobre el Autor es el CTO y cofundador de , una herramienta de desarrollo que ayuda a los desarrolladores y sus equipos a administrar el conocimiento sobre su base de código con documentación interna actualizada. Omer es el fundador de Check Point Security Academy y fue líder de seguridad cibernética en ITC, una organización educativa que capacita a profesionales talentosos para desarrollar carreras en tecnología. Omer Rosenbaum Nadar Omer tiene una Maestría en Lingüística de la Universidad de Tel Aviv y es el creador de la . Breve canal de YouTube Publicado por primera vez aquí