12. Exposición sobre los comandos usados hasta el momento

 

 Exposición sobre los Comandos Fundamentales

Bienvenidos a esta exposición. Hoy vamos a repasar los comandos básicos de Git que hemos aprendido hasta ahora, pero en lugar de solo listarlos, vamos a entender cómo funcionan en conjunto dentro del flujo de trabajo diario. Para esto, nos ayudaremos de una analogía muy útil.

1. El Punto de Partida: git init

Primero lo primero. ¿Qué necesitamos para empezar a usar Git en un proyecto? Necesitamos inicializar un repositorio local.

El comando mágico es: git init.

¿Qué es lo que sirve? Sirve para crear ese repositorio local. Una vez ejecutado, este comando crea una carpeta oculta llamada .git. Imaginen esta carpeta como el "cuarto oscuro" o el "cerebro" de nuestro proyecto. Esta carpeta .git contiene la referencia a todo lo que nosotros vayamos a hacer. Es la que le permite a Git llevar un rastro detallado de todas las modificaciones, por pequeñas que sean. Sin ella, Git no existiría en nuestro proyecto.

2. El Flujo de Trabajo Diario

Ahora, una vez que tenemos nuestro repositorio listo, empecemos a trabajar. El flujo normal va a funcionar de la siguiente manera:

Paso 1: Crear o Modificar Archivos (El Área de Trabajo)

Digamos que llega Johnny, un desarrollador, y crea un archivo, en este caso index.html. Le pone todo su empeño y la página web queda súper bonita. En este punto, el archivo index.html existe en nuestra computadora, pero Git aún no le está prestanda atención a sus cambios. Está en lo que llamamos el Directorio de Trabajo.

Paso 2: Preparar los Cambios (git add al "Escenario")

El archivo ya está listo para ser parte del próximo registro histórico. Pero antes de hacer la foto oficial, tenemos que llevarlo al "escenario" o "stage". ¿Cómo lo hacemos? Con el comando:

git add index.html

Imagínense el Stage (o Área de Preparación) como el lugar donde se prepara la presentación. Es como un backstage. Lo que estamos diciendo con ese comando es: "OK, toma el archivo index.html y ponlo en el escenario para la foto".

Ahí, en el escenario, ustedes ya saben que mucha gente está lista con los celulares y las cámaras, esperando el momento perfecto para tomarle fotografías.

Paso 3: Tomar la Fotografía (git commit - el Snapshot)

Cuando nosotros queremos tomar esa fotografía oficial, o como le llamamos en Git, el snapshot, nosotros ejecutamos el comando:

git commit -m "Mensaje descriptivo de los cambios"

En ese momento, cuando usamos git commit, se crea un registro histórico permanente de los cambios que se dieron, pero ojo: solo de los archivos que estaban en el escenario en ese preciso momento. Esa instantánea queda guardada para siempre en nuestra carpeta .git.

3. El Detective de Git: git status

Ahora, ¿cómo sabemos qué está pasando en nuestro repositorio en todo momento? Para eso tenemos un comando muy útil:

git status

Si se acuerdan, cuando nosotros escribimos eso por primera vez, después de crear varios archivos, apareció todo en rojo. ¿Qué quiere decir eso?

Bueno, todos esos archivos que están en rojo nos indican que han sido modificados o creados, pero aún no han sido agregados al "escenario" (stage). En nuestro caso, como fue el primer status después de crearlos, por eso todos salían en rojo. Pero normalmente, git status nos va a mostrar en rojo todos los archivos que hayan sufrido cualquier modificación, por más mínima que sea, desde el último commit.

4. Un Flujo de Trabajo más Detallado

Vamos a verlo con un poco más de detalle. Cuando nosotros estamos trabajando, nuestro git status nos muestra nuestro directorio de trabajo y podemos ver los cambios.

Imaginemos que tenemos un repositorio con muchos archivos, pero ese día yo sólo modifiqué tres. Esos son los archivos que yo voy a querer mandar al stage. Entonces, en lugar de hacer git add . (que agrega todo), puedo seleccionar cuidadosamente:

git add archivo1.html archivo2.js

Con esto, Git extrae las modificaciones de esos dos archivos y las pone en el escenario. Si ejecuto git status de nuevo, veré esos archivos en verde, indicando que ya están en el stage, listos para el commit. El archivo que modifiqué pero no añadí (archivo3.css), seguirá apareciendo en rojo.

Aquí, antes de mandarlo al commit, yo puedo decir: "¿Saben qué? Este archivo archivo2.js no lo voy a incluir en esta versión" y lo puedo quitar del stage con git restore --staged archivo2.js.

Una vez que ustedes ya están satisfechos con los archivos que van a mandar al commit (es decir, los que están en verde), ejecutamos:

git commit -m "Se añade la nueva funcionalidad X"

Al hacer eso, Git agarra todo lo que esté en el stage, crea el registro histórico (un snapshot con un ID único) y ya podremos, en un futuro, volver en el tiempo a este punto o tener un respaldo seguro de nuestros archivos en este estado exacto.

5. Resumen del Flujo del Día a Día

En el día a día, tendríamos un flujo muy parecido a este:

1. Creamos o modificamos archivos en nuestro proyecto.

2. Ejecutamos git add <archivo(s)> para mandar los cambios que queremos al stage.

3. Ejecutamos git commit -m "mensaje" para tomar el snapshot y guardar el registro histórico.

¡Y eso sería básicamente todo el trabajo del día a día con Git en su nivel más fundamental!

---

Cuestionario de Repaso

Para asegurarnos de que los conceptos han quedado claros, respondamos las siguientes preguntas:

1. ¿Cuál es el comando y el propósito de git init?
   a) Sirve para ver el historial de cambios.
   b) Sirve para crear un repositorio local y la carpeta .git.
   c) Sirve para preparar archivos para el commit.

2. En la analogía de la exposición, ¿qué representa el "stage" o "escenario" y con qué comando enviamos archivos allí?
   a) Representa el repositorio remoto en GitHub. Se envía con git commit.
   b) Representa el área de preparación para la foto. Se envía con git status.
   c) Representa el área de preparación para el snapshot. Se envía con git add.

3. ¿Qué acción realiza exactamente el comando git commit?
   a) Guarda los cambios directamente en el disco duro.
   b) Crea un registro histórico (un snapshot) de los archivos que están en el stage.
   c) Muestra las diferencias entre los archivos modificados.

4. Si ejecutas git status y ves unos archivos en rojo y otros en verde, ¿qué significa?
   a) Los rojos son los que están listos para el commit, los verdes son los que no se van a guardar.
   b) Los rojos indican archivos con errores, los verdes indican archivos correctos.
   c) Los rojos son archivos modificados pero no añadidos al stage, los verdes son los que ya están en el stage.

5. ¿Cuál es el flujo de trabajo correcto y más común para guardar los cambios de un archivo en Git?
   a) git commit -> git add -> Modificar archivo.
   b) Modificar archivo -> git add -> git commit.
   c) git status -> git commit -> Modificar archivo.

---

Respuestas:

1. b) Sirve para crear un repositorio local y la carpeta .git.

2. c) Representa el área de preparación para el snapshot. Se envía con git add.

3. b) Crea un registro histórico (un snapshot) de los archivos que están en el stage.

4. c) Los rojos son archivos modificados pero no añadidos al stage, los verdes son los que ya están en el stage.

5. b) Modificar archivo -> git add -> git commit.