Git y GitHub para principiantes: guía práctica paso a paso

Git y GitHub se confunden a menudo, pero son cosas distintas. Git es el sistema de control de versiones: un programa que corre en tu ordenador y guarda el historial de cambios de tu código. GitHub es una plataforma web que aloja repositorios de Git en la nube y añade funciones sociales y de colaboración: pull requests, issues, revisiones de código. Podrías usar Git sin GitHub, pero en la práctica casi todo el mundo los usa juntos.

Si vienes de la hoja de ruta para empezar a programar, ya sabes que Git no es opcional: es una de las pocas herramientas que vas a usar literalmente todos los días de tu carrera, sea cual sea el lenguaje o framework con el que trabajes.

Los comandos que usarás el 95% del tiempo

De los muchos comandos que tiene Git, en el día a día la mayoría de programadores se mueven con un puñado reducido. Este es el flujo básico completo, desde crear el repositorio hasta subir tus cambios:

# Crear un repositorio nuevo en la carpeta actual
git init

# O clonar uno que ya existe en GitHub
git clone https://github.com/usuario/proyecto.git

# Ver qué archivos han cambiado
git status

# Preparar los cambios para el próximo commit
git add archivo.py
git add .          # o todos los cambios de golpe

# Guardar esos cambios en el historial, con un mensaje claro
git commit -m "Añade validación de formulario de contacto"

# Subir tus commits al repositorio remoto (GitHub)
git push origin main

# Traer cambios que otros hayan subido al remoto
git pull origin main

Ese ciclo status → add → commit → push es, en esencia, el 95% de tu interacción diaria con Git. Todo lo demás —ramas, merges, resolución de conflictos— se construye encima de esta base.

Ramas: trabajar sin romper lo que ya funciona

Una rama (branch) es una línea de desarrollo independiente. La rama main suele representar el estado estable del proyecto; cuando vas a añadir una funcionalidad o corregir un bug, creas una rama nueva para no tocar directamente ese estado estable.

# Crear una rama nueva y moverte a ella en un solo paso
git checkout -b feature/formulario-contacto

# (alternativa moderna, misma idea)
git switch -c feature/formulario-contacto

# Trabajas, haces commits normales en esa rama...
git add .
git commit -m "Implementa validación de email"

# Subes la rama a GitHub
git push origin feature/formulario-contacto

Una vez la rama está en GitHub, se abre un pull request (PR): una propuesta formal para fusionar esos cambios en main, donde otros programadores pueden revisar el código, dejar comentarios y aprobarlo antes de que se integre. Este flujo de trabajo en equipo se apoya, además, en metodologías de organización como Scrum, que estructuran en qué momento se abren y cierran esas ramas dentro de un sprint.

Un flujo de trabajo real, paso a paso

Así se ve, encadenado, el flujo completo que seguirás en la mayoría de proyectos reales, ya sea en solitario o en equipo:

1. Clonas el repositorio del proyecto (o creas uno nuevo con git init).
2. Creas una rama para tu tarea concreta.
3. Haces cambios en el código y los revisas con git status.
4. Añades los cambios al área de preparación con git add.
5. Confirmas esos cambios con un git commit descriptivo.
6. Subes la rama al remoto con git push.
7. Abres un pull request en GitHub para que se revise.
8. Una vez aprobado, se fusiona en main y borras la rama.

Checklist: tu primer flujo de trabajo con Git

El archivo que todo el mundo olvida: .gitignore

Antes de tu primer commit, crea un archivo .gitignore en la raíz del proyecto. Sirve para decirle a Git qué archivos y carpetas no debe rastrear: dependencias instaladas (node_modules/), archivos de configuración con contraseñas o claves (.env), o archivos temporales del editor. Subir por error un archivo con credenciales a un repositorio público en GitHub es uno de los descuidos de seguridad más comunes, y aparece con razón en cualquier repaso serio del OWASP Top 10.

Conflictos: no son un error, son una conversación

Un conflicto de merge ocurre cuando dos ramas han modificado las mismas líneas de un archivo de forma distinta y Git no puede decidir por sí solo cuál versión conservar. No es un error grave: Git marca claramente las dos versiones dentro del archivo, y tú decides manualmente qué queda, editas el archivo, y haces un commit normal para cerrar el conflicto. Cuanto más pequeños y frecuentes sean tus commits y pull requests, menos conflictos —y más pequeños— vas a tener que resolver.

Por qué esto importa más allá del código

Un historial de commits limpio y un perfil de GitHub activo son, hoy, parte del currículum real de cualquier programador. Tanto si buscas tu primer empleo como si te planteas el camino freelance, un repositorio bien cuidado demuestra algo que ningún certificado puede demostrar por sí solo: que sabes trabajar como se trabaja de verdad en un equipo de desarrollo.