Curso de Git y GitHub

Presentarte ante Git, como el primer día de clases

Antes de usar Git, necesitas entender qué es, por qué existe y cómo piensa. Después lo configuraremos con tu identidad para que puedas empezar a usarlo.

El problema que Git resuelve

Imagina que estás escribiendo un informe importante. Llevas horas trabajando y haces un cambio que rompe todo. ¿Qué haces? Probablemente piensas “ojalá pudiera volver a la versión de hace 5 minutos”.

Ahora imagina algo peor: trabajas con 3 compañeros en el mismo proyecto. Cada uno tiene una copia del código en su computador. Alguien modifica un archivo, otro modifica el mismo archivo, un tercero borra algo sin querer. ¿Cómo juntan todo sin volverse locos? ¿Cómo saben quién cambió qué, cuándo y por qué?

Antes de Git, la gente resolvía esto de formas… creativas:

mi-proyecto-final.zip
mi-proyecto-final-v2.zip
mi-proyecto-final-DEFINITIVO.zip
mi-proyecto-final-DEFINITIVO-ahora-si.zip
mi-proyecto-final-NO-TOCAR.zip

¿Te suena familiar? Este sistema “funciona” para una persona con un documento pequeño. Pero en software, donde un proyecto puede tener cientos de archivos y decenas de personas trabajando al mismo tiempo, es una receta para el desastre.

Git nació para resolver exactamente este caos.

¿Qué es Git?

Git es un sistema de control de versiones. En palabras simples: es un programa que registra todos los cambios que haces en tus archivos, te permite volver a cualquier versión anterior y coordinar el trabajo de múltiples personas sobre el mismo proyecto.

Piensa en Git como tres cosas a la vez:

1. Una máquina del tiempo — Puedes volver a cualquier punto en la historia de tu proyecto. ¿El código funcionaba el martes pero hoy no? Vuelves al martes y comparas qué cambió.

2. Un cuaderno de bitácora — Cada cambio queda registrado: qué se modificó, quién lo hizo, cuándo y por qué. Es un historial completo y detallado de la evolución de tu proyecto.

3. Un coordinador de equipo — Permite que varias personas trabajen en el mismo proyecto simultáneamente, cada una en su propia “copia de trabajo”, y luego combinar todos los cambios de forma ordenada.

¿Cómo funciona conceptualmente?

Git funciona tomando “fotos” (snapshots) de tu proyecto. Cada vez que le dices “guarda este momento” (lo que se llama un commit), Git registra el estado exacto de todos tus archivos en ese instante.

Commit 1       Commit 2       Commit 3       Commit 4
    📸             📸             📸             📸
"Proyecto       "Agrego        "Corrijo       "Agrego
 vacío"          login"         un bug"        estilos"

Estas fotos se encadenan en una línea de tiempo. Puedes moverte hacia adelante y hacia atrás por esa línea, comparar fotos entre sí, o incluso crear líneas paralelas (ramas) para experimentar sin afectar el trabajo principal.

Lo más importante: Git vive en tu computador. Todo funciona sin internet. Cada copia de un proyecto con Git tiene la historia completa, no depende de un servidor central. Esto es lo que significa que sea “distribuido”: cada persona tiene la película entera, no solo el último fotograma.

¿Qué NO es Git?

Esto genera mucha confusión al principio, así que vamos a dejarlo claro:

Git NO es GitHub. Esta es la confusión más común. Son cosas diferentes que trabajan juntas:

• Git es la herramienta que se instala en tu computador. Registra cambios, crea versiones, maneja ramas. Funciona completamente offline.
• GitHub es un servicio web (una página de internet) donde puedes subir tus proyectos Git para tener un respaldo en la nube y colaborar con otras personas.

La analogía: Git es tu cámara de fotos (toma y organiza las fotos). GitHub es la galería en la nube donde las compartes (como Google Photos o iCloud). Puedes usar la cámara sin la galería, y la galería no sirve sin fotos.

Existen otros servicios similares a GitHub: GitLab, Bitbucket, Codeberg… todos usan Git por debajo, solo cambia la plataforma web. Si aprendes Git, puedes usar cualquiera de ellos.

Git NO es solo para programadores. Funciona con cualquier archivo de texto: documentación, configuraciones, notas, datos en CSV, scripts de análisis. Si trabajas con archivos de texto, Git puede ayudarte.

Git NO sube nada a internet automáticamente. Todo lo que haces con Git es local hasta que tú decides subirlo. Puedes trabajar semanas sin conexión y subir todo después. Tú controlas cuándo y qué compartes.

Git NO guarda copias completas de cada versión repetida. Es más inteligente que eso: internamente guarda snapshots (fotos) de tus archivos, pero si un archivo no cambió entre versiones, reutiliza el que ya tiene en vez de duplicarlo. Esto lo hace increíblemente eficiente. Un proyecto con miles de versiones puede ocupar menos espacio que unas pocas copias manuales de archivos zip.

Instalación de Git

sudo apt update
sudo apt install git

git --version
# Si no está instalado, aparecerá un diálogo para instalarlo

Para verificar que se instaló correctamente:

git --version
# git version 2.43.0  (o la versión que sea)

Si ves un número de versión, ¡perfecto! Git está instalado.

Configurar tu identidad

Git necesita saber quién eres para firmar tus cambios. Es como poner tu nombre en un trabajo de la escuela: cada cambio que guardes llevará tu nombre.

Configura tu nombre:

git config --global user.name "Tu Nombre Completo"

Reemplaza "Tu Nombre Completo" por tu nombre real (con las comillas).

Configura tu correo electrónico:

git config --global user.email "tu@correo.com"

¿Qué significa --global? Que esta configuración aplica para todos tus proyectos en este computador. Solo necesitas hacerlo una vez.

Configurar el editor de texto

Cuando Git necesita que escribas algo (como un mensaje largo), abre un editor de texto. Por defecto puede abrir Vim, que es un editor muy poderoso pero confuso para principiantes.

Para evitar ese problema, configuramos VS Code como editor:

git config --global core.editor "code --wait"

El --wait le dice a Git que espere a que cierres el archivo en VS Code antes de continuar.

Configurar la rama principal

Por convención moderna, la rama principal se llama main. Configuremos eso:

git config --global init.defaultBranch main

No te preocupes si no entiendes qué son las “ramas” todavía. Lo veremos en el Módulo 6. Por ahora solo estamos dejando todo bien configurado.

Verificar tu configuración

Para ver todo lo que configuraste:

git config --list
# user.name=Tu Nombre Completo
# user.email=tu@correo.com
# core.editor=code --wait
# init.defaultbranch=main

Si ves tus datos ahí, ¡todo está perfecto!

Tabla resumen

Ejercicios del módulo

Ejercicio 1: Instala Git en tu computador y verifica la instalación con git --version. ¿Qué versión tienes?

Ejercicio 2: Configura tu nombre y correo electrónico:

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

Ejercicio 3: Configura VS Code como tu editor por defecto:

git config --global core.editor "code --wait"

Ejercicio 4: Verifica que toda tu configuración está correcta:

git config --list

¿Aparecen tu nombre, correo y editor? ¡Excelente, estás listo para empezar a usar Git!

GitHub es como Google Drive pero para código

Hasta ahora, todo lo que has hecho con Git es local: vive solo en tu computador. Si tu disco duro muere mañana, pierdes todo.

GitHub es un servicio en la nube donde puedes subir tus repositorios Git. Piensa en la diferencia así:

• Git = la herramienta que instalaste en tu computador (la cámara de fotos)
• GitHub = un servicio web donde subes tus repositorios (Instagram para código)

GitHub te da dos cosas fundamentales:

1. Respaldo: Tu código está seguro en la nube
2. Colaboración: Otras personas pueden ver, descargar y contribuir a tu código

Crear tu cuenta en GitHub

Si todavía no tienes cuenta:

1. Ve a github.com y haz clic en “Sign up”
2. Usa el mismo correo que configuraste en Git (Módulo 2)
3. Elige un nombre de usuario que te guste (será tu identidad como desarrollador)
4. Completa el proceso de verificación

Instalar la app de GitHub (recomendado)

Antes de seguir, instala la app de GitHub en tu teléfono. La app te permite aprobar solicitudes de autenticación desde una notificación: cuando necesites autenticarte (por ejemplo con gh auth login), GitHub te manda una notificación al teléfono en vez de pedirte tokens o contraseñas.

Dos razones para instalarla ahora:

1. Seguridad: la app te permite activar verificación en dos pasos (2FA) usándola como método de aprobación, sin necesidad de configurar SMS ni apps de códigos
2. Configurar otros computadores es trivial: si mañana usas otro computador, solo ejecutas gh auth login y apruebas desde el teléfono — sin copiar tokens ni generar llaves SSH

Cómo instalarla:

1. Descarga GitHub Mobile desde la App Store (iOS) o Google Play (Android)
2. Inicia sesión con la cuenta de GitHub que acabas de crear
3. Acepta los permisos de notificaciones

Crear un repositorio en GitHub

Vamos a crear un repositorio vacío en GitHub para subir nuestro proyecto:

1. En GitHub, haz clic en el botón verde “New” (o en el + de la esquina superior derecha → “New repository”)
2. Ponle un nombre (ejemplo: mi-receta)
3. NO marques “Add a README file” (queremos un repo vacío)
4. NO selecciones un .gitignore ni licencia por ahora
5. Haz clic en “Create repository”

GitHub te mostrará una página con instrucciones. Esas instrucciones son exactamente lo que haremos a continuación.

Configurar autenticación

Para que Git pueda subir código a GitHub, necesitas autenticarte. La forma más fácil para principiantes:

sudo apt update
sudo apt install gh

brew install gh

gh auth login

git remote add origin — Conectar tu carpeta con la nube

Ahora necesitamos decirle a Git local: “este proyecto se conecta con este repositorio de GitHub”. Eso se hace con git remote.

# Conectar tu repo local con GitHub
git remote add origin https://github.com/tu-usuario/mi-receta.git

¿Qué significa cada parte?

• git remote add: “agrega una conexión remota”
• origin: es un nombre para esa conexión (es convención usar “origin” para la principal)
• https://github.com/...: la URL de tu repositorio en GitHub

Para verificar que la conexión se creó:

git remote -v
# origin  https://github.com/tu-usuario/mi-receta.git (fetch)
# origin  https://github.com/tu-usuario/mi-receta.git (push)

Si ves las dos líneas (fetch y push), la conexión está lista.

git push -u origin main — Subir tu trabajo a la nube

¡El momento de la verdad! git push sube tus commits locales a GitHub.

# Primera vez: necesitas el -u para establecer la conexión
git push -u origin main
# Enumerating objects: 6, done.
# Counting objects: 100% (6/6), done.
# Writing objects: 100% (6/6), 523 bytes | 523.00 KiB/s, done.
# Total 6 (delta 0), reused 0 (delta 0)
# To https://github.com/tu-usuario/mi-receta.git
#  * [new branch]      main -> main
# Branch 'main' set up to track remote branch 'main' from 'origin'.

¿Qué significa -u? Le dice a Git “recuerda que main local se conecta con main en GitHub”. Después de la primera vez, solo necesitas:

git push
# (sin -u, sin origin, sin main, Git ya recuerda)

¡Ve a GitHub en tu navegador y actualiza la página de tu repositorio! Deberías ver tus archivos ahí.

git clone — Descargar un proyecto de internet

git clone descarga una copia completa de un repositorio de GitHub a tu computador. Ya viene con todo configurado: la conexión remota, el historial de commits, todo.

# Clonar un repositorio
git clone https://github.com/usuario/nombre-repo.git
# Cloning into 'nombre-repo'...
# remote: Enumerating objects: 20, done.
# ...

# Entrar al repo clonado
cd nombre-repo

# Ya tiene todo configurado
git remote -v
# origin  https://github.com/usuario/nombre-repo.git (fetch)
# origin  https://github.com/usuario/nombre-repo.git (push)

git log --oneline
# (todo el historial del proyecto)

Flujo completo: de la idea a GitHub

Este es el flujo más importante que aprenderás. Conecta todo lo que viste en el Módulo 3 (repositorio local) con GitHub. Sigue cada paso en orden:

Paso 1: Crear la carpeta del proyecto e inicializar Git

mkdir mi-proyecto-web && cd mi-proyecto-web
git init

Paso 2: Crear .gitignore y hacer el primer commit

Siempre crea el .gitignore antes de empezar a trabajar (como aprendiste en el Módulo 3):

echo ".DS_Store" > .gitignore
echo "Thumbs.db" >> .gitignore
echo ".env" >> .gitignore
echo "node_modules/" >> .gitignore
echo "*.tmp" >> .gitignore
echo "*.log" >> .gitignore

git add .gitignore
git commit -m "chore: agrega .gitignore"

Paso 3: Crear los archivos del proyecto y hacer el segundo commit

echo "<!DOCTYPE html><html><body><h1>Hola Mundo</h1></body></html>" > index.html
echo "body { font-family: sans-serif; }" > estilos.css

git add index.html estilos.css
git commit -m "feat: crea estructura básica del sitio web"

Paso 4: Crear un repositorio vacío en GitHub

1. En GitHub, haz clic en el botón ”+” (esquina superior derecha) → “New repository”
2. Ponle el nombre mi-proyecto-web
3. NO marques “Add a README file”
4. NO selecciones un .gitignore template
5. NO selecciones una licencia
6. Haz clic en “Create repository”

GitHub te mostrará una página con instrucciones. Los comandos que necesitas son los de la sección “push an existing repository”.

Paso 5: Autenticarte (si no lo has hecho antes)

gh auth login
# Sigue las instrucciones: GitHub.com → HTTPS → Login with a web browser

Si ya te autenticaste antes, este paso no es necesario.

Paso 6: Conectar tu repo local con GitHub

git remote add origin https://github.com/tu-usuario/mi-proyecto-web.git

# Verificar la conexión
git remote -v
# origin  https://github.com/tu-usuario/mi-proyecto-web.git (fetch)
# origin  https://github.com/tu-usuario/mi-proyecto-web.git (push)

Paso 7: Subir tu código a GitHub por primera vez

git push -u origin main
# Enumerating objects: 8, done.
# ...
# To https://github.com/tu-usuario/mi-proyecto-web.git
#  * [new branch]      main -> main
# Branch 'main' set up to track remote branch 'main' from 'origin'.

El -u le dice a Git “recuerda que main local se conecta con main en GitHub”.

Paso 8: Verificar en GitHub

Abre tu navegador, ve a github.com/tu-usuario/mi-proyecto-web y actualiza la página. Deberías ver tus archivos (index.html, estilos.css, .gitignore) y tus commits.

Paso 9: Hacer un cambio, commit y push (flujo del día a día)

A partir de ahora, el flujo diario es mucho más simple:

# Editar un archivo
echo "<p>Bienvenido a mi sitio</p>" >> index.html

# El flujo de siempre: status → add → commit
git add index.html
git commit -m "feat: agrega mensaje de bienvenida"

# Subir a GitHub (ya no necesitas -u ni origin ni main)
git push

¡Eso es todo! A partir del primer push con -u, solo necesitas git push para subir tus nuevos commits.

Tabla resumen

Ejercicios del módulo

Ejercicio 1: Crea un repositorio vacío en GitHub (sin README, sin .gitignore). Anota la URL que te da.

Ejercicio 2: Conecta tu repo local de práctica con GitHub:

git remote add origin https://github.com/tu-usuario/tu-repo.git
git remote -v
# ¿Ves las dos líneas (fetch y push)?

Ejercicio 3: Sube tu trabajo con git push -u origin main:

git push -u origin main

Ejercicio 4: Ve a GitHub en tu navegador y verifica que tus archivos están ahí. ¿Puedes ver los commits? ¿Los archivos?

Ejercicio 5: Clona un repositorio público a tu máquina. Puedes clonar el repositorio de este mismo curso:

cd ~
git clone https://github.com/paulovillarroel/curso-git-github.git curso-git-github-copia
cd curso-git-github-copia
ls
git log --oneline

Las ramas son como universos paralelos

Imagina que eres un científico y quieres probar una idea loca. No vas a experimentar en tu laboratorio principal (podrías romper algo), así que creas un laboratorio paralelo. Si el experimento funciona, traes los resultados al laboratorio principal. Si no funciona, simplemente cierras el laboratorio paralelo y todo sigue igual.

Eso es exactamente lo que hacen las ramas en Git.

        main:    A --- B --- C
                              \
        feature:               D --- E

En este diagrama, main es tu laboratorio principal con los commits A, B y C. Luego creaste una rama feature donde hiciste los commits D y E. Mientras trabajas en feature, main no se ve afectado para nada.

git branch — Ver en qué universo estás

git branch te muestra todas las ramas que existen y marca con un asterisco (*) en la que estás parado.

git branch
# * main

Solo tenemos una rama: main. Y el * nos dice que estamos ahí.

git switch -c — Crear un laboratorio nuevo

git switch -c crea una rama nueva y te mueve a ella automáticamente. La -c viene de “create” (crear).

# Crear una nueva rama y movernos a ella
git switch -c feature/saludo
# Switched to a new branch 'feature/saludo'

git branch
#   main
# * feature/saludo

Ahora estás en la rama feature/saludo. Todo lo que hagas aquí (commits, cambios) NO afecta a main.

Trabajar en tu rama

Una vez en tu rama, el flujo es exactamente el mismo que aprendiste: editar → git add → git commit.

# Estamos en feature/saludo
echo "¡Hola Mundo desde Git!" > saludo.txt
git add saludo.txt
git commit -m "feat: agrega archivo de saludo"

# Hacer otro cambio
echo "Bienvenido al curso de Git" >> saludo.txt
git add saludo.txt
git commit -m "feat: agrega mensaje de bienvenida al saludo"

Estos commits solo existen en feature/saludo. La rama main no sabe nada de ellos.

git switch main — Volver a la realidad

Cuando vuelves a main, tus archivos cambian para reflejar el estado de main. Es como magia.

# Volver a main
git switch main
# Switched to branch 'main'

# Verificar: ¿existe saludo.txt?
ls
# receta.txt
# (¡No hay saludo.txt! Solo existe en la otra rama)

git merge — Traer el experimento exitoso a la realidad

Cuando estás satisfecho con tu trabajo en una rama, puedes mezclar (merge) esos cambios en main. Es como decir: “el experimento funcionó, traigan todo al laboratorio principal”.

Importante: Primero debes estar en la rama que recibe los cambios (generalmente main).

# 1. Asegúrate de estar en main
git switch main

# 2. Traer los cambios de feature/saludo
git merge feature/saludo
# Updating a1b2c3d..e5f6a7b
# Fast-forward
#  saludo.txt | 2 ++
#  1 file changed, 2 insertions(+)
#  create mode 100644 saludo.txt

# 3. Verificar
ls
# receta.txt  saludo.txt   ← ¡ahora saludo.txt está en main!

git log --oneline
# e5f6a7b Agrega mensaje de bienvenida al saludo
# d4e5f6a Agrega archivo de saludo
# ... (commits anteriores de main)

Conflictos de merge

A veces, cuando intentas hacer merge, Git encuentra un conflicto: dos ramas modificaron la misma línea del mismo archivo, y Git no sabe cuál elegir.

Esto no es un error. Es Git pidiendo tu ayuda para decidir.

Así se ve un archivo con conflicto:

<<<<<<< HEAD
Pasta con salsa de tomate
=======
Pasta con salsa boloñesa
>>>>>>> feature/nueva-receta

Los marcadores significan:

• <<<<<<< HEAD: lo que tiene tu rama actual (main)
• =======: separador
• >>>>>>> feature/nueva-receta: lo que tiene la otra rama

Cómo resolver un conflicto paso a paso:

1. Abre el archivo en tu editor de texto
2. Decide qué mantener: elimina los tres marcadores (<<<<<<<, =======, >>>>>>>) y deja solo el contenido correcto
3. Guarda el archivo
4. Haz add y commit:

# Después de editar el archivo y resolver el conflicto
git add receta.txt
git commit -m "Resuelve conflicto: elige salsa boloñesa"

git branch -d — Limpieza de ramas

Cuando una rama ya fue mergeada, debes borrarla. Una rama que ya cumplió su propósito no tiene razón de seguir existiendo. Dejarla ahí solo genera confusión: con el tiempo, el repositorio se llena de ramas viejas y nadie sabe cuáles están activas y cuáles son basura.

La regla es simple: rama mergeada = rama borrada.

# Borrar la rama local (solo funciona si ya fue mergeada)
git branch -d feature/saludo
# Deleted branch feature/saludo (was e5f6a7b).

La -d (de “delete”) es la forma segura de borrar: Git verifica que la rama ya fue mergeada antes de borrarla. Si no fue mergeada, te avisa para que no pierdas trabajo accidentalmente.

Si la rama también fue subida a GitHub, necesitas borrarla en el remoto también:

# Borrar la rama en GitHub
git push origin --delete feature/saludo

# 1. Borrar la rama local
git branch -d feature/saludo

# 2. Borrar la rama remota (si la subiste a GitHub)
git push origin --delete feature/saludo

git branch -D feature/experimento-fallido

Tabla resumen

Ejercicios del módulo

Ejercicio 1: Crea una rama feature/despedida, agrega un archivo despedida.txt con algún contenido, y haz commit:

git switch -c feature/despedida
echo "¡Adiós desde una rama!" > despedida.txt
git add despedida.txt
git commit -m "feat: agrega archivo de despedida"

Ejercicio 2: Vuelve a main y verifica que el archivo despedida.txt NO está:

git switch main
ls
# ¿Ves despedida.txt? No debería estar

Ejercicio 3: Mergea la rama a main y verifica que el archivo AHORA SÍ está:

git merge feature/despedida
ls
# Ahora despedida.txt debería aparecer

Ejercicio 4: Borra la rama con git branch -d:

git branch -d feature/despedida
git branch
# Solo debería quedar main

Ejercicio 5 (Desafío): Crea un conflicto a propósito y resuélvelo:

# Crear un archivo base
echo "Color favorito: azul" > preferencias.txt
git add . && git commit -m "feat: agrega preferencias"

# Crear una rama y cambiar el color
git switch -c feature/color
echo "Color favorito: rojo" > preferencias.txt
git add . && git commit -m "feat: cambia color a rojo"

# Volver a main y cambiar el color diferente
git switch main
echo "Color favorito: verde" > preferencias.txt
git add . && git commit -m "feat: cambia color a verde"

# Intentar merge (¡conflicto!)
git merge feature/color
# CONFLICT (content): Merge conflict in preferencias.txt

# Abre preferencias.txt, resuelve el conflicto, luego:
git add preferencias.txt
git commit -m "Resuelve conflicto: elige color verde"
git branch -d feature/color

Herramientas de poder para cuando ya dominas lo básico

En los módulos anteriores aprendiste a trabajar con Git de forma segura y productiva. Ahora es momento de conocer las herramientas avanzadas que te dan más control sobre la historia, la sincronización y la colaboración.

Estos comandos son más poderosos, pero también requieren más cuidado. Úsalos cuando entiendas bien lo que hacen.

git reset --hard HEAD~1 — El botón nuclear

# Esto BORRA el último commit y todos sus cambios
git reset --hard HEAD~1
# HEAD is now at b2c3d4e Agrega lista de ingredientes

Después de ejecutar esto, es como si el último commit nunca hubiera existido. Los archivos vuelven al estado del commit anterior y los cambios se pierden para siempre.

¿Cuándo usarlo? Casi nunca. Solo cuando hiciste algo realmente mal y estás seguro de que quieres eliminarlo por completo. En la mayoría de los casos, git revert (Módulo 5) es mejor opción.

git rebase — Integrar cambios con historia lineal

En el Módulo 7 viste las tres estrategias de merge (squash, merge commit, rebase). Ahora vas a aprender a usar rebase desde la terminal.

La diferencia clave con merge es cómo queda la historia:

• Merge crea un commit de merge que une las dos ramas
• Rebase “reescribe” la historia para que sea lineal, como si hubieras hecho tus cambios después de todo lo que pasó en main

Merge: crea un commit de merge (M) que une las ramas
        main:    A --- B --- C --------- M
                              \         /
        feature:               D --- E

Rebase: mueve tus commits para que empiecen desde la punta de main
        main:    A --- B --- C --- D' --- E'

Con merge, la historia muestra “aquí se juntaron dos ramas”. Con rebase, la historia queda limpia y lineal: tus commits aparecen como una continuación directa de main.

El comando básico:

# Estando en tu rama feature
git rebase main

Esto “mueve” los commits de tu rama para que empiecen desde la punta de main. Tus commits D y E se convierten en D’ y E’ (copias con el mismo contenido pero en una nueva posición de la historia).

Mantener tu rama actualizada con rebase (en Pull Requests)

Mientras trabajas en tu rama, tus compañeros siguen mergeando cambios a main. Después de unos días, tu rama está desactualizada: le faltan cambios que ya están en main. Esto puede causar conflictos más difíciles cuando quieras hacer merge, y hace que tu PR sea más difícil de revisar.

La solución es actualizar tu rama con rebase antes de crear el PR (o durante la revisión):

# Estás en tu rama feature/mi-cambio

# 1. Traer los cambios más recientes de main
git switch main
git pull

# 2. Volver a tu rama y hacer rebase
git switch feature/mi-cambio
git rebase main

# 3. Si hay conflictos, resolverlos y continuar
# (editar archivo, resolver conflicto)
git add archivo-resuelto.txt
git rebase --continue

# 4. Si todo sale mal, puedes cancelar y volver al estado anterior
git rebase --abort

¿Por qué rebase y no merge? Si haces git merge main dentro de tu rama, funciona, pero cuando las historias han divergido crea commits de merge extras que ensucian la historia y hacen tu PR más difícil de revisar. Con rebase, tu rama queda como si la hubieras creado recién desde el main más actualizado: limpia y fácil de revisar.

git pull --rebase — Atajo para actualizar tu rama

El flujo anterior (switch main → pull → switch feature → rebase) tiene un atajo. Si estás en tu rama y quieres actualizar directamente:

# Estando en tu rama feature/mi-cambio
git pull --rebase origin main

Esto hace git fetch + git rebase en un solo comando: trae los cambios de main del remoto y reaplica tus commits encima.

Por defecto, git pull sin flags hace un merge: trae los cambios remotos y crea un commit de merge para combinarlos (si las historias divergieron). La diferencia es la misma que ya conoces — --rebase mantiene la historia lineal, el merge por defecto preserva las bifurcaciones.

git push --force-with-lease — Push seguro después de rebase

git push --force-with-lease

Fork — Tu propia copia de un proyecto ajeno

Un fork es una copia completa de un repositorio de otra persona en tu cuenta de GitHub. Es diferente a clonar:

• Clone: descarga un repo a tu computador (copia local)
• Fork: crea una copia del repo en tu cuenta de GitHub (copia en la nube)

¿Para qué sirve? Imagina que encuentras un proyecto open source que quieres mejorar. No puedes hacer push directamente al repo de otra persona (no tienes permisos), pero puedes:

1. Hacer fork del proyecto (ahora tienes tu propia copia en GitHub)
2. Clonar tu fork a tu computador
3. Hacer tus cambios y push a tu fork
4. Crear un Pull Request desde tu fork al proyecto original

Cómo hacer un fork:

1. Ve al repositorio en GitHub que quieres copiar
2. Haz clic en el botón “Fork” (esquina superior derecha)
3. Selecciona tu cuenta como destino
4. ¡Listo! Ahora tienes una copia en github.com/tu-usuario/nombre-repo

Trabajar con tu fork:

# 1. Clonar TU fork (no el repo original)
git clone https://github.com/tu-usuario/nombre-repo.git
cd nombre-repo

# Verificar: origin apunta a TU fork
git remote -v
# origin  https://github.com/tu-usuario/nombre-repo.git (fetch)
# origin  https://github.com/tu-usuario/nombre-repo.git (push)

# 2. Crear una rama para tu contribución (nunca trabajes en main)
git switch -c feature/mi-mejora

# 3. Hacer tus cambios, add y commit
echo "Mi mejora" >> archivo.txt
git add archivo.txt
git commit -m "Agrega mejora al archivo"

# 4. Subir la rama a TU fork
git push -u origin feature/mi-mejora

Después ve a GitHub y crea un Pull Request desde tu fork al repositorio original. GitHub detecta automáticamente la rama que subiste y te ofrece crear el PR.

Mantener tu fork actualizado con upstream

Con el tiempo, el proyecto original seguirá avanzando. Para traer esos cambios a tu fork:

# Agregar una conexión al repo original (se hace una sola vez)
git remote add upstream https://github.com/autor-original/nombre-repo.git

# Traer los cambios del original y actualizar tu fork
git fetch upstream
git switch main
git merge upstream/main
git push
# Ahora tu fork está al día con el proyecto original

upstream es el nombre convencional para el repositorio original (el que forkeaste). origin sigue siendo tu fork.

git fetch — Preguntar si hay novedades

git fetch revisa si hay cambios nuevos en GitHub sin aplicarlos a tus archivos. Es como mirar el buzón sin abrir las cartas.

git fetch
# Si hay cambios nuevos, te muestra información
# Si no hay cambios, no muestra nada

Es útil para verificar si alguien más subió cambios antes de traerlos. La diferencia con git pull:

• git fetch: solo descarga la información, tus archivos no cambian
• git pull: descarga Y aplica los cambios (es un fetch + merge)

git pull avanzado

Ya conoces git pull del Módulo 4. Aquí van los detalles más avanzados.

El comportamiento por defecto de git pull es hacer merge. Cuando ejecutas git pull sin flags, Git hace dos cosas automáticamente:

1. git fetch — descarga los cambios del remoto
2. git merge — fusiona esos cambios con tu rama local

Como el merge ya viene “de fábrica”, no existe un flag --merge. Si intentas git pull --merge, Git te dará un error. Es lógico pensar que debería existir (sobre todo porque sí existe --rebase), pero sería redundante.

Los flags que sí existen:

# Pull normal (fetch + merge) — comportamiento por defecto
git pull

# Pull con rebase (fetch + rebase, historia lineal)
git pull --rebase origin main

# Forzar commit de merge explícito (incluso cuando fast-forward es posible)
git pull --no-ff

# Forzar merge aunque tu config global diga rebase
git pull --no-rebase

# Solo funciona si no hay divergencia (el más seguro)
git pull --ff-only

# Antes de pull, siempre:
git status
# Si hay cambios pendientes:
git add .
git commit -m "Guarda cambios antes de pull"
# Ahora sí:
git pull

Tabla resumen

Ejercicios del módulo

Ejercicio 1: Practica git reset --hard en un repo desechable:

mkdir practica-avanzado && cd practica-avanzado
git init
echo "Línea 1" > archivo.txt
git add . && git commit -m "Commit 1"
echo "Línea 2" >> archivo.txt
git add . && git commit -m "Commit 2"
echo "Línea 3" >> archivo.txt
git add . && git commit -m "Commit 3"

# Ver historial
git log --oneline
# Ahora borra el último commit
git reset --hard HEAD~1
git log --oneline
cat archivo.txt
# La línea 3 desapareció por completo

Ejercicio 2: Practica rebase entre ramas:

# Crear commits en main
echo "Base actualizada" >> archivo.txt
git add . && git commit -m "Actualiza base en main"

# Crear rama y trabajar
git switch -c feature/prueba-rebase
echo "Cambio en rama" > rama.txt
git add . && git commit -m "Agrega archivo en rama"

# Volver a main y agregar otro commit
git switch main
echo "Otro cambio en main" >> archivo.txt
git add . && git commit -m "Otro cambio en main"

# Rebase: actualizar la rama
git switch feature/prueba-rebase
git rebase main
git log --oneline
# Tu commit de rama aparece DESPUÉS de los de main

# Limpieza
git switch main
git merge feature/prueba-rebase
git branch -d feature/prueba-rebase

Ejercicio 3: Haz fork de un repositorio público: ve a cualquier repo en GitHub, haz clic en “Fork”, clona tu fork y verifica con git remote -v que apunta a tu cuenta.

Ejercicio 4: Practica git fetch para ver cambios sin aplicarlos:

# En un repo conectado a GitHub
git fetch
git log --oneline origin/main
# Ves los commits remotos sin que tus archivos cambien
git pull
# Ahora sí se aplican

Cómo trabajar en equipo sin destruir el proyecto

Hasta ahora has aprendido Git como herramienta individual: commits, ramas, PRs, rebase. Pero cuando trabajas en equipo, la herramienta sola no basta. Necesitas convenciones: reglas compartidas que evitan el caos.

Imagina una cocina de restaurante. Todos los chefs saben cocinar, pero si cada uno guarda los ingredientes donde quiere, usa los cuchillos de otro y no avisa cuándo enciende el horno, el resultado es un desastre. La solución no es mejor equipo de cocina — es tener acuerdos sobre cómo trabajar juntos.

Este módulo te enseña esos acuerdos para Git: cómo nombrar ramas, escribir commits, proteger main, crear templates de PR, y evitar los errores más comunes en equipo.

Convenciones de ramas

Cuando trabajas solo, puedes nombrar tus ramas como quieras. En equipo, eso no funciona. Si una persona crea arreglo-login, otra fix/login-bug y otra hotfix_auth, nadie sabe qué está pasando.

La convención estándar:

tipo/descripcion-breve

Los tipos más comunes:

# Bien
git switch -c feature/carrito-compras
git switch -c fix/error-validacion-email
git switch -c docs/guia-instalacion

# Mal
git switch -c mi-rama
git switch -c cambios-pedro
git switch -c arreglo-cosa

La regla de oro: una tarea = una rama. Cada rama debe hacer una cosa específica. Si tu rama hace 5 cosas diferentes, va a ser imposible de revisar y dolorosa de mergear.

Convenciones de commits en equipo

En el Módulo 3 aprendiste Conventional Commits (feat:, fix:, docs:, etc.). En equipo, esto deja de ser una recomendación y se vuelve una regla: todos usan el mismo formato para que el historial sea legible y consistente.

Recordatorio rápido del formato:

git commit -m "feat: agrega botón de exportar a PDF"
git commit -m "fix: corrige cálculo de impuestos en factura"
git commit -m "docs: agrega sección de FAQ al README"

Regla adicional para equipos: si necesitas más detalle, deja una línea en blanco y escribe un cuerpo descriptivo:

git commit -m "feat: agrega autenticación con Google

Implementa OAuth 2.0 para login con Google.
Incluye botón en la página de login y manejo de
tokens en el backend."

Branch protection en GitHub

Las convenciones de ramas y commits funcionan solo si todos las respetan. Pero, ¿qué pasa si alguien hace push directo a main por accidente? Para eso existen las reglas de protección de ramas.

Branch protection le dice a GitHub: “No dejes que nadie modifique main directamente. Todo debe pasar por un Pull Request”.

Cómo configurarlo:

1. Ve a tu repositorio en GitHub
2. Settings → Branches
3. Haz clic en Add branch ruleset (o “Add rule” en repos más antiguos)
4. En “Branch name pattern” escribe: main
5. Activa estas reglas:

# Con branch protection activado:

# Esto FALLA (push directo a main)
git switch main
echo "cambio directo" >> archivo.txt
git add . && git commit -m "cambio directo"
git push
# ❌ remote: error: GH006: Protected branch update failed

# Esto FUNCIONA (via PR)
git switch -c fix/mi-cambio
echo "cambio via PR" >> archivo.txt
git add . && git commit -m "fix: cambio correcto via PR"
git push -u origin fix/mi-cambio
gh pr create --title "Fix: mi cambio" --body "Descripción"
# ✅ PR creado, esperando revisión

PR Templates

Cuando alguien crea un Pull Request, ¿cómo sabes qué debe incluir? Un PR template es un archivo que GitHub usa automáticamente como plantilla cada vez que alguien crea un PR.

Cómo crearlo:

# Desde la raíz de tu proyecto
mkdir -p .github

Puedes crear este archivo directamente en VS Code: crea la carpeta .github/ y dentro el archivo pull_request_template.md con el siguiente contenido:

## ¿Qué hace este PR?

<!-- Describe brevemente los cambios -->

## Tipo de cambio

- [ ] Nueva funcionalidad (feature)
- [ ] Corrección de bug (fix)
- [ ] Documentación (docs)
- [ ] Refactorización (refactor)
- [ ] Otro: ___

## ¿Cómo se probó?

<!-- Describe cómo verificaste que funciona -->

## Checklist

- [ ] Mi código sigue las convenciones del proyecto
- [ ] He probado mis cambios localmente
- [ ] He actualizado la documentación si es necesario

# Agregar al proyecto
git add .github/pull_request_template.md
git commit -m "chore: agrega template de Pull Request"
git push

Ahora, cada vez que alguien crea un PR en este repositorio, verá este template ya completado con las secciones. Solo tiene que rellenar los espacios.

Squash merge como convención de equipo

En el Módulo 7 viste las tres estrategias de merge y recomendamos squash merge como default. En equipo, esto se convierte en una configuración del repositorio:

Configurar squash como único método permitido:

1. Settings → General → Pull Requests
2. Desmarca “Allow merge commits” y “Allow rebase merge”
3. Deja solo “Allow squash merging” marcado

Así ningún miembro del equipo puede mergear accidentalmente con otra estrategia. Todos los PRs producen un solo commit limpio en main.

Prevenir conflictos en equipo

En el Módulo 6 aprendiste a resolver conflictos técnicamente (los marcadores <<<<<<<, =======, >>>>>>>). En equipo, la clave no es solo resolverlos sino minimizarlos:

1. Divide el trabajo por archivos/componentes. Si Ana trabaja en el header y Bob en el footer, no habrá conflictos.
2. Haz pull frecuentemente. Actualiza tu rama diariamente, no cada 3 días.
3. Ramas pequeñas, PRs frecuentes. Una rama de 2 días tiene menos conflictos que una de 2 semanas.
4. Comunica antes de refactorizar. Mover archivos o renombrar funciones genera conflictos en todas las ramas activas. Avisa al equipo.

Anti-patrones: lo que NO debes hacer en equipo

Estos son los errores más comunes que destruyen la productividad de un equipo. Si te reconoces en alguno, no te preocupes — todos los hemos cometido.

1. Commits gigantes

# MAL: un commit con 47 archivos modificados
git add .
git commit -m "muchos cambios"
# Imposible de revisar, imposible de revertir parcialmente

# BIEN: commits atómicos
git add src/auth/login.js
git commit -m "feat: agrega validación de email en login"
git add src/auth/register.js
git commit -m "feat: agrega validación de email en registro"

2. Trabajar directamente en main

# MAL
git switch main
# ... hacer cambios durante 3 días ...
git push
# Acabas de romper main para todos

# BIEN
git switch -c feature/mi-cambio
# ... trabajar tranquilo en tu rama ...

3. No hacer pull antes de empezar a trabajar

# MAL: empezar a trabajar sin actualizar
git switch -c feature/nueva
# Tu rama está basada en un main desactualizado
# Vas a tener conflictos innecesarios

# BIEN: siempre actualizar primero
git switch main
git pull
git switch -c feature/nueva
# Ahora tu rama está basada en la versión más reciente

4. Acumular ramas que ya se mergearon

# MAL: nunca limpiar
git branch
# feature/header
# feature/footer-v1
# feature/footer-v2
# fix/bug-viejo
# ... 30 ramas más que ya se mergearon

# BIEN: limpiar después de cada merge
git branch -d feature/mi-rama-mergeada
# O limpiar todas las ramas mergeadas de una vez
git branch --merged main | grep -v main | xargs git branch -d

5. Force push a main

# NUNCA hagas esto
git push --force origin main
# Esto REESCRIBE el historial compartido
# Todos los miembros del equipo van a tener problemas

# Force push a TU rama está OK (con cuidado)
git push --force origin feature/mi-rama
# Esto está bien si solo tú trabajas en esa rama

Extra: AGENTS.md — tus convenciones para agentes de IA

Si usas agentes de IA como Claude Code o Gemini CLI (Módulo 9), cuando trabajas con ellos en un proyecto de equipo surge un problema: el agente no conoce las convenciones de tu equipo. Puede hacer commits con mensajes en inglés cuando tu equipo los escribe en español, o hacer push directo a main cuando tu equipo usa PRs.

La solución es un archivo AGENTS.md (o CLAUDE.md, dependiendo del agente) en la raíz de tu repositorio. Este archivo le dice al agente de IA las reglas del proyecto, exactamente igual que el PR template le dice a un humano cómo crear un PR.

Piénsalo así: el PR template es la “guía para humanos” y AGENTS.md es la “guía para IAs”.

¿Qué poner en un AGENTS.md?

Las mismas convenciones que le explicarías a un nuevo miembro del equipo:

# AGENTS.md

## Flujo de trabajo Git

Este equipo usa el flujo Feature Branch + Squash Merge.

### Reglas de Git
- Nunca hacer commit directo a main
- Crear ramas con formato: tipo/descripcion-corta
  - Tipos: feature/, fix/, docs/, refactor/
- Mensajes de commit en español, imperativo, una línea
  - Ejemplo: "Agregar filtro por región al dashboard"
- Antes de hacer push, verificar que el código corre sin errores

### Pull Requests
- Todo merge a main pasa por PR
- Usar squash merge
- Descripción del PR debe incluir: qué hace, por qué, cómo probarlo
- Borrar la rama después del merge

### Resolución de conflictos
- Al resolver conflictos, explicar qué versión se eligió y por qué
- No resolver conflictos automáticamente sin que el usuario entienda qué cambió
- Si el conflicto es ambiguo, mostrar ambas versiones y preguntar

### Convenciones del equipo
- Idioma: español para documentación, inglés para código
- Los nombres de variables y funciones en inglés
  (snake_case para R, snake_case para Python)
- Los comentarios en el código pueden ser en español

# Agregar al proyecto
git add AGENTS.md
git commit -m "docs: agrega AGENTS.md con convenciones para agentes IA"
git push