6 errores de Git que cometerá y cómo solucionarlos

Una gran razón por la que los desarrolladores utilizan un sistema de control de fuentes como Git es para evitar desastres. Si hace algo tan simple como eliminar un archivo por error, o si descubre que los cambios que ha realizado en una docena de archivos no fueron aconsejables, puede deshacer lo que ha hecho sin problemas.

Algunos errores de Git son más intimidantes y difíciles de revertir, incluso para usuarios experimentados de Git. Pero con un poco de cuidado, y siempre que no entre en pánico, puede retroceder de algunos de los peores desastres de Git conocidos por los programadores.

Aquí hay una lista de varios de los boo-boos de Git más grandes, junto con consejos para retroceder y prevenir algunos de ellos. Cuanto más avanza en la lista, mayores se vuelven los desastres.

Error de Git n. ° 1: olvidó agregar cambios a la última confirmación

Este es uno de los errores de Git más fáciles de recuperar. Digamos que comprometió un poco de trabajo en una sucursal local y luego se dio cuenta de que no organizó varios archivos necesarios. O olvidó agregar ciertos detalles en el mensaje de confirmación.

Sin miedo. Primero, si tiene que realizar nuevos cambios, hágalo. Luego escriba git commit --amendpara editar el mensaje de confirmación. Una vez que haya terminado, presione Esc, luego escriba :xqpara guardar y salir del editor. (Este último paso es el que a menudo pone nerviosos a los recién llegados a Git, quienes no siempre se dan cuenta de que el editor de Git incorporado es en gran medida su propio animal).

Si solo está cambiando archivos y no necesita modificar el mensaje de confirmación, puede usar git commit --amend --no-editpara agregar los archivos y omitir el proceso de edición del mensaje.

Una forma de evitar este tipo de error es modificar la forma en que realiza las confirmaciones en Git. Si está trabajando en algo en lo que constantemente realiza pequeños compromisos para realizar un seguimiento de las revisiones incrementales, hágalo en una rama desechable. Mientras hace esto, documente los cambios importantes que está realizando en algún lugar; no espere hasta que se enfrente a la git commitlínea de comandos para escribirlo todo. Luego, cuando alcance un hito importante, use git merge --squashde su rama desechable para guardar los resultados en la rama de trabajo en progreso como una confirmación única y limpia, y use las notas que ha tomado para el mensaje de confirmación.

Error de Git n. ° 2: cometió cambios en el maestro (local)

Otro error común: ha cometido diligentemente un montón de cambios ... pero en la rama principal de su repositorio por error. Lo que realmente quería hacer era enviarlos a una nueva rama, oa esa devrama que tiene específicamente para cambios importantes.

No todo está perdido. Este error se puede solucionar en tres comandos:

rama git nueva rama

git reset HEAD ~ --hard

git checkout nueva rama

El primer comando crea la nueva rama con la que queremos trabajar. El segundo comando restablece la rama principal justo antes de la última confirmación, pero deja los cambios que acaba de realizar en la nueva rama. Finalmente, cambiamos a la nueva rama donde le esperan sus cambios.

Si ha realizado varias confirmaciones, use git reset HEAD~ --hard, donde es la cantidad de confirmaciones que desea realizar. O puede usar git reset , donde está el ID de hash de la confirmación de destino si lo tiene a mano.

Para evitar este error, adquiera el hábito de crear nuevas ramas y cambiar a ellas, incluso si simplemente se van a descartar, cada vez que comience una sesión con su código.

Error de Git n. ° 3: eliminó un archivo o directorio

Otro desastre común es destruir por error el contenido de un archivo ... y solo al enterarse de ello, muchos se comprometen con la rama después del hecho. Afortunadamente, existe una solución fácil.

Primero, use las git logherramientas Git integradas de su IDE para encontrar el ID de hash de una confirmación antes de que se modificara el archivo. A continuación, use git checkout hash_id -- /path/to/filepara verificar solo ese archivo de la confirmación en cuestión. Tenga en cuenta que la ruta debe ser relativa a la raíz del proyecto. Esto colocará la versión anterior del archivo en el área de preparación de su proyecto.

Si simplemente desea retroceder n confirmaciones, no necesita el ID de hash. Puede simplemente emitir el comando git checkout HEAD~ -- /path/to/file, donde está el número de confirmaciones que desea realizar.

Si desea consultar un directorio completo de archivos, utilice el formato comodín de Git para las rutas de archivo. Por ejemplo, ingresar  git checkout HEAD~1 -- ./src/**le devolverá una confirmación y recuperará todo en el /srcdirectorio desde la raíz de su proyecto.

Error de Git # 4: borraste accidentalmente una rama

Aquí hay un escenario que todos tememos: eliminar accidentalmente una rama completa de nuestro repositorio. Este puede ser muy fácil de recuperar o un poco más complicado, según las circunstancias.

Primero, use git reflogpara encontrar la última confirmación realizada en la rama. Luego use el ID de hash para crear una nueva rama:

git checkout -b restored-branch

Tenga en cuenta que esto solo hará que se fríe el tocino si la rama en cuestión ya se fusionó. Si eliminó a la fuerza una rama no fusionada , tiene una forma más de encontrarla, siempre que no haya ejecutado git gcen el repositorio:

git fsck --full --no-reflogs --unreachable --lost-found

Esto arrojará una lista de todos los hashes de confirmación para objetos que ya no son accesibles, incluidas las ramas eliminadas. Busque en la parte inferior de la lista una entrada de "confirmación inalcanzable" e intente restaurar esa ID de hash en una nueva rama para ver si es la que envió a la papelera. Si no es así, avance en la lista hasta la siguiente y vea qué puede recuperar.

Como regla general, nunca fuerce la eliminación de una rama de forma predeterminada, ya que fácilmente podría terminar destruyendo una rama no fusionada que todavía tiene algo valioso. Si habitualmente fuerza la eliminación de ramas, eso es una señal de que sus hábitos de trabajo con las ramas deben ser menos complicados.

Error de Git n. ° 5: golpeaste la rama remota con git push

Una vez estaba trabajando en una copia local de un repositorio de GitHub y por error empujé mi rama maestra a la copia remota con la --forceopción. Terminé con una copia pública de un repositorio que no estaba en un estado utilizable en ese momento. ¡Uy grande!

Si ha cometido un error como este, y su repositorio se sincronizó con el repositorio remoto lo suficientemente recientemente, puede usar su propia copia de la rama del repositorio remoto para solucionarlo. Cambie a la rama que necesita resincronizar, asumiendo que aún no está allí, y emita este comando:

git reset --hard /@{1}

Esto restablecerá su copia de a la última versión sincronizada de . En mi caso, la rama era mastery el repositorio remoto era origin, por lo que podría haber usado git reset --hard origin/[email protected]{1}.

Luego use git push -f para restaurar el repositorio remoto a su estado anterior.

Una forma de evitar que esto vuelva a suceder es no permitir el empuje forzado. Puede configurar esto en el repositorio remoto de Git con este comando:

git config --system receive.denyNonFastForwards true

Puede llegar un momento en que necesite hacer un empuje forzado, pero probablemente sea mejor activarlo cuando lo necesite y desactivarlo cuando no lo necesite.

Error de Git n. ° 6: comprometiste información privada en un repositorio público

Este puede ser el problema de Git peor y más difícil de tratar. Envió por error datos confidenciales a un repositorio público y desea eliminar quirúrgicamente los archivos del repositorio. Debe asegurarse de que los datos confidenciales no se puedan encontrar incluso volviendo a una confirmación anterior, pero debe hacerlo  sin tocar nada más.

Esto es doblemente difícil si el expediente en cuestión se comprometió, oh, hace seis semanas, y mientras tanto se ha cometido una gran cantidad de otros trabajos importantes. No puede simplemente volver a antes de que se agregara el archivo; arruinarás todo lo demás en el proceso.

La buena noticia: algunos intrépidos expertos en Git crearon una herramienta, BFG Repo-Cleaner, específicamente con el propósito de eliminar datos incorrectos de los repositorios de Git. BFG Repo-Cleaner le permite realizar rápidamente tareas comunes en un repositorio, como eliminar todos los archivos que coincidan con un comodín en particular o que contengan ciertos textos. Incluso puede pasar un archivo que enumere todos los textos no deseados.

BFG Repo-Cleaner es esencialmente una automatización para un proceso de varios pasos git filter-branch. Si prefiere hacer las cosas a mano, GitHub tiene un tutorial detallado del proceso. Pero la herramienta BFG cubre la gran mayoría de los casos de uso comunes, muchos de los cuales están integrados en las opciones de la línea de comandos de la herramienta. Además, el proceso es largo y complejo, y es muy fácil dispararse en el pie en algún punto del camino si lo hace a mano.

Tenga en cuenta que si limpia datos de una sucursal local que debe sincronizarse en otro lugar, no podrá sincronizar excepto mediante un empuje forzado a las sucursales remotas. Todo el árbol de confirmación debe reescribirse, por lo que, en esencia, está escribiendo un historial completamente nuevo en remoto. También deberá asegurarse de que todos los demás obtengan una copia nueva del repositorio reescrito después de sus cambios, porque sus repositorios tampoco serán válidos.