Fundamentos de Git

Un historial al que puedes volver

Git registra el historial de un proyecto como una serie de commits: instantáneas de todos los archivos seguidos, cada una con autor, hora y mensaje. Con él puedes ver qué cambió y por qué, probar una idea sin miedo y volver a una versión que funcionaba. Una carpeta bajo control de Git es un repositorio. El trabajo cuantitativo depende mucho de esto: un resultado solo es fiable si puedes decir exactamente qué versión del código lo produjo.

# Start tracking a project (once)
git init

# See what changed, stage it, record it
git status
git add main.py README.md
git commit -m "Add the first backtest loop"

# Look back
git log --oneline
git diff                      # changes not yet staged

Los tres lugares donde vive un cambio

Un cambio pasa por tres áreas. Editas archivos en el directorio de trabajo. git add copia los cambios elegidos al área de preparación (la siguiente instantánea, en preparación). git commit registra la instantánea preparada en el historial del repositorio. Así puedes confirmar juntos solo los cambios relacionados, aunque hayas editado muchos archivos. git status muestra cada archivo en su área: modificado, preparado o sin seguimiento (nuevo y aún desconocido para Git).

# git status --porcelain prints two status letters, a space, then the path
status = """ M main.py
A  notes.md
?? scratch.txt
D  old.py"""

for line in status.splitlines():
    code, path = line[:2], line[3:]
    print(repr(code), path)
# ' M' main.py     (modified, not staged)
# 'A ' notes.md    (new, staged)
# '??' scratch.txt (untracked)
# 'D ' old.py      (deleted, staged)

Ramas

Una rama es un nombre móvil para una línea de commits. Crea una por cada idea o arreglo (git switch -c fee-model), haz commits libremente y, cuando funcione, tráela a la línea principal con git merge (normalmente desde la rama main). Los nombres de rama pueden contener letras, dígitos, -, _, / y ., pero no espacios ni ninguno de ~ ^ : ? * [ \, y no pueden empezar ni terminar con / ni terminar con .. Git avisa de los conflictos cuando dos ramas cambiaron las mismas líneas, y los resuelves a mano.

# Try an idea on its own branch, then bring it back
git switch -c fee-model
git commit -am "Use tiered fees"
git switch main
git merge fee-model

# List branches (the current one has a star)
git branch

Qué dejar fuera y cómo deshacer

Un archivo .gitignore lista los patrones que Git no debe seguir: .venv/ (una carpeta, escrita con barra final), *.log (cualquier archivo que coincida con un comodín), secrets.env. Deja fuera los entornos virtuales, las cachés, los archivos de datos grandes y sobre todo los secretos como las claves de API: todo lo que se confirma queda en el historial aunque luego lo borres. Para deshacer, git restore archivo descarta las ediciones no confirmadas de un archivo, y git revert <commit> añade un commit nuevo que cancela uno antiguo, algo seguro en ramas compartidas. git push y git pull intercambian commits con una copia remota, por ejemplo en GitHub.

# .gitignore
.venv/
__pycache__/
*.log
secrets.env

# Undo safely
git restore main.py            # drop uncommitted edits to one file
git revert 3f2a9c1             # new commit that cancels an old one

# Share
git push origin main
git pull

• git init, git status, git add, git commit -m "...", git log --oneline.
• Una rama por idea: git switch -c nombre y luego git merge.
• Usa .gitignore para .venv/, cachés, datos y secretos; deshaz con restore o revert.

A continuación: cuadernos Jupyter, para explorar datos de forma interactiva y mantenerlos ordenados bajo Git.

Lab: qué se califica

• Clasificar los archivos de un informe git status con parse_status25 pts
• Leer un listado de git log --oneline con parse_log25 pts
• Comprobar un nombre de rama con las reglas de Git usando is_valid_branch_name25 pts
• Aplicar un .gitignore a una lista de archivos con not_ignored25 pts