Yo sé que en tu oxidada memoria de GenX, en lo que piensas cuando ves esas tres letras, es en la banda ochentera argentina formada por Guyot, Iturri y Toth:
Pero no, este artículo de la serie del programador oxidado habla sobre una de las herramientas esenciales para programar hoy en día.
No sé si has usado un sistema de control de versiones, pero dependiendo de tu grado de oxidación, quizás usaste algo como RCS, CVS, SVN o, sufriste con SourceSafe de Microsoft. Si no usabas ninguna de estas herramientas, es casi seguro que terminaste en una situación similar a lo que muestra esta viñeta que publicó hace unos años Alberto Montt:
Si no sabes nada de sistemas de gestión de código fuente, te recomiendo este artículo que escribí hace algún tiempo.
Los sistemas de control de versiones son vitales para el trabajo en equipo, pues permiten la coordinación e integración del trabajo distribuido de los distintos miembros del equipo. Es por esto que los sistemas de gestión de código distribuidos son tan populares hoy en día, y hay uno en particular que es el más usado: GIT.
Pero este artículo no pretende enseñar a utilizar GIT, para eso hay miles de tutoriales en internet o en YouTube. Mi objetivo es explicarte algunos aspectos básicos esenciales que algunos de estos tutoriales pasan por alto.
Primero, hay que entender que en tu entorno local (el computador donde estás trabajando) hay tres áreas, o árboles como los llama Scott Chacon en esta brillante charla.
Estos espacios son:
Working Directory: que es donde están los archivos que estás editando.
Stage Area o Index: que es donde reside el próximo commit candidato (yo la llamo área de paso).
Head: que es donde está el último commit.
Vamos un poco más lento, acá asumiré que has configurado un repositorio con el comando git init
y que tienes un archivo llamado main.py
que tiene el siguiente contenido:
print("hola mundo")
Cuando ejecutas este comando:
git add main.py
has creado un commit candidato que se encuentra ahora en el área de paso (staging), eso se puede ver si ejecutas git status
, que se ve así:
Y acá viene lo importante, si agregas una línea adicional y haces git commit esa línea adicional no se verá reflejada en tu commit. Esto está pensado para dar flexibilidad, pero es algo que puede llegar a confundir a muchos usuarios.
Por ejemplo, supongamos que agrego una línea y ahora mi archivo se ve así:
print("hola mundo")
print(“adios mundo")
Si ahora ejecuto git status
se ve así:
Si ejecutas git commit
ese cambio no quedará reflejado en HEAD, tal como se verifica al hacer git status
de nuevo:
Es por eso que muchas personas aprenden el “truco” de ejecutar git commit
con el parámetro -a
. Esto es lo mismo que ejecutar git add
de los archivos modificados más un git commit
.
En resumen, recuerda que hay tres áreas o árboles en tu repositorio local, que git add
agrega los cambios al área de paso, y que git commit
es el comando que deja esos cambios definitivamente en tu repositorio, listos para ser compartido con el resto de tus colegas. Si dominas estas ideas desde el principio, créeme que tu experiencia con GIT será más sencilla.
Si te gustó, considera suscribirte:
Y si ya estás suscrito y consideras que esto puede ser útil para alguien más, entonces te animo a compartir este artículo.