Capitulo 3 ➜ El ciclo de vida de los archivos en #git | Capitulo 3 | parte 1

Bienvenidos a la tercera lección de este curso sobre git, espero que hayan podido instalar git sin problemas, y que ya tengan interiorizado los conceptos de la primera lección, sobre teoría, porque constantemente estaremos regresando a esa lección para entender ahora si en la práctica, mucho de lo que se dijo entonces, en especial la primera parte sobre el siglo de vida en git, que como ya habrán notado tomara mas de una lección abarcar este tema, empezando por esta lección, pero ya siendo más específico lo que veremos en la lección de hoy, será lo siguiente:

• Preparando el área de trabajo
• ¿Cómo ver archivos ocultos en Windows?
• Comando: git status
• Repaso del ciclo de vida del estado de tus archivos (untracked, tracked, stage)
• Comando: git add .
• Áreas de trabajo en Git (Workspace, Index)
• Comando: git restore .

Preparando el área de trabajo

Abra su explorador de archivos y creen una carpeta en una ubicación de su preferencia, ponganle el nombre que guste, al final esa carpeta es solo para practicar los comandos que veremos hoy, así que el nombre es lo de menos; en la carpeta cree tres archivos txt, el primer concepto que se abordó en la primera lección era el comando “git init”, este es el primer paso para empezar a usar git, porque convierte nuestra carpeta en un repositorio, para ejecutarlo puedes abrir tu cmd y caminar hasta la ubicación de tu carpeta, o mas facil click derecho “git bash here”, como se ve en la imagen, esa es la forma de darse cuenta que tu instalación a ido bien, porque el git bash es el componente más importante que instalamos con git, entonces ya en la consola, escribimos “git init” y lo primero que salta a la vista es master, en la línea siguiente, esa es la ayuda visual que nos da el git bash para que sepamos en qué rama estamos, ¿recuerdan las ramas? puedes crear las que quieras, pero siempre empiezas en master, es tu rama inicial, por ahora no cambiaremos ni crearemos ramas nuevas, pero es bueno que lo vayan notando, aparte de eso nada mas paso, o eso parece.

¿Cómo ver archivos ocultos en Windows?

En tu explorador de archivos puedes activar una configuración para poder ver archivos ocultos, (la de la imagen) al hacerlo notarás una carpeta transparente, esta se crea junto con el comando git init, antes de ejecutar el comando no existía tal carpeta, esta carpeta es usada por git, para trabajar internamente, no debes borrarla ni interactuar con ella a menos que estés seguro de lo que haces, entonces ahora, después del git init, ya podemos usar comandos git para manejar nuestro repositorio a gusto. 

Comando: git status

En la consola del git bash digite “git status”, este comando te dice en que rama estas (master) ademas de mostrarte el mensaje de: “no hay commits aun” eso es correcto, no tienes commits aun, pero ya llegaras a tenerlos; ahora “archivos sin seguimiento” es decir archivos sin traquear, y ahí están nuestros tres archivos; fijense que el propio git ya nos dice que tenemos que agregar esos contenidos “usa git add para incluirlos en lo que será un commit” y efectivamente antes del comit, tienes que empezar a traquear tus archivos.

Repaso del ciclo de vida del estado de tus archivos (untracked, tracked, stage)

Recordemos un poco lo visto en la lección uno, el comando git add le permite a git empezar a darle seguimiento a los archivos que especifiques, puedes ejecutar el comando add, uno por uno, o simplemente con un punto, agregarlos todos de golpe, pero lo importante de esto es entender que una vez  traqueados, tus archivos podrán estar en 3 estados diferentes: sin modificaciones, con modificaciones o en stage (el siglo de vida de tus archivos en git), ahora estamos en “untraked” pero luego de hacer el add, pasaremos a estar en “stage”, ¿y por qué nos saltamos unmodified y modified? bueno no es que te los saltes, porque el grafico no va de ir primero este luego este, luego este, sino que es por estados, al ejecutar el git add, pasas a stage si o si, no importa si el archivo no estaba traqueado, ya que de paso empiezas a traquearlo, y si ya estaba traqueado, pues solo mandas a stage, lo diferente es que en un primer momento git no tiene con qué comparar para saber si hubo una modificación o no, luego de ese primer git add, ahora si ya se puede saber si hubo o no cambios.

Comando: git add .

En consola digite: “git add .” y usemos el comando recién aprendido: “git status” para saber que paso, todo se ve color verde claro, eso significa que está bien, cuando sale rojo es que hay acciones por ejecutar, pero aun asi no se fíen por colores, hay que leer, vemos como hace un momento pone, “en la rama master y sin commits”, ya lo habíamos visto en el anterior git status, pero esto es nuevo “cambios para confirmar” o mejor “cambios listos para ser un commit” (comúnmente se traduce commit como confirmación) y ese mensaje nos lista los archivos o los cambios que ya están listos para el commit, es decir todo lo que está en stage, el estado de nuestros archivos ahora es ese “en stage”. Fijense que también pone “new file” porque al ser este el primer git add, estamos empezando recién a darle seguimiento a nuestros archivos, antes no había una primera versión con la cual git compare para saber si hubo o no modificaciones, ahora ya lo hay, hay 3 archivos, A, B y C que a partir de ahora git sabrá si tienen cambios o no, justamente porque ya los estamos traqueando, eso ocurre con el primer git add, los siguientes git add ya notarán que nos avisaran solo de cambios en nuestro archivos, a menos que creemos uno nuevo.

Áreas de trabajo en Git (Workspace, Index)

Regrese al explorador, y edite sus ficheros con un párrafo entero de lorem ipsum (texto de ejemplo) y revise de nuevo ese git status, fijense que pone lo mismo que antes hay archivos listos para ser un commit, pero también que hay modificaciones, y lo que se explico hace un momento, en vez de new file, tenemos “modified” porque git ya tenía en stage los archivos en un estado, (vacíos sin el parrafo) pero con el lorem ipsum git noto el cambio y te esta avisando básicamente para que le digas que hacer con ese cambio, puedes volver a hacer git add, para actualizar el stage con esos lorem ipsum o usar git restore para descartar los cambios en tu directorio de trabajo; y aquí es momento de detenerse porque quiero hablar de las áreas de trabajo en git, observen un momento este sitio web que encontramos en las referencias de la documentación de git, el sitio es una ayuda para saber como git maneja tus archivos con cada comando, por ejemplo al hacer el git add pasamos del workspace al index, y ¿qué es esto del workspace, del index? lo explico con un ejemplo, A, B y C esta en nuestro workspace, o nuestro directorio de trabajo (la carpeta) al hacer el git add pasan al index que no es más que otra forma de llamar al stage, ojo no es que se cree una copia en otra carpeta con nombre index, estas áreas de trabajo las maneja git internamente, es más como que A, B y C están haciendo un paso lógico al stage o index, físicamente todo sigue en tu workspace. Entonces lo normal sería, pasar al repositorio local, con un commit, pero en lugar de eso, editamos los archivos con lorem ipsum y por tanto index y workspace no coinciden. Les comento todo esto por el mensaje que tenemos en nuestro último git status, esto que ponía: “usar git restore para descartar los cambios en tu directorio de trabajo” ese directorio de trabajo es nuestro workspace git status te dice que tu index y tu workspace no coinciden, si quieres que coincidan usa git restore, si lo usamos entonces nuestros archivos volverían a como estaban en el index, (vacíos) ¿significa eso que todo ese avance se perdería? (el párrafo) 

Comando: git restore .

En la consola escriban: “git restore .” y veamos el estado con git status y miren volvimos a como estábamos antes de poner los lorem ipsum, ¿qué significa? que todo lo avanzado se perdió, si revisas tus archivos no queda ni rastro del párrafo de lorem ipsum. Les muestro esto para que entiendan, el poder que tiene git como herramienta de control de versiones, tal cual no podemos recuperar los escrito en los archivos porque restauramos su estado anterior, con el git restore; por cierto, git restore tiene más subcomandos (opciones) que pueden revisar, no solo puedes restaurar del workspace al index, pero eso te lo dejo de tarea; ya para terminar hagamos que los archivos se conviertan en un commit, para eso: git commit -m “archivos vacios” ¿por que ese mensaje? porque los archivos pues están vacíos no tienen nada, más adelante volveremos a toparnos con este commit. Por ahora eso es todo, practiquen hagan su primer commit y vean el resto de lecciones.