Commits y Pushes: Guardando y Sincronizando tu Progreso.
Imagina que estás jugando un videojuego largo y complejo. ¿Qué haces antes de enfrentar a un jefe final? ¡Guardas la partida! Si algo sale mal, puedes volver a ese punto exacto y reintentarlo. Git funciona con esta misma idea. Cada vez que haces un commit, estás creando un "punto de guardado" (snapshot) de tu proyecto.
Esta "máquina del tiempo" es la habilidad más importante que Git nos ofrece. Nos libera del miedo a experimentar, porque siempre podemos volver a una versión anterior que sabíamos que funcionaba. Olvídate de los archivos analisis_final.R, analisis_final_v2.R y analisis_final_AHORA_SI.R. Con Git, tienes un historial limpio y profesional de cada cambio.
El flujo de trabajo básico que realizarás decenas de veces al día se resume en tres comandos. Piénsalo como el proceso de tomar una foto y subirla a un álbum en la nube.
La Analogía: Elegir qué cosas incluirás en la foto.
La Realidad: Le dices a Git qué archivos específicos, que has creado o modificado, quieres incluir en tu próximo "punto de guardado". A esta zona de preparación se le llama "Staging Area".
La Analogía: Tomar la foto y escribir una descripción en la parte de atrás.
La Realidad: Creas el "punto de guardado" permanente en tu máquina local. Cada commit debe ir acompañado de un mensaje (-m) que describa claramente qué cambiaste. Ej: "Se añade gráfico de dispersión".
La Analogía: Subir tu foto al álbum compartido en la nube (GitHub).
La Realidad: Sincronizas los commits que tienes en tu máquina local con el repositorio remoto en GitHub, para que tu equipo pueda ver tus cambios y tengas una copia de seguridad.
Vamos a poner en práctica el ritmo de tres pasos. Usaremos el proyecto que ya clonamos en el módulo anterior.
Abre tu proyecto en RStudio o VS Code. Busca el archivo README.md y añade una nueva línea de texto. Por ejemplo: "Este proyecto contendrá un dashboard para el análisis de los resultados de las pruebas Saber 11." Guarda el archivo.
En la pestaña "Git" de RStudio o en "Source Control" de VS Code, verás que el archivo README.md aparece como modificado.
Abre una terminal en la carpeta de tu proyecto. Si usas RStudio, puedes ir a Tools > Shell....
# PASO 1: ADD
# Le decimos a Git que incluya el README.md en la "foto".
# El punto (.) es un atajo para añadir todos los archivos modificados.
git add .
# PASO 2: COMMIT
# Tomamos la "foto" con un mensaje descriptivo.
git commit -m "docs: Se actualiza la descripción del proyecto en el README"
¡Listo! Has creado tu primer "punto de guardado" en tu repositorio local. En este momento, GitHub todavía no sabe nada de este cambio.
Ahora, vamos a compartir nuestro trabajo con el mundo (o al menos, con nuestro repositorio en GitHub).
# PASO 3: PUSH
# Sube tus commits de la rama 'main' al repositorio remoto llamado 'origin'
git push origin mainAhora, si vas a tu repositorio en GitHub y refrescas la página, verás que el archivo README.md contiene los cambios que acabas de hacer.
Ya dominas el ciclo fundamental. Pero, ¿qué pasa si quieres probar una idea nueva y radical sin arriesgar el trabajo que ya funciona? En lugar de hacer una copia de tu carpeta (mi-proyecto-copia), Git te ofrece una solución mucho más elegante: las ramas (branches).
Una rama es simplemente una línea de desarrollo independiente. Puedes crear una nueva rama para trabajar en una nueva funcionalidad, y si la idea no funciona, simplemente la desechas. Si funciona, la integras de nuevo a tu rama principal main.
# Para crear una nueva rama llamada "experimento"
git branch experimento
# Para moverte a esa nueva rama y empezar a trabajar en ella
git checkout experimento
No te preocupes por dominar esto ahora. Lo importante es saber que existen. En módulos más avanzados, aprenderemos a usarlas para colaborar en equipo de forma profesional. Por ahora, sigue practicando el ritmo de add, commit y push en la rama main.