Sesión 3 · Guardar la historia del proyecto

Git, GitHub y proyecto final ENSO–Baja

Posgrado en Oceanografía Física · CICESE

2026-09-01

Dónde vamos

Recordatorio de la historia

Marina ya tiene:

enso_baja/
├── data/
├── notebooks/
│   └── 01_explora_datos.ipynb
├── scripts/
│   └── plot_sst_timeseries.py
├── figures/
│   └── ssta_baja_timeseries.png
├── README.md
└── environment.yml

Hoy quiere evitar esto:

analisis.ipynb
analisis_final.ipynb
analisis_final_ahora_si.ipynb
analisis_final_corregido_2.ipynb

Pregunta guía

¿Cómo guardamos la historia de un análisis sin duplicar archivos ni perder versiones?

Hoy usaremos Git para:

• registrar cambios;
• recuperar versiones;
• ignorar archivos que no deben subirse;
• respaldar el proyecto en GitHub;
• preparar el proyecto final.

Git no es GitHub

Git

Sistema de control de versiones.

Vive en tu computadora.

Registra la historia del proyecto.

GitHub

Plataforma en línea.

Hospeda repositorios.

Facilita respaldo y colaboración.

Configurar Git

Una sola vez por computadora

git config --global user.name "Tu Nombre"
git config --global user.email "tu_correo@ejemplo.edu"
git config --global init.defaultBranch main

Revisar:

git config --list --global

No dedicar demasiado tiempo a configuración. Si algo falla, resolver caso por caso.

El ciclo básico

working directory
      ↓ git add
staging area
      ↓ git commit
repository
      ↓ git push
GitHub

Hoy repetiremos este ciclo varias veces.

No basta con hacer un solo commit al final.

Crear el repositorio

Entrar al proyecto

Desde la terminal:

cd enso_baja
pwd
ls -F

Inicializar Git:

git init

Revisar:

git status

¿Qué ve Git?

git status nos dice:

• si estamos en un repositorio;
• qué archivos cambiaron;
• qué archivos todavía no están registrados;
• qué archivos están listos para commit.

Regla de oro:

git status

antes y después de cada paso.

Primer commit: estructura del proyecto

Agregar archivos pequeños y esenciales:

git add README.md environment.yml

Revisar:

git status

Guardar:

git commit -m "Create ENSO Baja project structure"

Reto 1 · ¿Qué pasó?

Ejecuta:

git status
git log --oneline

Responde:

1. ¿hay cambios pendientes?
2. ¿cuántos commits hay?
3. ¿qué mensaje tiene el commit?

Agregar análisis

Segundo commit: notebook y script

Agregar el análisis exploratorio:

git add notebooks/01_explora_datos.ipynb

Agregar el script:

git add scripts/plot_sst_timeseries.py

Guardar:

git commit -m "Add initial SST analysis"

Ver la historia

git log --oneline

Ahora el proyecto tiene memoria.

Cada commit debe representar una unidad de trabajo con sentido.

Cambiar algo

Edita el título de la figura en:

scripts/plot_sst_timeseries.py

Por ejemplo cambia:

ax.set_title("Anomalía de SST frente a Baja California")

por algo más específico.

Ver diferencias

git status
git diff

git diff muestra qué cambió línea por línea.

Esto es una de las razones principales para usar archivos de texto como scripts.

Tercer commit

Si el cambio nos gusta:

git add scripts/plot_sst_timeseries.py
git commit -m "Improve SST anomaly figure title"

Revisar:

git log --oneline

Reto 2 · Commit pequeño

Haz un cambio pequeño en el README:

• agrega una frase sobre la pregunta científica del proyecto;
• revisa git diff;
• haz commit.

Mensaje sugerido:

git commit -m "Describe project question in README"

No todo va a Git

El problema

Si hacemos:

git add .

podríamos intentar agregar:

data/
figures/
.ipynb_checkpoints/
__pycache__/
.DS_Store

Pero no todo debe estar en Git.

¿Qué sí y qué no?

Archivo	¿Git?	Razón
README.md	sí	explica el proyecto
environment.yml	sí	permite recrear el ambiente
scripts .py	sí	reproducen el análisis
notebooks .ipynb	sí	documentan exploración
datos grandes .nc	no	pesan mucho; pueden tener restricciones
figuras regenerables	depende	si se generan con código, no siempre hace falta
tokens/contraseñas	jamás	riesgo de seguridad

Crear .gitignore

Crear un archivo llamado:

.gitignore

con:

data/
figures/
.ipynb_checkpoints/
__pycache__/
.DS_Store

Agregarlo:

git add .gitignore
git commit -m "Ignore data and generated files"

Reto 3 · Verificar .gitignore

Ejecuta:

git status

Pregunta:

¿Aparecen los archivos de data/ como pendientes?

Si aparecen, algo está mal en .gitignore o ya habían sido agregados antes.

Deshacer con cuidado

Antes de commit

Si modificaste un archivo y quieres descartar el cambio:

git restore archivo

Ejemplo:

git restore README.md

Cuidado: esto elimina cambios no guardados en Git.

Después de commit

Para este curso basta saber:

• git log muestra la historia;
• cada commit es un punto al que podemos referirnos;
• no tenemos que duplicar archivos para conservar versiones.

No entraremos a rebase ni historia avanzada.

GitHub

Crear repositorio remoto

En GitHub:

1. crear repositorio nuevo;
2. no agregar README desde GitHub si ya existe localmente;
3. copiar la URL del repositorio.

Después en terminal:

git remote add origin URL_DEL_REPOSITORIO
git push -u origin main

Revisar en GitHub

Deberían verse:

README.md
environment.yml
notebooks/
scripts/
.gitignore

No deberían verse:

data/

Reto 4 · Modificar y subir

1. Haz un cambio pequeño en README.md.
2. Revisa:

git diff

3. Haz commit.
4. Sube a GitHub:

git push

5. Verifica el cambio en el navegador.

Proyecto final

La tarea

Usando los datos del proyecto:

• SST frente a Baja California;
• precipitación en Ensenada;
• ONI;

cada persona o pareja debe construir un notebook final.

Pregunta general:

¿Qué relación interesante puedes mostrar entre ENSO, SST regional y precipitación local?

Reglas del proyecto

El notebook debe incluir:

1. una pregunta clara;
2. descripción breve de los datos usados;
3. una o dos figuras;
4. interpretación corta;
5. código que corra de principio a fin.

No tiene que ser perfecto.

Sí tiene que ser entendible.

Preguntas posibles

Puedes elegir una o inventar otra:

• ¿La SST regional tiende a ser más cálida durante eventos El Niño?
• ¿Los años El Niño son más lluviosos en Ensenada?
• ¿Hay desfase entre ONI y SSTA de Baja California?
• ¿La relación cambia entre eventos?
• ¿La precipitación parece más ruidosa que la SST?
• ¿Hay años que contradicen la expectativa inicial?

Producto esperado

enso_baja/
├── notebooks/
│   └── proyecto_final.ipynb
├── scripts/
├── figures/
├── README.md
├── .gitignore
└── environment.yml

El repositorio debe estar en GitHub.

Commits esperados

No hacer un solo commit al final.

Ejemplos de commits útiles:

Load SST and ONI data
Calculate SST anomalies
Compare ONI and precipitation
Add final interpretation
Clean notebook for submission

Mínimo sugerido: tres commits con sentido.

README del proyecto final

El README puede ser breve:

# Proyecto ENSO–Baja

Este repositorio contiene un análisis exploratorio de SST frente a Baja California,
precipitación en Ensenada e índice ONI.

## Pregunta

...

## Datos

...

## Cómo correr el análisis

Abrir `notebooks/proyecto_final.ipynb`.

Cierre

Lo que ya saben hacer

En tres sesiones practicamos:

terminal
  ↓
proyecto organizado
  ↓
Python / xarray / pandas
  ↓
figuras
  ↓
Git
  ↓
GitHub

Éste es un flujo de trabajo básico para empezar investigación computacional.

Para la sesión 4 opcional

Traeremos:

• notebook final;
• repositorio en GitHub;
• una figura que quieran discutir;
• un problema que no hayan podido resolver.

La sesión 4 será clínica + presentaciones relámpago.

Última idea

El objetivo no es que el análisis sea definitivo.

El objetivo es que el análisis sea:

• claro;
• repetible;
• compartible;
• mejorable.

Eso es programación científica.