Git y GitHub¶

Git guarda el historial de cambios en tu equipo. GitHub aloja copias remotas de repositorios Git y añade colaboración, pull requests, incidencias, Codespaces y automatizaciones. No son la misma herramienta: puedes usar Git sin GitHub, aunque en este curso usaremos ambos.

Qué aprenderás¶

Al terminar esta guía podrás:

• reconocer el estado de un archivo y consultar qué ha cambiado;
• preparar cambios, guardarlos en commits y revisar el historial;
• clonar un repositorio y sincronizarlo con GitHub;
• trabajar en una rama y abrir una pull request;
• evitar subir entornos virtuales, cachés, metadatos y secretos.

La evidencia mínima de logro es poder explicar qué ocurre en cada paso de este flujo:

archivos -> git add -> staging -> git commit -> historial local -> git push -> GitHub
GitHub -> git pull -> archivos e historial local

El viaje de un cambio. Cada flecha del dibujo es un comando: add elige qué entra, commit guarda el hito, push lo publica y pull trae lo nuevo. La fila de círculos del historial es la cadena de commits: instantáneas encadenadas que solo salen de tu equipo cuando las publicas.

Vocabulario esencial¶

Un commit no sube nada a GitHub: guarda un hito en el repositorio local. git push publica commits locales en un remoto y git pull trae cambios del remoto e intenta integrarlos en tu rama.

Instalación y configuración¶

Git se instala una sola vez por equipo. GitHub no se instala: es un servicio web. Crea una cuenta gratuita en github.com si aún no la tienes; en VS Code iniciarás sesión con ella cuando el editor lo solicite.

sudo apt install git

xcode-select --install

winget install Git.Git

Comprueba la instalación:

git --version

Salida esperada: una línea como git version 2.43.0. El número depende de la versión instalada. En Windows, si el comando no aparece, cierra y vuelve a abrir la terminal después de instalar.

Configura la identidad que Git escribirá en tus commits:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

Comprueba los valores guardados:

git config --get user.name
git config --get user.email

El correo debe ser uno que reconozcas en GitHub, o el correo privado que GitHub te proporcione. Esta configuración identifica los commits; no autentica el acceso a GitHub.

Crear o clonar un repositorio¶

Proyecto local nuevo¶

Si la carpeta todavía no es un repositorio:

git init
git status

Efecto observable: Git muestra la rama actual y los archivos no seguidos o modificados. Aparece una carpeta oculta .git/; no debes editarla ni subir su contenido por separado.

Si el proyecto usa uv, prepara después sus dependencias con uv sync. Consulta la guía de uv para distinguir pyproject.toml, uv.lock y .venv.

Repositorio que ya existe en GitHub¶

Clona el repositorio y entra en la carpeta creada:

git clone https://github.com/usuario/repo.git
cd repo
git status

Si es un proyecto Python gestionado por uv, ejecuta después uv sync --locked antes de abrir cuadernos o scripts. No hagas git init después de clonar: la carpeta ya contiene su historial y su remoto.

El ciclo local: revisar, preparar y guardar¶

Consultar cambios¶

git status
git diff
git diff --staged

git status resume el estado; git diff muestra cambios todavía no preparados y git diff --staged muestra lo que ya está preparado para el próximo commit. La salida depende de lo que hayas editado, por lo que el resultado importante es identificar cada archivo como modificado, no seguido o preparado.

Crear un commit¶

Cada línea siguiente representa un paso consciente:

git add archivo.py
git diff --staged
git commit -m "Describe el cambio"
git log --oneline -5

• git add lleva una versión concreta del cambio al staging;
• revisar git diff --staged evita guardar accidentalmente otro archivo;
• git commit crea un hito local;
• git log --oneline -5 permite comprobar que el hito aparece en el historial.

Escribe mensajes breves y concretos, por ejemplo Explica validación cruzada. Un commit debería representar una unidad que se pueda revisar o recuperar.

Quitar algo del staging o descartar cambios¶

Si preparaste un archivo por error, puedes devolverlo al estado no preparado:

git restore --staged archivo.py

git restore archivo.py descarta los cambios no guardados de ese archivo. Es una operación destructiva: úsala solo después de comprobar git diff y cuando estés seguro de que no necesitas recuperar esas modificaciones.

.gitignore: qué no debe entrar en el repositorio¶

.gitignore contiene patrones para archivos locales, generados o sensibles que Git no debe proponer para seguimiento. uv init crea uno básico; para los proyectos del curso conviene que incluya al menos esto:

# Código compilado por Python
__pycache__/
*.py[oc]

# Entorno virtual: se recrea con uv sync
.venv/

# Sesiones y cachés de marimo
__marimo__/

# Secretos (claves de API); la plantilla sin valores sí se versiona
.env
.env.*
!.env.example

Cada línea es un patrón: una carpeta termina en /, * significa «cualquier texto» y ! crea una excepción a un patrón anterior. No ignores el código, pyproject.toml, uv.lock ni .python-version: son parte de la información necesaria para reproducir el entorno. .venv se recrea con uv sync.

Trabajar con GitHub¶

Consulta el remoto antes de sincronizar:

git remote -v
git branch --show-current

Para conectar un repositorio local que todavía no tiene remoto:

git remote add origin https://github.com/usuario/repo.git
git push -u origin NOMBRE_DE_LA_RAMA

-u asocia la rama local con su rama remota; en los siguientes envíos suele bastar git push. Usa la URL real del repositorio y el nombre que muestre git branch --show-current.

El ciclo habitual después de tener commits:

git pull
git push

Antes de git pull, confirma tus cambios locales en un commit o descártalos. Si el remoto ha avanzado y tienes cambios sin publicar, Git puede pedirte que resuelvas una integración. No fuerces git push para ocultar el problema.

Ramas y pull requests¶

La rama principal suele llamarse main, aunque en repositorios antiguos es frecuente master. No adivines el nombre: compruébalo con git branch o en GitHub.

Una rama (tema) parte de main, avanza con sus propios commits y se integra con un merge después de que la pull request haya pasado revisión. Así el trabajo aislado no toca la rama principal hasta que está listo y revisado.

Para trabajar en una tarea aislada:

git switch -c tema
git branch --show-current
git add archivo.py
git commit -m "Implementa el tema"
git push -u origin tema

Después, abre en GitHub una pull request desde tema hacia la rama principal. La revisión permite discutir el cambio antes de integrarlo. Cuando termine el trabajo, actualiza tu copia local y cambia de rama:

git switch NOMBRE_DE_LA_RAMA_PRINCIPAL
git pull

Resolver un conflicto¶

Un conflicto aparece cuando Git no puede elegir automáticamente entre dos versiones. El procedimiento básico es:

1. Ejecuta git status para localizar los archivos afectados.
2. Abre cada archivo y decide qué contenido debe conservarse entre los marcadores <<<<<<<, ======= y >>>>>>>.
3. Elimina los marcadores, guarda el archivo y comprueba que el código sigue funcionando.
4. Ejecuta git add archivo y termina la integración con el comando que Git indique.

No borres los marcadores sin revisar el código: resolver un conflicto es una decisión sobre contenido, no solo una operación mecánica.

GitHub, Codespaces y Actions¶

GitHub es un servicio con tres piezas que conviene no confundir: una es obligatoria para este curso y las otras dos son opcionales.

Repositorio. Es lo que se usa en el curso: git, las ramas, los merges y los conflictos. Todo lo anterior de esta página trabaja contra el repositorio, y funciona igual con un remoto local o con uno en GitHub.

Codespaces. Abre el proyecto en un editor completo dentro del navegador, sin instalar VS Code ni Python en tu equipo. Al abrirlo hay que sincronizar las dependencias con uv sync, porque la máquina remota llega vacía. Es opcional: si ya tienes VS Code y Python funcionando, ignóralo sin consecuencias. Se menciona en la página del editor.

Actions. Se explica en el capítulo 2.1 · Entorno de desarrollo profesional de Programación de IA, junto con la integración continua (CI): comprobaciones automáticas que se ejecutan en cada cambio. Tus prácticas no la necesitan, pero en un proyecto profesional es lo habitual; por eso se enseña.

Problemas habituales¶

Comandos de referencia rápida¶

Comprobación final¶

Desde la raíz del repositorio, ejecuta:

git status
git branch --show-current
git log --oneline -1
git diff --check

Salida esperada: Git muestra el estado y la rama sin errores, el historial contiene al menos un commit y git diff --check no imprime nada cuando no hay errores de espacios en los cambios no preparados. La salida concreta depende del trabajo que haya hecho cada persona.

Siguiente paso¶

Sigue con uv para dominar el gestor de dependencias; con eso cierras las herramientas y empiezas el contenido.