Ciclo Profesional de Trabajo con Git y GitHub

En este tema profundizamos en la práctica profesional del flujo de trabajo con Git.
Nuestro objetivo es comprender cómo versionar código de manera disciplinada, tal como se hace en proyectos reales.

Commit

¿Qué es un commit?

Un commit es una fotografía del proyecto en un momento específico.
Cada vez que haces un commit, le dices a Git:

“Aquí tengo un conjunto de cambios coherentes y quiero guardarlos en el historial”.

Es la unidad fundamental del versionamiento.

¿Qué hace que un commit sea bueno?

Un commit profesional debe ser:

Pequeño: un único propósito.
Coherente: cambios relacionados entre sí.
Frecuente: no esperar horas o días para registrar progreso.

Un commit no debe mezclar:

código + gráficos + limpieza + cambios masivos del YAML.
Cada tarea debe tener su propio commit.

Cómo escribir mensajes de commit profesionales

Un buen mensaje responde:

¿Qué cambiaste? y ¿Por qué?

Ejemplos claros:

Corrijo error en el cálculo del promedio (chunk 03)
Agrego visualización con ggplot para variable precio
Actualizo README con instrucciones de instalación
Refactorizo función get_data()

Evitar mensajes como:

“arreglo cosas”
“último intento”
“ya quedó”
“update”

Ejemplo práctico

Modifica un archivo:

# archivo: analisis.R
x <- rnorm(100)
mean(x)

Luego:

git add analisis.R
git commit -m "Agrego análisis inicial de promedio muestral"

Git deja tu proyecto con un punto seguro al que puedes volver.

Push y Pull

¿Qué es push?

Cuando haces commits en tu computador, esos cambios solo existen en tu repositorio local.

Para compartirlos con tus compañeros o simplemente respaldarlos en GitHub, necesitas enviarlos al remoto.

Eso se hace con:

git push

push = enviar tus cambios al repositorio remoto.

Sube únicamente los commits registrados; si no has hecho commit, no hay nada que enviar. Es la manera profesional de mantener el proyecto actualizado y disponible para el equipo.

¿Qué es pull?

Mientras tú trabajas localmente, el repositorio remoto puede cambiar porque:

tus compañeros enviaron nuevos commits,
actualizaste algo desde otra máquina,
hiciste un merge en GitHub,
o realizaste ediciones desde GitHub directamente.

Para que tu copia local esté alineada con la versión más reciente, usas:

git pull

pull = traer e integrar en tu computador las actualizaciones del remoto.

Si no haces pull con frecuencia, aumentan las probabilidades de conflictos.

Regla de oro en equipos

Siempre hacer git pull ANTES de empezar a trabajar.

Siempre hacer git push DESPUÉS de terminar.

Esto garantiza sincronización constante, evita conflictos y mantiene el proyecto ordenado.

Una forma de recordarlo:

Momento	Comando	¿Por qué?
Antes de trabajar	`git pull`	Aseguras que tu copia esté actualizada.
Después de trabajar	`git push`	Compartes tu progreso y lo respaldas.

Flujo profesional recomendado

Sincronizar

git pull

Trabajar (editar scripts, agregar funciones, análisis, etc.)
Registrar cambios en el índice

git add archivo.R

Crear un commit claro y coherente

git commit -m "Mensaje preciso sobre lo que cambió"

Enviar los commits al remoto

git push

Este ciclo se repite varias veces al día en proyectos profesionales.

Ejemplo con un archivo `.R`

Supongamos que modificas el archivo modelos/modelo_car.R para mejorar una función.

El flujo sería:

git pull
git add modelos/modelo_car.R
git commit -m "Implemento función para ajustar modelo CAR con validación"
git push

Resultado:

Tu repositorio local queda limpio y organizado.
GitHub queda con la versión más reciente.
Tus compañeros podrán hacer pull y continuar sin conflicto.

Ramas (branches)

1. ¿Qué es una rama y por qué la necesitamos?

En Git, una rama es una línea de trabajo independiente dentro del mismo proyecto. Permite crear un espacio seguro para desarrollar ideas, probar cambios o corregir errores sin afectar la versión principal del código.

Podemos pensar la rama principal main como la versión limpia y estable del proyecto. A partir de ella podemos crear ramas secundarias donde trabajamos sin riesgo.

Usamos ramas para:

experimentar sin modificar el código estable,
desarrollar tareas específicas en paralelo,
evitar conflictos cuando hay varias personas trabajando,
tener un historial claro de qué se hizo y por qué,
poder descartar una idea sin afectar el proyecto completo.

En síntesis: una rama = un experimento o un conjunto coherente de cambios.

2. Crear una nueva rama

Para iniciar un trabajo o experimento, creamos una rama a partir de main.

Forma clásica:

git branch analisis-poisson

Esto solo crea la rama; aún no te mueves hacia ella. Lo habitual es crearla y cambiarte de inmediato:

git checkout -b analisis-poisson

En ese momento ya estás “dentro” de la nueva rama y todo lo que programes quedará asociado a ella.

3. Cambiar de una rama a otra

Si necesitas volver a main:

git checkout main

Y si quieres regresar a la rama nueva:

git checkout analisis-poisson

Recuerda: Git solo te dejará cambiar de rama si no tienes cambios sin guardar. En caso contrario, primero debes hacer:

git add .
git commit -m "Guardo progreso antes de cambiar de rama"

4. Integrar los cambios de una rama en `main`

Cuando terminas tu trabajo en la rama y quieres que pase a formar parte del proyecto principal, debes fusionarla (hacer un merge).

Flujo recomendado:

Ir a main
```
git checkout main
```
Traer los cambios más recientes del repositorio remoto (para evitar conflictos innecesarios):
```
git pull
```
Fusionar tu rama con el trabajo finalizado
```
git merge analisis-poisson
```

Después de esto, los cambios ya forman parte de main.

5. Eliminar una rama que ya no se necesita

Una vez que una rama cumplió su función (ya fusionaste su contenido), puedes eliminarla:

git branch -d analisis-poisson

Esto mantiene tu repositorio limpio y evita acumulación de ramas viejas.

Resolver conflictos

¿Por qué ocurren?

Un conflicto aparece cuando dos personas modifican la misma parte del mismo archivo. Git no puede decidir cuál versión conservar y te pide ayuda.

Cómo se ven en un archivo

Aparecen así:

<<<<<<< HEAD
promedio <- mean(x)
=======
promedio <- sum(x)/length(x)
>>>>>>> rama-estudiante

Git te muestra dos versiones. Debes elegir una o combinarlas.

Cómo resolverlos

Editas el archivo y escoges la versión correcta.
Eliminas las marcas:

<<<<<<<
=======
>>>>>>>

Luego:

git add archivo_conflictivo.R
git commit -m "Resuelvo conflicto en cálculo de promedio"

Buenas prácticas para evitarlos

Hacer git pull antes de trabajar.
Evitar modificar el mismo archivo entre varias personas.
Usar ramas para cada tarea.
Hacer commits pequeños y frecuentes.

Reglas profesionales esenciales

No subir datos pesados: usar .gitignore
No subir .Rhistory ni .Rproj.user
README siempre actualizado
Commits pequeños, claros, frecuentes
Ramas para experimentos o correcciones
Nombres claros de archivos (analisis_eda.R, modelo_car.R)
Scripts bien documentados
Comentarios útiles, no decorativos