Nota perev. : Hace unos días, apareció una pequeña pero muy útil nota en el blog para ingenieros de nuestro proyecto GitLab favorito con instrucciones que ayudan a ahorrar tiempo y nervios en caso de varios problemas que ocurren mientras trabaja con Git. Es poco probable que sean nuevos para los usuarios experimentados, pero ciertamente habrá aquellos a quienes serán útiles. Y al final de este material, agregamos una pequeña bonificación de nosotros mismos. ¡Que tengas un buen viernes!Todos cometemos errores, especialmente cuando trabajamos con sistemas complejos como Git. Pero recuerda: ¡Git sucede!
Si recién está comenzando con Git, aprenda los
conceptos básicos para trabajar con él en la línea de comandos. Y aquí hablaré sobre cómo puede solucionar los seis errores más comunes en Git.
1. Vaya ... Me equivoqué en el mensaje de la última confirmación
Después de varias horas de codificación, es fácil cometer un error en el mensaje de confirmación. Afortunadamente, esto es fácil de solucionar:
git commit --amend
Con este comando, se abrirá un editor de texto que le permitirá realizar cambios en el mensaje hasta la última confirmación. Y nadie sabrá que usted escribió "agregado" con tres "ds".
2. ¡Vaya! Olvidé agregar el archivo a la última confirmación
Otro error popular en Git es un commit demasiado apresurado. ¿Se olvidó de agregar el archivo, olvidó guardarlo o debería hacer un pequeño cambio para que la confirmación sea significativa? Tu amigo será ...
--amend nuevo.
Agregue el archivo que falta y ejecute este comando correcto:
git add missed-file.txt git commit --amend
Ahora puede corregir el mensaje o simplemente guardarlo en su forma original (con el archivo agregado).
3. Vaya ... agregué un archivo que no debería estar en este repositorio
Pero, ¿y si tienes la situación opuesta? ¿Qué sucede si agregaste un archivo que no quieres comprometer? Un archivo ENV engañoso, un directorio de compilación o una foto con un gato que se guardó accidentalmente en el directorio incorrecto ... Todo está resuelto.
Si solo ha realizado una
etapa para el archivo y aún no lo ha confirmado, todo se hace mediante un simple
restablecimiento del archivo deseado (ubicado en la etapa):
git reset /assets/img/misty-and-pepper.jpg
Si aún confirma el cambio, se requiere un paso preliminar adicional:
git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit
La confirmación se revertirá, la imagen se eliminará y luego se realizará una nueva confirmación.
Nota perev. : Como se señaló en los comentarios sobre el artículo original, este problema también se puede resolver utilizando el ya mencionado --amend . Aparentemente, con este párrafo, el autor quería mostrar qué otras formas hay de cambiar el historial de confirmaciones para corregir el error.4. Vaya ... cometí cambios en master
Entonces, está trabajando en una nueva característica y se apresuró, olvidando crear una nueva rama para ella. Ya ha confirmado un montón de archivos y todas estas confirmaciones están en el maestro. Afortunadamente, GitLab
puede evitar push'y directamente en master. Por lo tanto, podemos revertir todos los cambios necesarios a una nueva rama con los siguientes tres comandos:
Nota : Asegúrese de confirmar o esconder los ceros primero, ya que de lo contrario se perderán. git branch future-brunch git reset HEAD~ --hard git checkout future-brunch
Se creará una nueva rama, en master: se hace una reversión al estado en el que estaba antes de los cambios, y luego se realiza el
pago de la nueva rama con todos sus cambios.
5. Vaya ... cometí un error en el nombre de la sucursal
Los más atentos pudieron notar en el ejemplo anterior un error en el nombre de la sucursal. Son casi las 3 p.m., y todavía no he cenado, así que mi hambre llamó a la nueva sucursal (
br nch ) como
brunch futuro . Golosinas!
Cambie el nombre de esta rama de la misma manera que se usa al cambiar el nombre de un archivo con el comando
mv , es decir, colocándolo en una nueva ubicación con el nombre correcto:
git branch -m future-brunch feature-branch
Si ya empuja esta rama, necesitará un par de pasos adicionales. Eliminaremos la rama vieja del
control remoto y empujaremos la nueva:
git push origin --delete future-brunch git push origin feature-branch
Nota perev. : Todavía puede eliminar una rama del control remoto usando: git push origin :future-brunch
6. ¡Vaya ... lo hice de nuevo!
El último comando en caso de que todo saliera mal. Cuando acumuló y empujó un montón de soluciones con Stack Overflow, después de lo cual todo en el repositorio se volvió aún peor de lo que era al principio. Todos nosotros una vez enfrentamos algo similar ...
git reflog muestra una lista de todas las operaciones que realizó. Luego le permite usar las capacidades mágicas de viaje en el tiempo de Git, es decir, volver a cualquier momento del pasado. Debo señalar que esta es su última esperanza: no debe recurrir a ella en casos simples. Entonces, para obtener la lista, haga:
git reflog
Cada uno de nuestros pasos está bajo la atenta mirada de Git. Ejecutar el equipo en el proyecto anterior produjo lo siguiente:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit
Presta atención a la columna de la izquierda: este es el índice. Si desea regresar a cualquier punto de la historia, ejecute el siguiente comando, reemplazando
{index} con el valor apropiado (por ejemplo,
dfa27a2 ):
git reset HEAD@{index}
Entonces, ahora tiene seis formas de salir de los Gitfalls más frecuentes
(juego de palabras: la trampa se traduce como "trampa, error" - aprox. Transl. ) .
Bono del traductor
En primer lugar, un comentario valioso sobre todo lo escrito anteriormente (excepto el párrafo 5). Tenga en cuenta que estas acciones cambian el historial de confirmaciones, por lo que deben llevarse a cabo solo si los cambios no se han enviado a
control remoto (push'nut). De lo contrario, la antigua mala confirmación ya estará en la rama
remota y tendrá que realizar
git pull (lo que hará la
fusión , y luego tratar de "borrar" el historial dará lugar a peores consecuencias), o
git push --force , que está plagado de pérdida de datos cuando se trabaja con una rama de varias personas ...
Ahora, pequeñas adiciones útiles de nuestra experiencia:
- Si (accidentalmente o no) cambió la rama y necesita volver a la anterior, la forma más rápida es usar
git checkout - . - Si accidentalmente agregó un archivo al commit que no debe agregarse allí, pero aún no lo ha hecho, use
git reset HEAD path/to/file . Una situación similar se describe en el párrafo 3, pero en realidad es más amplia, porque se refiere a cualquier cambio innecesario en la confirmación (no solo el caso de un archivo adicional). - Es una buena práctica no comprometerse demasiado, utilizando la opción
-p al agregar un archivo a una confirmación ( git add -p ). Esto le permite revisar cada cambio que entra en la confirmación. Pero vale la pena recordar que no agrega archivos sin seguimiento a la confirmación; deben agregarse sin este parámetro. - Se pueden encontrar varias buenas recomendaciones (incluidas las más complejas) en el artículo de 2014 " Tutorial de Git: 10 problemas comunes de Git y cómo solucionarlos ". En particular, tenga en cuenta el uso de
git rebase -i y git rebase -i .
PD del traductor
Lea también en nuestro blog: