A principios de este año hice una reorganización interactiva por primera vez y me impresionó lo que se puede hacer con ella. También me pareció un poco complejo al principio. Con suerte, esta guía ayudará a eliminar cierta incertidumbre al respecto. Además, debido a que es tan poderoso y esencialmente puede reescribir la historia, una pequeña advertencia antes de comenzar: hay muchas escuelas de pensamiento sobre Git y si reorganizar es una buena idea o no. Esta publicación se sumergirá en esas discusiones y tiene la intención pura de explicar los conceptos básicos del uso de rebase interactivo. no TL;RD El reajuste interactivo se puede usar para cambiar confirmaciones de muchas maneras, como editar, eliminar y aplastar. Para decirle a Git dónde comenzar la reorganización interactiva, use el SHA-1 o el índice de la confirmación que precede inmediatamente a la confirmación que desea modificar. Durante una reorganización interactiva, cuando Git se detiene en una confirmación que etiquetó para editar, el flujo de trabajo no es diferente a un proceso de confirmación normal: prepara los archivos y luego los confirma. La única diferencia es que usas el comando en lugar de . git commit --amend git commit El cambio de base interactivo creará nuevos SHA-1, por lo que es mejor usar el cambio de base interactivo en confirmaciones que no haya enviado a una rama remota. El problema En este ejemplo, trabajaremos en una situación en la que hemos estado trabajando en una rama de función y tenemos un par de compromisos que nos gustaría cambiar o eliminar. Así es como se ve nuestro registro de git: Desde el registro de git anterior, aquí están las dos confirmaciones que queremos cambiar: - En esta confirmación cometimos accidentalmente un conflicto de combinación - En esta confirmación eliminamos el conflicto de combinación 4a4d705 6c01350 Lo que nos gustaría hacer es retroceder en el tiempo hasta , eliminar el conflicto de combinación en la confirmación y luego eliminar , ya que el conflicto de combinación está resuelto y ya no necesitamos esta confirmación. Esta será una mejora en nuestro historial de confirmaciones por dos razones: 4a4d705 6c01350 No tendremos confirmaciones rotas (conflictos de fusión) Solo tendremos compromisos significativos, no compromisos relacionados únicamente con la reparación de un conflicto de fusión perdido La solución Esta situación es una buena candidata para el cambio de base interactivo. Scott Chacon, en su libro , describe el cambio de base interactivo de la siguiente manera: “A veces, lo que se solucionó... no se puede modificar a la confirmación no del todo perfecta que corrige, porque esa confirmación está profundamente enterrada en una serie de parches. Eso es exactamente para lo que sirve el rebase interactivo: utilícelo después de mucho [trabajo comprometido], reorganizando y editando confirmaciones, y agrupando múltiples confirmaciones en una sola”. Pro Git ¿Qué compromisos queremos modificar? Para iniciar una reorganización interactiva, debemos decirle a Git qué confirmaciones queremos modificar. Hacemos esto haciendo referencia a la confirmación inmediatamente anterior a la primera confirmación que queremos modificar. O, en pocas palabras, hacemos referencia a "la última confirmación [que] queremos conservar tal como está", según Scott Chacon. Veamos nuestro ejemplo para tener una mejor comprensión. Hay dos formas de hacer referencia a esta confirmación: : la última confirmación que queremos conservar tal cual tiene un SHA-1 de para que podamos pasar esto a nuestro comando de rebase interactivo. : la última confirmación que queremos conservar tal como está tiene una posición de índice de 3 (Git usa indexación basada en cero) para que podamos pasar a nuestro comando de rebase interactivo. Por SHA-1 528f82e Por índice HEAD~3 Nota: si solo tiene algunas confirmaciones en las que realizar una reorganización interactiva, usar el índice probablemente sea más fácil para la mayoría de las personas. Sin embargo, si tiene muchas confirmaciones, usar SHA-1 probablemente sea más fácil para que no tenga que contar todo el registro de git. Iniciar rebase interactivo Basándonos en nuestro ejemplo, ejecutaremos: $ git rebase -i 528f82e O $ git rebase -i HEAD~3 Lo que abre esta ventana en Vim: Observe que las confirmaciones están en el orden opuesto al registro de git. En el registro de git, la confirmación más reciente está en la parte superior. En esta vista, la confirmación más reciente está en la parte inferior. También observe que los comentarios a continuación brindan una lista útil de los comandos válidos que podemos usar en cada confirmación. Si no conoce Vim, simplemente haga clic en cada de palabra que desee editar y luego presione la tecla (para el modo de inserción). Una vez que haya terminado de escribir, presione la tecla para salir del modo de inserción. pick <i> <esc> En nuestro ejemplo, hemos cambiado el comando para para la confirmación que queremos modificar y hemos cambiado el comando para para la confirmación que queremos eliminar. Luego ejecutamos para guardar y salimos de la ventana de Vim. edit drop :wq Modificar el compromiso De vuelta en la terminal vemos este mensaje: Esto tiene sentido que nos detengamos en . Esta es la confirmación más antigua de la serie de confirmaciones que queremos modificar. Comenzaremos con este compromiso y avanzaremos a través de cada compromiso hasta el más reciente. 4a4d705 Como recordatorio, fue la confirmación con el conflicto de combinación que cometimos accidentalmente. Cuando abrimos nuestro editor, vemos el conflicto de fusión allí: 4a4d705 Así que solucionamos el conflicto de combinación en el archivo, pero ¿qué hacemos ahora? En caso de duda, : git status ¡Enfriar! Esto es realmente útil. Vemos que actualmente estamos editando , y vemos que se actuará sobre los siguientes dos compromisos después de este. 4a4d705 El resto del mensaje nos explica un flujo de trabajo familiar. Git nos dice si queremos modificar la confirmación, ejecutamos . Básicamente, esto actuará como nuestro típico que usamos en un flujo de trabajo normal. En la parte inferior de este mensaje, vemos que nuestro archivo se modificó reflejando los cambios que acabamos de hacer para eliminar el conflicto de combinación. Necesitamos organizar el archivo antes de comprometernos. Esto no es diferente de un flujo de trabajo normal. git commit --amend git commit Todo lo que hacemos es para preparar el archivo editado y luego para confirmar el archivo preparado. Esto ahora abrirá una ventana de Vim nuevamente con el mensaje de confirmación: git add tempChanger.js git commit --amend Podemos editar el mensaje de confirmación o dejarlo como está. Elijamos mantener el mismo mensaje de confirmación y escribiremos para guardar y salir de la ventana. :wq Ahora hemos editado nuestro antiguo compromiso. ¿Y ahora que? Ejecute el : git status Continuar rebase interactivo No tenemos nada más que cambiar en el compromiso, así que ¡continuemos! y vemos el siguiente mensaje: git rebase --continue Vaya, ¿hemos terminado? Pero, ¿qué pasa con esos otros dos compromisos? Bueno, el siguiente compromiso en el que se actuó fue . Esta confirmación la marcamos para eliminar ( ) cuando comenzamos la reorganización interactiva. Git lo eliminó automáticamente y pasó a la siguiente confirmación, . Este nunca fue modificado en el rebase interactivo inicial. Su comando predeterminado era lo que significa que se usará la confirmación. Git aplicó ese compromiso y, dado que ese fue el último compromiso, se completó la reorganización interactiva. 6c01350 drop 41aa9d2 pick Tenga en cuenta que, si tuviéramos más confirmaciones para editar, simplemente pasaríamos a la siguiente confirmación y comenzaríamos el proceso de modificación tal como lo hicimos anteriormente. El ciclo continúa hasta que no quedan confirmaciones. El botón de expulsión Vale la pena señalar que si en algún momento de nuestro rebase interactivo arruinamos las cosas y no sabemos cómo solucionarlas, siempre podemos abortar. En cualquier momento, podemos ejecutar en la terminal y el rebase interactivo se cancelará sin guardar los cambios. Entonces tendríamos que volver a iniciar la reorganización interactiva. git rebase --abort Después del rebase interactivo Nuestro registro de git ahora se ve así: Notará que algunas cosas han cambiado desde antes de que comenzáramos la reorganización interactiva: Ya no tenemos la confirmación con el mensaje de confirmación "Eliminar conflicto de combinación". Esta es la confirmación que eliminamos en nuestra reorganización interactiva. 6c01350 Nuestro compromiso que editamos, , tiene un SHA-1 diferente, . 4a4d705 2b7443d Nuestro compromiso más reciente de nuestro registro de git original, , también tiene un nuevo SHA-1, . Esta confirmación no se modificó sino que simplemente se aplicó a la confirmación anterior . 41aa9d2 2b95e92 2b7443d Efectos secundarios del rebase interactivo Para las dos confirmaciones más recientes en nuestro registro de git, debido a que tienen nuevos SHA-1, Git las ve como confirmaciones completamente nuevas. Esto es cierto incluso para nuestra última confirmación, , donde ni el mensaje de confirmación ni los archivos cambiaron en absoluto. Esto trae a colación un punto importante con el cambio de base interactivo: 2b95e92 si modifica una confirmación, esa confirmación y todas las confirmaciones sucesivas tendrán nuevos SHA-1. Esto no afectará nada si las confirmaciones que ha modificado no se han enviado a una rama remota. Sin embargo, si de hecho completó una reorganización interactiva en las confirmaciones que ya se enviaron a una rama remota y luego volvió a enviar su rama, vería: Técnicamente, podría solucionar esto usando , pero eso es muy peligroso. Si la sucursal remota tiene confirmaciones de otras personas pero su sucursal local aún no tiene esas confirmaciones, eliminará efectivamente sus confirmaciones. git push --force Otra solución es usar que solo modificará tus confirmaciones pero no las confirmaciones que pertenezcan a otros, aunque esto también puede ser problemático. Por ejemplo, si otro desarrollador ya tiene esas confirmaciones a las que se les dieron nuevos SHA-1 en su sucursal local, cuando extraen la sucursal remota, tendrán conflictos de combinación con cada una de estas confirmaciones. git push --force-with-lease Cuándo usar está más allá del alcance de esta publicación de blog, pero sería mejor consultar a otros miembros de su equipo antes de hacerlo. Puedes leer más sobre . --force-with-lease git push --force-with-lease aquí La conclusión clave de esta sección es que es mucho más fácil y seguro usar el cambio de base interactivo en confirmaciones que aún no se han enviado a una rama remota. Escrito por Blake DeBoer. Publicado originalmente en Dev.to ¡ ¿Desarrollador senior, líder o principal en la ciudad de Nueva York? Stride está contratando ! ¿Quieres subir de nivel a tu equipo técnico? ¡Mira cómo lo hacemos ! www.stridenyc.com
