Git: arreglando errores y arreglando commits

Error en commit ... ¿Cómo solucionarlo? Un desastre en la historia de los commits ... ¿Cómo hacer que todo parezca decente? El autor del artículo, cuya traducción publicamos hoy, dice que fue escrito específicamente para aquellos que hicieron tales preguntas. Según él, después de estudiar las técnicas para trabajar con Git presentadas aquí, puede avanzar significativamente en el camino del desarrollo de Git.


Se supone que el lector de este artículo ya está familiarizado con los conceptos básicos de Git. Si esto no es así, primero se recomienda dominar la base, por ejemplo, utilizando este material.

Corregir errores en commits

Aquí veremos varios escenarios para errores en commits y su corrección.

▍ Escenario número 1

Suponga que confirmó muchos archivos y se dio cuenta de que el mensaje de confirmación no era muy claro. Después de eso, decidiste cambiar este mensaje. Para hacer esto, use el git commit --amend . Aquí hay un ejemplo de su aplicación:

 git commit --amend -m "New commit message" 

▍ Escenario número 2

Supongamos que desea comprometer seis archivos, pero cometió por error solo cinco. Parece que puede solucionar este error simplemente creando una nueva confirmación y agregando el sexto archivo que falta allí.

Este enfoque tiene derecho a la vida. Pero para mantener el historial de confirmación en buenas condiciones, probablemente sería mucho mejor poder agregar un archivo omitido al azar a la misma confirmación. Esto se puede hacer, nuevamente, con el git commit --amend . Su uso se ve así:

 git add file6 git commit --amend --no-edit 

El indicador --no-edit significa que el mensaje de confirmación no cambia.

▍ Escenario número 3

Las confirmaciones que se realizan en Git están vinculadas al nombre del autor y su dirección de correo electrónico. Típicamente, estos datos se indican realizando la configuración inicial de Git. Como resultado, aquellos que usan Git pueden, al ejecutar cada confirmación, no les importa la información sobre su autor.

Además, es muy posible que cuando trabaje con algunos proyectos, necesite usar información sobre el autor, por ejemplo, una dirección de correo electrónico que difiera de las principales. Para dicho proyecto, debe especificar una dirección de correo electrónico con este comando:

 git config user.email "your email id" 

Supongamos que olvidó hacer esta configuración y ya realizó la primera confirmación. Corregir la situación ya puede ser familiar para nosotros amend equipo. Al usarlo, puede cambiar la información sobre el autor de la confirmación anterior:

 git commit --amend --author "Author Name <Author Email>" 

▍ Nota

Use el comando amend solo en su repositorio local. Su uso en repositorios remotos puede generar una enorme confusión.

Poner orden en la historia de commits

Supongamos que está trabajando en un código para un proyecto. Sabes que tomará unos diez días. Durante estos diez días, otros desarrolladores se comprometen con el repositorio de origen.

Se recomienda mantener la sincronización entre los repositorios locales y remotos. Esto evita los muchos conflictos de fusión que surgen cuando los repositorios son demasiado raros para sincronizar. Siguiendo esta práctica, decide descargar los cambios desde el repositorio remoto cada dos días.

Cada vez que descarga código de un repositorio remoto al local, se crea una nueva confirmación de fusión en el repositorio local. Esto significa que en su historial de confirmación local habrá muchas confirmaciones que pueden confundir a la persona que verá su código.


Historial de confirmaciones en el repositorio local

¿Cómo ordenar el historial de confirmaciones? Para resolver este problema, puede usar el git rebase .

▍Git comando de rebase

Considere el git rebase como ejemplo.


Se compromete en la rama Release y en la rama Feature

Hay tres commits en la rama Release : Rcommit1 , Rcommit2 y Rcommit3 . Creó su rama Feature desde la rama Release cuando solo tenía una confirmación: Rcommit1 . Después de eso, agregó dos confirmaciones a la rama Feature . Estos son Fcommit1 y Fcommit2 . Su objetivo es cargar confirmaciones desde la rama Release a su rama Feature . Para hacer esto, usará el comando rebase .

Utilizaremos la release y la feature nombres para las dos ramas bajo consideración.

Como resultado, el uso del rebase se verá así:

 git checkout feature git rebase release 

▍ Características del comando rebase

El comando rebase usa para garantizar que la rama Feature tenga un código nuevo de la rama Release .

Al aplicar este comando, el sistema intenta agregar cada confirmación a la rama Feature , una a la vez, y buscar conflictos. Si esto suena complicado, veamos la siguiente figura. Esto muestra los mecanismos internos del rebase .


Función de ramificación y tres pasos del comando rebase

Paso 1

Cuando se llama al comando, la rama Feature apunta al encabezado de la rama Release . Después de eso, hay tres confirmaciones en la rama Feature : Rcommit1 , Rcommit2 y Rcommit3 . Quizás aquí tenga una pregunta sobre lo que sucedió con los Fcommit1 y Fcommit2 . Estas confirmaciones no han desaparecido, se utilizarán en los próximos pasos.

Paso 2

Git ahora está tratando de agregar el compromiso Fcommit1 a la rama Feature . Si no hay conflicto, Fcommit1 agrega después de Rcommit3 . Si se detecta un conflicto, Git lo informará y deberá resolverlo manualmente.

Paso 3

Después de que el commit Fcommit1 agrega a la rama Feature , Git intenta agregar Fcommit2 allí Fcommit2 . Aquí, de nuevo, si no hay conflictos, Fcommit2 agrega Fcommit1 después de Fcommit1 y la operación se completa con éxito. Si se detecta un conflicto, Git, como antes, lo informará y se ofrecerá a solucionarlo.

Una rebase comando rebase puede ver que hay commits Rcommit1 , Rcommit2 , Rcommit3 , Fcommit1 y Fcommit2 en la rama Feature .

▍ Nota

Cuando se trabaja con Git, se rebase tanto el comando de merge como el comando de rebase . Esto no quiere decir que uno de ellos sea preferible al otro.

Si usa el comando merge , recibirá un commit de merge . Si usa rebase , no tendrá ninguna rebase adicional.

Se recomienda que use estos comandos en diversas situaciones. Por lo tanto, rebase es adecuado para actualizar el código del repositorio local basado en el último código del repositorio remoto. Use el comando merge para realizar solicitudes de extracción para fusionar la rama Feature con la rama Release o Master .

Resumen

Después de estudiar los conceptos presentados en este artículo, ha mejorado sus habilidades de Git y está más cerca del nivel de un experto en Git. Esperamos que lo que aprendiste aquí te sea útil. Pero el mundo de Git es enorme, por lo tanto, habiendo dominado algo nuevo, no te detengas allí y sigue adelante.

Estimados lectores! ¿Has encontrado un desastre en git commits?