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

Git & GitHub · M2

0%

Módulo 2 · Parte 1

⏳ Parte 2 (próximamente)

✅ Módulo 1 completado

🚀 Proyecto del módulo

Publicar en GitHub

Disponible en Parte 2

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

Controla tu código
como un profesional

Git es la herramienta más usada en la industria del software. Todo programador, sin excepción, la usa a diario. En esta primera parte aprenderás qué es, por qué existe y cómo empezar a usarla desde hoy.

3Lecciones hoy

5Total módulo 2

3Mini quizzes

+10Comandos reales

🔖 Marcadores

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

L1

Fundamental

¿Qué es el control de versiones?

Antes de tocar un solo comando, necesitas entender el problema que resuelve Git. Porque Git no es solo una herramienta para programadores avanzados: es la solución a un problema que todos hemos tenido alguna vez.

😰

¿Te suena familiar esta situación?

Tienes una carpeta llamada proyecto_final con archivos como proyecto_final_v2.py, proyecto_final_BUENO.py, proyecto_final_ESTE_SI.py, proyecto_final_ULTIMO_DE_VERDAD.py. No sabes cuál es el más nuevo, no recuerdas qué cambió en cada uno, y si algo se rompe no puedes volver atrás fácilmente. Eso es vivir sin control de versiones.

Un sistema de control de versiones (VCS) es una herramienta que registra automáticamente cada cambio que haces en tus archivos a lo largo del tiempo. Es como tener una máquina del tiempo para tu código: puedes ver exactamente qué cambió, cuándo, quién lo cambió y por qué, y puedes volver a cualquier punto anterior en segundos.

¿Qué problema resuelve exactamente?

⏪

Volver atrás

Rompiste algo que funcionaba. Con Git recuperas la versión anterior en un comando, sin perder nada.

👥

Trabajar en equipo

Dos personas pueden modificar el mismo proyecto al mismo tiempo sin pisarse el trabajo mutuamente.

🔍

Historial completo

Sabes exactamente qué cambió, en qué fecha y quién lo hizo. Útil para auditar bugs y decisiones.

🧪

Experimentar sin miedo

Prueba ideas nuevas en ramas separadas. Si no funcionan, las descartas sin afectar el código principal.

Git vs. GitHub: no son lo mismo

Esta confusión es muy común. Aquí la diferencia clara de una vez:

	Git	GitHub
¿Qué es?	Programa que se instala en tu computadora	Sitio web (plataforma en la nube)
¿Dónde vive?	En tu máquina local	En internet (servidores de Microsoft)
¿Para qué sirve?	Registrar y gestionar el historial de cambios	Almacenar y compartir repositorios Git online
¿Se necesitan juntos?	Git funciona solo. GitHub necesita Git. Son complementarios.
Analogía	El software de edición de fotos (Photoshop)	La galería online donde subes las fotos (Instagram)

Una breve historia: por qué existe Git

Git fue creado en 2005 por Linus Torvalds, el mismo creador del kernel Linux. El equipo que desarrollaba Linux necesitaba coordinar los cambios de miles de contribuidores de todo el mundo. Las herramientas de la época no podían manejarlo. Torvalds decidió construir una herramienta nueva desde cero en solo dos semanas. El resultado fue Git, que hoy es usado por más de 100 millones de desarrolladores en el mundo.

💡 Dato de la industria

Según la encuesta de Stack Overflow 2024, el 97.9% de los desarrolladores profesionales usa Git como sistema de control de versiones. No es una opción — es el estándar absoluto. Aprender Git no es aprender una herramienta más: es aprender el idioma del desarrollo de software moderno.

Instalación de Git: primeros pasos reales

Terminal — Verificar e instalar Git

# Paso 1: verificar si ya tienes Git instalado $ git --version git version 2.43.0 # ✅ ya está instalado # Si no está instalado: # Windows → descarga desde: https://git-scm.com # Mac → ejecuta en terminal: brew install git # Linux → ejecuta: sudo apt install git # Paso 2: configurar tu identidad (solo se hace UNA vez) $ git config --global user.name "Tu Nombre" $ git config --global user.email "tu@email.com" # Verificar que quedó guardado $ git config --list user.name=Tu Nombre user.email=tu@email.com

⚠ Importante: configura tu identidad

Git usa tu nombre y email para firmar cada cambio que hagas. Esta información queda registrada permanentemente en el historial del proyecto. Usa el mismo email que usarás para crear tu cuenta de GitHub — eso vinculará tus contribuciones a tu perfil automáticamente.

🧠 Quiz: Tienes un proyecto funcionando y quieres probar una idea nueva que podría romperlo. ¿Qué ventaja te da Git en este escenario?

L2

Fundamental

Repositorios: el contenedor de tu proyecto

Un repositorio (o "repo") es la carpeta de tu proyecto convertida en un espacio gestionado por Git. No es solo la carpeta con tus archivos: es esa carpeta más todo el historial de cambios, la configuración y los metadatos que Git necesita para hacer su trabajo.

📚

Analogía: el repositorio es un libro con historial de ediciones

Imagina un libro que guarda no solo la versión final, sino todas las versiones anteriores: cada borrador, cada corrección, con fecha y nombre del editor que la hizo. Puedes abrir el libro en cualquier versión anterior y ver exactamente cómo estaba en ese momento. Eso es un repositorio Git: tu proyecto más su historia completa.

Repositorio local vs. repositorio remoto

💻

Repositorio local

Vive en tu computadora. Es el que creas con git init. Puedes trabajar sin internet. Contiene todo el historial.

☁️

Repositorio remoto

Vive en internet (GitHub, GitLab, Bitbucket). Es la copia "oficial" del proyecto que comparte todo el equipo.

🔄

Sincronización

git push sube cambios del local al remoto. git pull trae cambios del remoto a tu local.

Crear tu primer repositorio local

Terminal — Crear e inicializar un repositorio

# Paso 1: crear la carpeta del proyecto $ mkdir mi-proyecto-python $ cd mi-proyecto-python # Paso 2: inicializar Git en esa carpeta $ git init Initialized empty Git repository in /mi-proyecto-python/.git/ # git init crea una carpeta oculta llamada .git # AHÍ VIVE TODO el historial y configuración de Git # NO borres esa carpeta o perderás todo el historial # Verificar el estado actual del repositorio $ git status On branch main No commits yet nothing to commit (create/copy files and use "git add" to track)

La carpeta .git: el corazón oculto

Cuando ejecutas git init, Git crea una carpeta oculta llamada .git dentro de tu proyecto. Esta carpeta es la base de datos donde Git guarda absolutamente todo: el historial completo, las ramas, la configuración, los objetos comprimidos con cada versión de cada archivo.

⚠ Regla de oro

Nunca borres la carpeta .git manualmente. Hacerlo equivale a destruir todo el historial del proyecto. Si accidentalmente la borras, pierdes el control de versiones completamente — solo quedan los archivos actuales sin ningún historial.

Clonar un repositorio existente

Si un proyecto ya existe en GitHub (tuyo o de otra persona), no necesitas git init. Usas git clone para descargar una copia completa — archivos e historial incluidos — a tu computadora.

Terminal — Clonar un repositorio de GitHub

# Sintaxis: git clone [URL del repositorio] $ git clone https://github.com/usuario/nombre-repo.git Cloning into 'nombre-repo'... remote: Enumerating objects: 84, done. remote: Counting objects: 100% (84/84), done. Receiving objects: 100% (84/84), 24.5 KiB | 1.2 MiB/s, done. # git clone hace tres cosas automáticamente: # 1. Crea una carpeta con el nombre del repositorio # 2. Descarga todos los archivos y el historial completo # 3. Configura la conexión al repositorio remoto (origin) $ cd nombre-repo $ git log --oneline a3f8c12 feat: agregar módulo de inventario b19e4a1 fix: corregir división por cero en calculadora c0d7e33 init: estructura inicial del proyecto

El archivo .gitignore: qué NO debe rastrear Git

No todo lo que está en tu carpeta de proyecto debe ser guardado en el repositorio. Archivos temporales, contraseñas, configuraciones locales, dependencias descargadas — todo eso debe ser ignorado. Para eso existe .gitignore: un archivo de texto donde le dices a Git qué carpetas y archivos debe ignorar completamente.

.gitignore — Ejemplo para proyecto Python

# Archivos de configuración local y secretos
.env                    # variables de entorno (contraseñas, API keys)
config_local.py         # configuración específica de tu máquina

# Entorno virtual de Python
venv/
env/
__pycache__/            # archivos compilados de Python
*.pyc                   # archivos bytecode

# Archivos del sistema operativo
.DS_Store               # Mac: metadatos de carpeta
Thumbs.db               # Windows: thumbnails

# Archivos de editores
.vscode/
.idea/

# Logs y bases de datos temporales
*.log
*.sqlite

✅ GitHub tiene plantillas

Al crear un repositorio en GitHub, la plataforma te ofrece elegir una plantilla de .gitignore según el lenguaje de tu proyecto (Python, JavaScript, Java, etc.). Úsala siempre — contiene todos los patrones comunes que necesitas ignorar para ese ecosistema, preconfigurados y listos.

Comandos esenciales para gestionar un repo

Comando	¿Qué hace?	Cuándo usarlo
git init	Inicializa un repositorio nuevo en la carpeta actual	Al empezar un proyecto desde cero
git clone [url]	Descarga un repositorio existente de internet	Al incorporarte a un proyecto existente
git status	Muestra el estado actual de los archivos	Siempre — antes de cualquier otra acción
git log	Muestra el historial de commits	Para revisar qué cambios se han hecho
git remote -v	Muestra los repositorios remotos configurados	Para verificar la conexión con GitHub

🧠 Quiz: ¿Qué diferencia hay entre git init y git clone?

L3

Core skill

Commits: fotografías del historial de tu código

Un commit es una instantánea (snapshot) del estado de tu proyecto en un momento específico del tiempo. Cada vez que haces un commit, Git guarda para siempre cómo estaba tu código en ese instante, junto con un mensaje que describe qué cambió y por qué. Los commits son la unidad fundamental de Git: todo lo demás gira alrededor de ellos.

📸

Analogía: el commit es una foto con pies de foto

Imagina que cada vez que terminas una parte importante de tu proyecto tomas una fotografía de todo el código. Cada foto tiene un pie de foto que explica qué hiciste: "Agregué la función de suma", "Corregí el error de división por cero", "Completé el módulo de inventario". Si algo sale mal más adelante, simplemente buscas en el álbum la última foto buena y restauras a partir de ahí. Eso es el historial de commits.

El flujo de trabajo de Git: los 3 estados

Antes de hacer un commit, Git tiene un sistema de tres pasos que confunde a muchos principiantes. Entenderlo bien es clave para todo lo que viene después:

Untracked

Sin rastrear

El archivo existe en la carpeta pero Git no lo conoce todavía. Recién creado.

Modified

Modificado

Git ya lo rastreaba y detectó cambios, pero aún no están listos para guardar.

Staged

En área de staging

Marcado con git add. Listo y esperando ser incluido en el próximo commit.

Committed

Guardado

El cambio fue guardado permanentemente en el historial con git commit.

💡 ¿Por qué existe el área de staging?

El área de staging (o "index") te da control preciso sobre qué incluir en cada commit. Puedes haber modificado 5 archivos pero querer guardar solo 2 de ellos en este commit, y los otros 3 en el siguiente. Sin staging, tendrías que commitear todo o nada. Con staging, eliges exactamente qué va en cada "foto".

El flujo completo: de archivo a commit

Terminal — Ciclo completo: crear, añadir y commitear

# Estado inicial del repositorio $ git status On branch main nothing to commit, working tree clean # Creamos un archivo nuevo $ echo "print('Hola mundo')" > hola.py $ git status Untracked files: hola.py # ← Git lo ve, pero no lo rastrea aún # PASO 1: añadir al área de staging $ git add hola.py $ git status Changes to be committed: new file: hola.py # ← ahora está en staging (verde) # PASO 2: hacer el commit con un mensaje descriptivo $ git commit -m "feat: agregar archivo inicial hola.py" [main (root-commit) a1b2c3d] feat: agregar archivo inicial hola.py 1 file changed, 1 insertion(+) create mode 100644 hola.py # Verificar el historial $ git log --oneline a1b2c3d feat: agregar archivo inicial hola.py

Comandos de git add: cuándo usar cada variante

Comando	¿Qué añade al staging?	Cuándo usarlo
git add nombre.py	Solo ese archivo específico	Cuando quieres control preciso de qué incluir
git add src/	Todos los archivos dentro de una carpeta	Cuando un módulo completo está listo
git add .	Todos los archivos modificados en el directorio actual	Cuando todos los cambios van en el mismo commit
git add -p	Te pregunta archivo por archivo qué añadir	Para máximo control en proyectos complejos

Cómo escribir buenos mensajes de commit

El mensaje del commit es para los humanos, no para Git. Un mal mensaje hace el historial inútil; uno bueno lo convierte en documentación automática del proyecto. La convención más usada en la industria se llama Conventional Commits:

Formato — Conventional Commits

# Formato: tipo(alcance opcional): descripción breve

# Tipos más comunes:
feat:     nueva funcionalidad
fix:      corrección de un bug
docs:     cambios en documentación
refactor: mejora de código sin cambiar funcionalidad
test:     agregar o corregir tests
chore:    tareas de mantenimiento (configs, dependencias)

# Ejemplos reales del proyecto calculadora+inventario:
feat: agregar función calcular() con los 4 operadores
fix: corregir error de división por cero en calcular()
feat(inventario): implementar función agregar_producto()
feat(inventario): agregar alerta de stock bajo en ver_inventario()
refactor: extraer lógica del menú a función main()
docs: agregar comentarios explicativos a todas las funciones

# ❌ Mensajes malos (no hagas esto):
git commit -m "cambios"
git commit -m "arreglé cosas"
git commit -m "asdfgh"
git commit -m "WIP"      # solo en ramas propias, nunca en main

El historial de commits: la línea del tiempo de tu proyecto

Así se vería el historial ideal del proyecto de la calculadora e inventario que construiste en el Módulo 1, si hubieras ido haciendo commits en cada etapa:

1

e3a1f00 · hace 5 días

init: estructura inicial del proyecto

Archivos creados: calculadora_inventario.py, .gitignore, README.md

2

a2c9d11 · hace 4 días

feat: implementar función calcular() con 4 operadores

1 archivo modificado, +18 líneas añadidas

3

b4f0e22 · hace 3 días

fix: agregar validación de división por cero

1 archivo modificado, +4 líneas añadidas, +1 modificada

4

c6d3a33 · hace 2 días

feat(inventario): agregar funciones CRUD del inventario

1 archivo modificado, +42 líneas añadidas

5

d8e5b44 · ayer

feat: integrar calculadora e inventario en menú main()

1 archivo modificado, +20 líneas añadidas — proyecto completado ✅

Comandos para inspeccionar y deshacer commits

Terminal — Ver historial y corregir errores

# Ver historial completo (q para salir) $ git log # Versión compacta: una línea por commit $ git log --oneline d8e5b44 feat: integrar calculadora e inventario en menú main() c6d3a33 feat(inventario): agregar funciones CRUD del inventario b4f0e22 fix: agregar validación de división por cero # Ver qué cambió en el último commit $ git show HEAD # Ver qué cambió entre el estado actual y el staging $ git diff # Corregir el mensaje del último commit (¡antes de hacer push!) $ git commit --amend -m "feat: mensaje corregido" # Quitar un archivo del staging (sin borrar los cambios) $ git restore --staged archivo.py # Descartar cambios de un archivo (⚠ IRREVERSIBLE) $ git restore archivo.py

🚀 Conexión con el proyecto final

En la Parte 2 del módulo tomarás exactamente este historial de commits y lo publicarás en GitHub. Cada commit que hagas ahora aparecerá en tu perfil público como evidencia de tu trabajo. Practica hacer commits bien escritos desde hoy — es tu portafolio profesional en construcción.

🧠 Quiz: Modificaste 3 archivos pero solo quieres incluir 2 de ellos en este commit. ¿Cuál es el flujo correcto?

⏳

Próximamente

Módulo 2 · Parte 2: Branches, Pull Requests y Proyecto Final

Completaste la primera mitad del Módulo 2. Ya dominas los tres conceptos que usan el 80% de los desarrolladores el 80% del tiempo. Lo que viene en la Parte 2 es lo que separa a un usuario básico de Git de alguien que trabaja como un profesional en equipo.

🔒

Parte 2 — Disponible próximamente

Estas lecciones completan el módulo y desbloquean el proyecto final

L4 · Branches L5 · Pull Requests 🏆 Proyecto Final

¿Qué aprenderás en la Parte 2?

🌿

L4 · Branches (Ramas)

Crear líneas de trabajo paralelas. Desarrollar nuevas funciones sin tocar el código principal hasta que estén listas.

🔀

L5 · Pull Requests

El mecanismo de revisión de código en equipos. Cómo proponer cambios, revisarlos y fusionarlos de forma ordenada.

🚀

🏆 Proyecto Final

Publicar todos los ejercicios del Módulo 1 en GitHub con un repositorio bien estructurado, commits limpios y README profesional.

Tarea para antes de la Parte 2

Para aprovechar al máximo la siguiente entrega, completa estos pasos antes de continuar:

1. Instala Git en tu computadora si aún no lo tienes (git --version para verificar).
2. Crea una cuenta gratuita en GitHub en github.com. Usa el mismo email con el que configuraste Git.
3. Inicializa un repositorio local para el proyecto del Módulo 1 (git init dentro de la carpeta del proyecto).
4. Haz tus primeros commits: añade los archivos con git add . y haz un commit inicial con un mensaje descriptivo.
5. Practica el flujo: modifica un archivo, añádelo al staging, haz un segundo commit. Repite hasta que el flujo sea natural.

✅ Lo que ya eres capaz de hacer

Con lo aprendido en esta parte ya puedes: crear repositorios locales, rastrear cambios en tu código, hacer commits con mensajes profesionales, e inspeccionar el historial de tu proyecto. Eso ya te pone por delante de muchos programadores autodidactas.

🔮 Vista previa del Proyecto Final

Al terminar la Parte 2 tendrás un repositorio público en GitHub con el proyecto de la Calculadora + Inventario del Módulo 1, organizado con commits bien escritos, un README.md profesional que explica el proyecto, y todo correctamente estructurado con .gitignore. Ese repositorio será el inicio de tu portafolio como desarrollador.

🎯

¡Parte 1 completada!

Dominaste los fundamentos de Git: control de versiones, repositorios y commits. Ya piensas como un desarrollador que cuida su código.

La Parte 2 (Branches, Pull Requests y Proyecto Final en GitHub) se publicará pronto.