En dado caso de que ya hayas trabajado con Git, o ya sea que eres relativamente nuevo usándolo, entonces este artículo es para ti. Para ser honesto, a mí me hubiera encantado toparme con un artículo como este después de haber aprendido lo básico de Git.
Muy probablemente habrás escuchado de Git si es que estás familiarizado con la programación, pero si es el caso de que no tienes ni idea de lo que es, deja explicártelo.
¿Recuerdas aquellos días en que estabas en la escuela y te dejaban encargado un ensayo? Probablemente, habrás guardado varias versiones del mismo archivo pero con diferentes nombres.
Por ejemplo, “ensayofinal_v1.doc”, “ensayofinal_v2FINAL.doc”, “ensayofinalTELOJUROFINAL.doc”, y así sucesivamente.
Esta es una forma para guardar cambios de un archivo con el tiempo.
Sin embargo, hay problemas que no se ven a primera instancia si es que decides guardar los cambios de tus documentos de esta manera.
Primero que nada, es muy fácil perder la noción de qué versión era la más reciente o qué cambios se habían realizado. En segundo lugar, si se quisiera experimentar con diferentes ideas, se necesita crear una nueva versión del archivo, por lo que podría volverse muy confuso.
Y es aquí donde entran los sistemas de control de versiones con Git.
Git te permite efectuar un seguimiento de los cambios de tu código o documentos de una manera más organizada. Con Git, puedes generar un repositorio para tu proyecto y, cada vez que ejecutas un cambio, puedes guardarlo como un “commit” con una descripción de lo que se modificó.
Con Git puedes hacer seguimiento de los cambios de un documento con varios usuarios trabajando en el mismo proyecto.
Antes de seguir, quiero informarte que no puedo recomendar lo suficiente este tutorial de freeCodeCamp.org para aprender los conceptos básicos:
No obstante, incluso con este tutorial, sé que en algún momento puedes estropear algo, y está bien, es normal.
Entonces, ¿cómo dejas de estropear tanto?
Afortunadamente, después de encontrarme con este artículo, pude identificar mis cinco errores más comunes y cómo evitarlos.
Lo importante es aprender de esos errores y tomar medidas para prevenirlos en el futuro.
#1 Dangit, hice algo terriblemente mal, por favor dime que git tiene una máquina del tiempo mágica!?!
Afortunadamente, si hay una forma para hacerlo. Puedes utilizar git reflog para arreglar tu desastre.
Puedes recuperarte que accidentalmente eliminaste, puedes recuperarte después de romper un código, puedes recuperarte después de hacer un mal “merge”, puedes viajar en el tiempo en un momento en específico cuando tu código estaba funcionando.
git reflog es un salvavidas, definitivamente.
# Create directory and initialize Git repository
mkdir dangit_one
cd dangit_one
git init
# Create new file and commit it
echo "First commit" > file1.txt
git add file1.txt
git commit -m "First commit"
# Modify the file and commit changes
echo "Second commit" >> file1.txt
git add file1.txt
git commit -m "Second commit"
# Use git reflog to see commit history
git reflog
# Use git reset to go back to previous commit
git reset HEAD@{1}
Ahora tu directorio se restablece al estado anterior del commit erróneo.
Ten en cuenta que si tienes cambios no confirmados en tu directorio, es posible que debas ejecutar stash primero antes de realizar git reset para evitar conflictos.
Por cierto, si te estás preguntando por qué git reset no modificó el archivo cambiando el comentario “Second commit”, puedes usar git reset --hard
Ten presente que usar git reset --hard es una operación destructiva y perderás los commits. Con el siguiente error que explicaré entenderás de qué estoy hablando.
#2 Dangit, necesito deshacer un commit de hace 5 commits!
De repente te das cuenta de que todo lo que estabas haciendo está mal, peor sabes que hay un punto en la línea del tiempo de tu historial, que te das cuenta de que puedes volver a donde quieres.
Para eso, usas git revert
# Create directory and initialize Git repository
mkdir dangit_two
cd dangit_two
git init
# Create new file and commit it
echo "First commit" > file2.txt
git add file2.txt
git commit -m "First commit"
# Modify the file and commit changes
echo "Second commit" >> file2.txt
git add file2.txt
git commit -m "Second commit"
# Modify the file again and commit the changes
echo "Third commit" >> file2.txt
git add file2.txt
git commit -m "Third commit"
# Modify the file one more time and commit the changes
echo "Fourth commit" >> file2.txt
git add file2.txt
git commit -m "Fourth commit"
# Check the commit history
git log --oneline
# Output
# (HEAD -> main) (hash4) Fourth commit
# (hash3) Third commit
# (hash2) Second commit
# (hash1) First commit
# If you want to undo changes by the "Third commit"
# This will open an editor with a default commit message
git revert hash3
# Check changes in the working directory
cat file2.txt
# Output
# First commit
# Second commit
# Fourth commit
NOTA: En caso de que obtengas un conflicto de “merge” entre los cambios introducidos del “Third commit”, recibirás un mensaje que indica que Git no pudo resolver automáticamente el conflicto al revertir la confirmación.
Para efectos de este ejemplo, hacemos los cambios entre los marcadores y quitamos el “Third commit”.
Una vez que ya hiciste eso, haz lo siguiente:
# Stage the resolved file
git add file2.txt
# Continue with the revert process
git revert --continue
Probablemente, te estés preguntando por qué Dangit #1 y este error son similares. ¿Recuerdas que te comenté que git reset --hard puede ser destructivo?
Explicando las diferencias te hará entender:
git reset
- Este comando mueve el HEAD y la rama actual a un commit en específico.
- Puede usarse para eliminar uno o más de un commit del historial de la rama.
- No crea nuevos commits.
git revert
- Este comando genera un nuevo commit que deshace los cambios.
- No modifica el historial de commits existente, pero agrega un nuevo commit que revierte los cambios del commit especificado.
- Es útil cuando se colabora con otros o cuando se trabaja en un repositorio público porque no reescribe el historial.
Así que en resumen, si deseas deshacer los cambios y mantener el historial de confirmaciones (especialmente cuando trabajas con otros), utilizas git revert. Si deseas eliminar commits del historial y no te importa volver reescribir el historial, empleas git reset.
#3 Dangit, hice commit e inmediatamente me di cuenta que tenía que hacer un pequeño cambio!
Sí, esto suele pasar. Pensaste que ya terminaste, pero de repente de tas cuenta de que hay una pequeña cosa que te perdiste y quieres arreglarlo. ¿Cómo hacerlo?
Con git commit --amend
Citando el artículo:
Advertencia: Nunca deberías arreglar commits que han sido subidos a ramas públicas/compartidas. Solo arregla commits que existan en tu copia local o la vas a pasar mal.
# Create directory and initialize Git repository
mkdir dangit_three
cd dangit_three
git init
# Create new file and commit it
echo "First commit" > file3.txt
git add file3.txt
git commit -m "First commit"
# Modify the file and commit changes
echo "Second commit" >> file3.txt
git add file3.txt
git commit -m "Second commit"
# If you need to make a small change and want to include it in the last commit
echo "Small change" >> file3.txt
git add file3.txt
# Amend the last commit
git commit --amend
Ahora ya podrás ver el último commit “Second commit” incluye “Small change”.
#4 Dangit, accidentalmente hice commit de algo a master que debía haber sido en una nueva rama!
¿Te suena familiar esta situación? Pensaste que estabas trabajando en una nueva rama, pero ¿adivina qué? ¡El commit estaba apuntando a master! Citando el artículo:
Nota: esto no funciona si ya haz realizado el push a una rama pública/compartida, y si haz intentado otra cosa antes, podrías necesitar hacer git reset HEAD@{number-of-commits-back} en vez de HEAD~. Tristeza infinita. También, mucuuuuuchas personas sugirieron una increible manera de hacer esto más corto que no la sabía. Gracias a todos.
# Create directory and initialize Git repository
mkdir dangit_four
cd dangit_four
git init
# Create new file and commit it
echo "First commit" > file4.txt
git add file4.txt
git commit -m "First commit"
# Make a change and commit in main branch
echo "Second commit" >> file4.txt
git add file4.txt
git commit -m "Second commit"
# Create new branch
git branch the-best-branch
# Remove the last commit from 'main' branch
git reset HEAD~ --hard
# Check out the new branch
git switch the-best-branch
Toma en consideración que este método solo debe usarse si no se ha enviado el commit a una rama pública o compartida.
#5 Olvida este ruido, me doy por vencido.
¿Has probado todo lo que se te ocurre en Git? No es la mejor opción, pero funciona:
# This is exactly as it says in dangit.com
cd ..
sudo rm -r stupid-git-repo-dir
git clone https://some.github.url/stupid-git-repo-dir.git
cd stupid-git-repo-dir
Repito, no es la mejor opción, y no es una buena práctica, pero en caso de que ya agotaste todas tus opciones, entonces hazlo.
Git puede ser complicado porque puedes cometer errores fácilmente. La advertencia aquí es que cualquiera que conozca Git tiene sus métodos para manejarlo. Puedes encontrar más de una solución para resolver cualquier problema en particular con el que estés lidiando, y eso está bien.
Explicar Git de forma sencilla es, y siempre será, la mejor forma para explicarle a alguien que recién empieza a utilizarlo.
En realidad, usar manzanas y peras como metáfora es un método bien establecido para explicar casi cualquier cosa en la vida.
Y recuerda, si tienes problemas con Git, no dudes en volver a ester artículo tantas veces como quieras.
Top comments (0)