Curso de programación GRATIS Modulo II: Git y GitHub Parte II

Git & GitHub · M2 P2

0%

Módulo 2 · Parte 2

✅ Parte 1 completada

🚀 Proyecto del módulo

Publicar en GitHub

Completa L4 y L5 para desbloquearlo

Módulo 2 · Parte 2 · Git & GitHub · 2026

Branches, PRs
y tu primer repositorio público

Las últimas dos herramientas que completan tu dominio de Git — y el proyecto que convierte todo el trabajo del Módulo 1 en tu primer portafolio público en GitHub.

2Lecciones

1Proyecto real

2Mini quizzes

∞Tu portafolio

🔖 Marcadores

Sin marcadores — usa el botón dorado en cualquier lección.

L4

Intermedio

Branches: líneas de trabajo paralelas

Una branch (rama) es una línea de trabajo independiente dentro del mismo repositorio. Te permite desarrollar nuevas funciones, corregir bugs o experimentar ideas sin afectar el código principal que ya funciona. Es una de las características más poderosas de Git y la base del trabajo colaborativo en equipos profesionales.

🌿

Analogía: las ramas de un árbol

El tronco del árbol es tu código principal (main): estable, probado, listo para producción. Las ramas crecen desde el tronco en distintas direcciones sin afectarlo. Puedes cultivar una rama por semanas, y cuando esté lista y sana, la injertas de vuelta al tronco. Si una rama se seca, simplemente la podas sin que el árbol sufra. Así es exactamente como Git maneja las branches.

La rama main: el código que siempre funciona

Por convención, la rama main (antes llamada master) contiene siempre la versión estable y funcional del proyecto. Es la rama que ven los usuarios, la que se despliega a producción, la que nunca debería tener código roto. Nunca desarrolles directamente en main — para eso están las ramas de trabajo.

💡 Flujo de trabajo estándar en la industria

Los equipos profesionales tienen una regla simple: main siempre funciona. Todo el desarrollo nuevo ocurre en ramas separadas. Cuando una función está completa y probada, se fusiona a main mediante un Pull Request. Este flujo se llama GitHub Flow y lo usan empresas como GitHub, Airbnb, Shopify y millones de proyectos open source.

Cómo se ve el flujo con branches

📊 Diagrama — Desarrollo con branches

main

C1

C2

C3

M

← merge

feat/inventario

F1

F2

F3

→ PR → merge

🟢 main (estable)  |  🔵 feat/inventario (desarrollo)  |  🟡 M = merge point

Comandos esenciales de branches

Terminal — Crear, navegar y gestionar ramas

# Ver todas las ramas del repositorio $ git branch * main # el * indica la rama actual # Crear una rama Y cambiar a ella en un solo comando $ git checkout -b feat/agregar-busqueda Switched to a new branch 'feat/agregar-busqueda' # Forma moderna (Git 2.23+) — equivalente al anterior $ git switch -c feat/agregar-busqueda # Cambiar a una rama existente $ git switch main Switched to branch 'main' # Ver en qué rama estás en todo momento $ git branch --show-current feat/agregar-busqueda # Eliminar una rama (después de hacer merge) $ git branch -d feat/agregar-busqueda Deleted branch feat/agregar-busqueda (was f3a1c2b).

El proceso completo: rama → trabajo → merge

Terminal — Flujo real de una feature branch

# 1. Partir siempre de main actualizado $ git switch main $ git pull origin main # 2. Crear la rama para la nueva función $ git switch -c feat/buscar-producto # 3. Trabajar normalmente: editar, añadir, commitear $ git add inventario.py $ git commit -m "feat: implementar búsqueda por nombre" $ git commit -m "feat: agregar búsqueda por categoría" # 4. Subir la rama a GitHub $ git push origin feat/buscar-producto remote: Create a pull request for 'feat/buscar-producto' remote: https://github.com/usuario/repo/pull/new/feat/buscar-producto # 5. Después del merge en GitHub: limpiar localmente $ git switch main $ git pull origin main $ git branch -d feat/buscar-producto

Convenciones de nombres de ramas

Prefijo	Para qué se usa	Ejemplo real
feat/	Nueva funcionalidad	feat/sistema-inventario
fix/	Corrección de bug	fix/division-por-cero
docs/	Documentación	docs/actualizar-readme
refactor/	Mejora de código sin cambiar funcionalidad	refactor/extraer-funciones
hotfix/	Corrección urgente en producción	hotfix/crash-al-iniciar
chore/	Mantenimiento general	chore/actualizar-dependencias

¿Qué pasa cuando dos ramas modifican el mismo archivo?

Cuando dos ramas modifican las mismas líneas de código y luego se intenta fusionarlas, Git no sabe cuál versión conservar. Esto se llama conflicto de merge. Git marca el archivo con indicadores especiales para que tú —como programador— decidas qué código queda:

Archivo con conflicto — Git lo marca así

# Git marca el conflicto con estos delimitadores:

<<<<<<< HEAD                    # código de tu rama actual
def calcular(n1, op, n2):
    print("Calculando...")
=======                         # separador
def calcular(n1, op, n2):
    print(f"Calculando {n1} {op} {n2}...")
>>>>>>> feat/mejorar-mensajes  # código de la otra rama

# Tu trabajo: elegir cuál versión conservar (o combinarlas),
# borrar los marcadores, guardar el archivo, y hacer commit.

⚠ Los conflictos son normales, no un error

Los conflictos de merge asustan a los principiantes, pero son completamente normales en equipos. Git simplemente te pide que decidas qué código prevalece. La mejor manera de minimizarlos es hacer commits frecuentes, ramas de vida corta (1–3 días) y comunicación entre el equipo sobre qué archivos está tocando cada quien.

🧠 Quiz: Estás trabajando en la función de búsqueda del inventario y aún no está terminada. Alguien reporta un bug crítico en la calculadora que hay que corregir ahora. ¿Cuál es la forma correcta de manejarlo con Git?

L5

Intermedio

Pull Requests: la puerta de revisión del código profesional

Un Pull Request (PR) es una solicitud formal para fusionar el código de una rama hacia otra —generalmente hacia main. Es mucho más que un botón de merge: es el espacio donde el equipo revisa el código, deja comentarios, sugiere mejoras, aprueba o rechaza cambios antes de que toquen el código principal.

📋

Analogía: el PR es como entregar un trabajo para revisión antes de publicarlo

En una editorial, antes de publicar un artículo, el autor lo entrega al editor. El editor lo revisa, señala errores, sugiere mejoras, y solo cuando está satisfecho lo aprueba para publicación. Un Pull Request funciona igual: tu código es el artículo, GitHub es la plataforma de revisión, tus compañeros son los editores, y el merge a main es la publicación. Nada llega a producción sin pasar por ese filtro.

Anatomía de un Pull Request

🔀 feat: implementar sistema de búsqueda en inventario Open

📁 feat/buscar-producto → main 👤 @tu-usuario 📅 hace 2 horas 📝 3 commits ➕ +47 líneas   ➖ -3 líneas

¿Qué hace este PR?
Agrega la funcionalidad de búsqueda al sistema de inventario. El usuario puede buscar productos por nombre o por categoría. Se incluye validación de entrada y manejo de resultados vacíos.

✅3 commits · sin conflictos con main

✅Revisión solicitada a @compañero

⏳Esperando aprobación (1 de 2 revisores)

✅Branch actualizada con los últimos cambios de main

Cómo crear un Pull Request paso a paso

1

Sube tu rama a GitHub

Ejecuta git push origin nombre-de-tu-rama. GitHub detecta la rama nueva y te muestra automáticamente un banner verde: "Compare & pull request". Haz clic en ese botón.

2

Completa el formulario del PR

Escribe un título claro que describa el cambio. Agrega una descripción: qué hace, por qué se necesita, cómo probarlo. Cuanta más información, más fácil es la revisión para tus compañeros.

3

Asigna revisores

En proyectos en equipo, añade a los compañeros que deben revisar el código en la sección Reviewers. Ellos recibirán una notificación y podrán dejar comentarios línea por línea directamente en GitHub.

4

Responde comentarios y actualiza

Si un revisor pide cambios, los haces en la misma rama local, haces nuevos commits y los subes con git push. El PR se actualiza automáticamente con los nuevos commits — no hay que crear uno nuevo.

5

Merge: la fusión final

Cuando todos los revisores aprueban, el PR puede fusionarse. GitHub ofrece 3 opciones: Merge commit (conserva todo el historial), Squash and merge (condensa todos los commits en uno) y Rebase and merge (historial lineal sin commit de merge). Para proyectos individuales, cualquiera funciona bien.

PR en proyectos personales: ¿tiene sentido?

Sí, incluso trabajando solo. Los PRs en proyectos personales te ayudan a revisar tu propio trabajo antes de mergearlo, mantener un registro organizado de qué funciones agregaste y cuándo, y practicar el flujo exacto que usarás en tu primer trabajo. Muchos reclutadores revisan el historial de PRs de tu GitHub para evaluar tu forma de trabajar.

✅ PR de calidad: lista de verificación

Antes de abrir un PR, revisa: (1) ¿El título describe el cambio sin leer el código? (2) ¿La descripción explica el "por qué", no solo el "qué"? (3) ¿Probaste manualmente que funciona? (4) ¿El PR es lo suficientemente pequeño para revisarse en 20 minutos? Los PRs grandes son difíciles de revisar y propensos a errores.

Comandos Git relacionados con PRs

Terminal — Comandos antes y después de un PR

# Antes del PR: actualizar la rama con los últimos cambios de main $ git switch feat/buscar-producto $ git merge main $ git push origin feat/buscar-producto # Ver diferencia entre tu rama y main $ git diff main..feat/buscar-producto # Después del merge en GitHub: limpiar localmente $ git switch main $ git pull origin main $ git branch -d feat/buscar-producto # Verificar historial $ git log --oneline --graph --all * d8e5b44 (HEAD -> main, origin/main) feat: implementar búsqueda * c6d3a33 feat(inventario): agregar funciones CRUD * b4f0e22 fix: corrección de división por cero

🧠 Quiz: Un revisor deja un comentario en tu PR pidiendo que cambies el nombre de una función. ¿Cuál es la forma correcta de responder?

🏆

Proyecto Final

Publica tu proyecto en GitHub: tu primer portafolio

Este es el momento en que todo el trabajo del Módulo 1 (la Calculadora + Sistema de Inventario) deja de vivir solo en tu computadora y se convierte en algo que el mundo puede ver. Publicar en GitHub no es solo guardar código en la nube — es construir tu reputación como desarrollador.

🚀 Proyecto Final del Módulo 2

Publicar todos los ejercicios del Módulo 1 en GitHub con estructura profesional

✅ Control de versiones ✅ Repositorio local ✅ Commits limpios ✅ Branches ✅ Pull Requests 📤 Publicar en GitHub

Estructura del repositorio que vas a crear

Estructura final del repositorio

fundamentos-programacion/          # nombre del repositorio en GitHub
│
├── README.md                        # descripción del proyecto
├── .gitignore                       # archivos que Git ignorará
│
├── modulo1-fundamentos/
│   ├── calculadora_inventario.py    # el proyecto completo del Módulo 1
│   └── ejercicios/
│       ├── 01_variables.py
│       ├── 02_operadores.py
│       ├── 03_condicionales.py
│       └── 04_ciclos_funciones.py
│
└── modulo2-git-github/
    └── notas-comandos.md             # tus apuntes de Git

Paso a paso: publica tu repositorio HOY

1

Crea el repositorio en GitHub

Ve a github.com → New repository. Nombre: fundamentos-programacion. Visibilidad: Public. NO inicialices con README ni .gitignore — los crearemos nosotros.

2

Prepara el repositorio local

En tu computadora, ve a la carpeta del proyecto. Si aún no inicializaste Git, ejecuta git init. Crea la estructura de carpetas y coloca el archivo calculadora_inventario.py dentro de modulo1-fundamentos/.

3

Crea el archivo .gitignore

Crea el archivo .gitignore en la raíz del proyecto ignorando __pycache__/, .env, venv/, .DS_Store. Esto garantiza que solo suba código limpio a GitHub.

4

Crea el README.md profesional

El README es la portada de tu proyecto. Es lo primero que ven los reclutadores. En el bloque de abajo tienes la plantilla completa lista para copiar y personalizar.

5

Haz los commits iniciales

Añade todos los archivos con git add . y haz tu primer commit: git commit -m "init: estructura inicial del repositorio". Luego commits separados por cada parte del proyecto.

6

Conecta y sube a GitHub

Copia la URL de tu repositorio en GitHub y ejecuta los comandos del bloque de terminal de abajo. En segundos tu código estará en internet con una URL pública que puedes compartir.

7

Aplica el flujo de branches en tu repo

Crea una rama feat/notas-git, agrega el archivo modulo2-git-github/notas-comandos.md, haz commits, sube la rama y abre un Pull Request. Luego fusiónalo a main. ¡Tu primer PR real completado!

Comandos para conectar y subir a GitHub

Terminal — Conectar repo local con GitHub y hacer push

# 1. Añadir todos los archivos y hacer el commit inicial $ git add . $ git commit -m "init: estructura inicial del repositorio" # 2. Renombrar la rama principal a 'main' $ git branch -M main # 3. Conectar con el repositorio en GitHub $ git remote add origin https://github.com/TU_USUARIO/fundamentos-programacion.git # 4. Subir el código a GitHub por primera vez $ git push -u origin main Branch 'main' set up to track remote branch 'main' from 'origin'. To https://github.com/TU_USUARIO/fundamentos-programacion.git * [new branch] main -> main # ✅ Para subidas futuras simplemente usa: $ git push

Tu README.md: la plantilla completa

📄 README.md

🧮 Fundamentos de Programación — Módulo 1

Python 3.x Git Nivel principiante

Proyecto del Módulo 1 del curso de Fundamentos de Programación.

Incluye una calculadora de operaciones básicas y un sistema de inventario

por consola, desarrollados aplicando variables, operadores, condicionales,

ciclos (while/for) y funciones.

📁 Estructura del proyecto

modulo1-fundamentos/

├── calculadora_inventario.py # proyecto principal

└── ejercicios/ # prácticas por lección

🚀 Cómo ejecutarlo

# Requiere Python 3.x instalado

python modulo1-fundamentos/calculadora_inventario.py

✅ Funcionalidades

- Calculadora: suma, resta, multiplicación y división

- Validación de división por cero

- Inventario: agregar, ver y vender productos

- Alerta automática de stock bajo

- Menú interactivo con ciclo principal

📚 Conceptos aplicados

Variables · Operadores · Condicionales · Ciclos · Funciones

Practica el flujo completo: tu primer PR real

Terminal — Flujo branches + PR en tu propio repositorio

# 1. Crear rama para agregar las notas de Git $ git switch -c feat/notas-git # 2. Crear el archivo de notas $ mkdir modulo2-git-github $ echo "# Mis apuntes de Git" > modulo2-git-github/notas-comandos.md # 3. Commitear los cambios $ git add modulo2-git-github/notas-comandos.md $ git commit -m "docs: agregar apuntes de comandos Git del Módulo 2" # 4. Subir la rama a GitHub $ git push origin feat/notas-git remote: https://github.com/TU_USUARIO/fundamentos-programacion/pull/new/feat/notas-git # 5. Ir a GitHub, abrir el PR con título y descripción, y hacer merge $ git switch main $ git pull origin main $ git branch -d feat/notas-git ✅ ¡Tu primer PR completado!

Lista de verificación: repositorio listo para tu portafolio

• ✅
  Repositorio público en GitHub con nombre descriptivo y URL compartible.
• ✅
  README.md completo con descripción, instrucciones de instalación, funcionalidades y tecnologías.
• ✅
  .gitignore configurado — sin archivos de caché, entornos virtuales ni archivos del SO.
• ✅
  Historial de commits limpio con mensajes en formato Conventional Commits.
• ✅
  Estructura de carpetas organizada separada por módulo.
• ✅
  Al menos un PR completado en el historial — demuestra que sabes trabajar con branches.
• ✅
  Código ejecutable — quien clone el repo puede ejecutarlo con un solo comando de Python.

🎓 Lo que tu portafolio ya dice de ti

Un repositorio bien organizado le dice a cualquier reclutador que eres alguien que escribe código estructurado, documenta su trabajo, entiende el flujo profesional de Git y toma en serio lo que hace. No necesitas años de experiencia para tener un portafolio sólido — necesitas hacerlo correctamente desde el inicio.

🚀 ¿Qué sigue? Módulo 3

Con Git y GitHub dominados, el Módulo 3 entra al núcleo del desarrollo moderno: estructuras de datos avanzadas (listas, diccionarios, conjuntos), manejo de archivos (leer y escribir datos en disco para que el inventario persista entre ejecuciones) y los primeros pasos de la Programación Orientada a Objetos.

🏆

¡Módulo 2 completado!

Dominas Git y GitHub: control de versiones, repositorios, commits, branches, pull requests y publicación de proyectos. Tu portafolio en GitHub ya está vivo.

El Módulo 3 (Estructuras de datos, archivos y POO) te espera.