Git: aplasta varios compromisos en un solo compromiso

Una de las cosas buenas de Git es su flexibilidad, que le permite realizar casi cualquier tarea en un árbol de código fuente que necesite. En este caso, me refiero a limpiar el historial de un árbol de fuentes aplastando las confirmaciones.

Cuando aplasta las confirmaciones, está combinando 2 o más confirmaciones en una única confirmación. Esto se puede hacer por muchas razones, una de las cuales es que el historial de la fuente debe limpiarse antes de compartirlo con su equipo o enviar una solicitud de extracción a un proyecto de código abierto. Por ejemplo, digamos que su historial de confirmaciones reciente se parece a esto:

$ git log --oneline
b7c864c Seriously, #421 is fixed now
7729f48 Fixed typo
cc4f2b5 Didn't work, trying something else
b1339db Fixed issue #421
c9f9e96 Updated docs for feature ABC
4eeb10f Added feature ABC
...

Como puede ver en los registros, el problema # 421 requirió varios intentos para solucionarse. Aunque es genial que finalmente se haya encontrado la solución, esto no es exactamente algo que le gustaría compartir con el resto de su equipo. Lo único que realmente les importa es la solución final al problema # 421, pero no necesariamente cómo llegaste allí. En casos como este, es posible que desee aplastar las confirmaciones juntas para crear una confirmación agradable y limpia para este problema.

Para aplastar las confirmaciones, deberá usar el rebase comando como este:

$ git rebase -i HEAD~4

Esto le dice a Git que vuelva a aplicar las últimas 4 confirmaciones sobre otra sugerencia base. los -i bandera es la abreviatura de --interactive, que abrirá su editor de texto predeterminado para que pueda editar los comandos antes de reajustar. Para nuestro ejemplo anterior, veríamos un editor de texto con las últimas 4 confirmaciones en orden inverso, como el siguiente:

pick b1339db Fixed issue #421
pick cc4f2b5 Didn't work, trying something else
pick 7729f48 Fixed typo
pick b7c864c Seriously, #421 is fixed now

Cualquier confirmación con la palabra clave “picK” permanecerá en el árbol de fuentes. Sin embargo, si reemplaza “pick” con “squash”, esa confirmación se combinará con la anterior. Continuando con nuestro ejemplo, nos gustaría combinar las confirmaciones de esta manera:

pick b1339db Fixed issue #421
squash cc4f2b5 Didn't work, trying something else
squash 7729f48 Fixed typo
squash b7c864c Seriously, #421 is fixed now

Guardar sus ediciones en este archivo dará como resultado una única confirmación que es la combinación de los cambios de los cuatro, y el mensaje de confirmación es una combinación de los 4 también. Para especificar un nuevo mensaje de confirmación, debe utilizar “reword” en lugar de “elegir” en la primera confirmación.

O, si desea mantener solo el mensaje de confirmación “elegido”, puede usar “arreglar” en lugar de “aplastar” para los demás, lo que hará lo mismo que aplastar pero descartará el mensaje de confirmación.

Estos son todos los comandos que se pueden usar al reajustar:

• pick (o p): use commit
• reword (o r): use commit, pero edite el mensaje de commit
• edit (o e): use commit, pero deténgase para enmendar
• squash (o s): usa la confirmación, pero fusiona la confirmación anterior
• fixup (o f): como “squash”, pero descarta el mensaje de registro de esta confirmación
• exec (o x): ejecutar comando (el resto de la línea) usando shell
• drop (o d): eliminar el compromiso

Y algunas otras notas importantes de Git con respecto al modo interactivo al reajustar confirmaciones:

• Las líneas se pueden reordenar, se ejecutan de arriba a abajo.
• Si quita una línea allí ese compromiso se perderá.
• Sin embargo, si elimina todo, la rebase se cancelará.
• Tenga en cuenta que las confirmaciones vacías están comentadas

Arreglar sus confirmaciones de esta manera es una buena práctica antes de compartir con los miembros de su equipo o antes de enviar los cambios a un repositorio remoto. Es mucho más fácil leer un árbol de fuentes y comprender qué errores se han corregido cuando una sola confirmación corrige un solo error, por ejemplo. Sin embargo, si alguna de estas confirmaciones ya se ha enviado al repositorio remoto, no se recomienda aplastar las confirmaciones, ya que estaría reescribiendo el historial.

Para obtener más información, recomiendo leer los documentos de Git para rebase mando Aquí.