Juan Diego Andrés PRADA··RAMÍREZ Entrar
Lección 4 de 7

GitHub y colaboración

Ya tienes un repositorio Git local con historial. En este módulo lo sacamos al mundo: lo subimos a GitHub, le añadimos las piezas que todo proyecto profesional necesita —un .gitignore y un README— y aprendes el flujo de colaboración con pull requests. Al terminar, tu PROYECTO FINAL vivirá en la nube, será clonable por cualquiera y tendrá su portada de presentación.

¿Qué es?

GitHub es una plataforma web para alojar repositorios Git. Si Git es el sistema que guarda la historia en tu máquina, GitHub es el lugar donde esa historia se publica, se respalda y se comparte. Sobre Git puro, GitHub añade colaboración: pull requests, revisión de código, issues (tickets de trabajo) y control de permisos.

El repositorio en tu máquina se llama local; el de GitHub se llama remoto (remote). Sincronizas entre ambos con dos verbos: push (subir tus commits al remoto) y pull (bajar los del remoto a tu máquina).

¿Cómo funciona?

Conectas tu repositorio local con uno remoto en GitHub (le pones un nombre, por convención origin). A partir de ahí:

  • git push envía tus commits locales a GitHub.
  • git pull trae a tu máquina los commits que haya en GitHub.
  • Una pull request (PR) es una propuesta de fusión: "tengo estos cambios en mi rama, revísenlos y, si están bien, mézclenlos en main". Es el corazón de la colaboración: nadie escribe directo en main; se propone, se revisa y se aprueba.

¿Para qué sirve?

  • Respaldo en la nube: si tu disco muere, tu proyecto sigue vivo.
  • Portafolio: tus repos públicos son tu carta de presentación profesional.
  • Colaboración ordenada: las PR permiten revisar antes de fusionar.
  • Portada del proyecto: el README explica qué es y cómo usarlo; el .gitignore mantiene el repo limpio de basura.

Construyamos esta pieza del proyecto

Paso 1: crea el .gitignore

El .gitignore es un archivo que lista lo que Git debe ignorar: cosas que no se suben porque son grandes, generadas o privadas. El caso estrella es la carpeta .venv del primer módulo: no se sube, cada quien la recrea desde requirements.txt.

Crea el archivo en la raíz del proyecto:

cd mi-entorno-pro

Con este contenido:

# Entorno virtual (se recrea desde requirements.txt)
.venv/

# Cachés de Python
__pycache__/
*.pyc

# Variables de entorno y secretos
.env

# Archivos del sistema operativo
.DS_Store

Si ya habías subido por error una carpeta como .venv, añadirla al .gitignore no la quita del repositorio. Hay que sacarla del seguimiento: git rm -r --cached .venv y luego commit.

Paso 2: crea el README.md

El README es la portada del proyecto: lo primero que GitHub muestra. Debe responder qué es, cómo instalarlo y cómo usarlo. Crea README.md:

# Mi Entorno Pro

Entorno de desarrollo profesional, listo y reproducible.

## Requisitos

- Python 3.10 o superior

## Instalación

```bash
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\Activate.ps1
pip install -r requirements.txt

Uso

python app.py


Haz un commit con las dos piezas nuevas:

```bash
git add .gitignore README.md
git commit -m "Añade gitignore y README"

Tech English: README se lee "read me" ("léeme"). Es una convención universal: el archivo que el visitante debe leer primero.

Paso 3: crea el repositorio remoto y conéctalo

Lo más cómodo es usar la herramienta oficial de GitHub, gh. Autentícate una vez:

gh auth login

Y crea el repositorio remoto a partir del local, en un solo paso:

gh repo create mi-entorno-pro --public --source=. --remote=origin --push

Esto crea el repo en GitHub, lo conecta como origin y sube (push) tu historial.

Si prefieres hacerlo a mano (creando el repo vacío desde la web de GitHub), el equivalente es:

git remote add origin https://github.com/TU-USUARIO/mi-entorno-pro.git
git push -u origin main

El -u enlaza tu rama main local con la remota, para que en adelante baste con git push.

Paso 4: el ciclo diario push / pull

Cada vez que hagas commits nuevos, súbelos:

git push

Y antes de empezar a trabajar, baja lo que haya cambiado en el remoto:

git pull

Regla de oro de equipo: pull antes de empezar, push al terminar. Así reduces los conflictos al mínimo.

Paso 5: flujo de pull request

Así se colabora de verdad. Nunca escribes directo en main: trabajas en una rama y propones la fusión.

git switch -c feature/mejora-readme
# ...editas el README...
git add README.md
git commit -m "Mejora la sección de uso"
git push -u origin feature/mejora-readme

Ahora abre la pull request:

gh pr create --title "Mejora del README" --body "Aclara la sección de uso."

En GitHub, esa PR se puede revisar, comentar y, cuando esté aprobada, fusionar. Tras fusionarla, vuelve a main y actualiza tu local:

git switch main
git pull

No fusiones tus propias PR a ciegas en un proyecto en equipo. El sentido de la PR es que alguien más revise antes de que el cambio entre a main.

Ejercicios

  1. Crea un repositorio nuevo en GitHub con gh repo create, añádele un .gitignore y un README.md decentes, haz commit y push. Abre la URL del repo en el navegador y confirma que el README se ve como portada.
  2. En ese repo, crea una rama feature/cambio, modifica el README, súbela y abre una pull request con gh pr create. Revisa la PR en la web, fusiónala y luego haz git switch main + git pull para traer el cambio fusionado a tu máquina.
Tu progreso se guarda en este navegador. Inicia sesión para guardarlo en tu cuenta y verlo desde cualquier dispositivo.