Git y GitHub Tutorial Completo para Principiantes

Git es la herramienta que todo desarrollador necesita dominar — sin excepción. No importa si trabajas solo o en equipo, si haces frontend o backend, Git es el sistema de control de versiones que usa el 95% de la industria. En esta guía completa vas a aprender Git y GitHub desde cero, con los comandos y workflows que realmente uso a diario en proyectos profesionales.

¿Qué es Git y por qué es imprescindible?

Git es un sistema de control de versiones distribuido creado por Linus Torvalds (sí, el mismo creador de Linux) en 2005. Te permite:

• Rastrear cada cambio que haces en tu código, línea por línea
• Volver a cualquier versión anterior si algo sale mal
• Trabajar en equipo sin pisar el trabajo de otros
• Experimentar con ramas sin arriesgar el código estable
• Mantener un historial completo de quién cambió qué y por qué

GitHub, por otro lado, es una plataforma en la nube que aloja repositorios Git. Además del hosting, ofrece herramientas de colaboración como Pull Requests, Issues, Actions (CI/CD) y más. Otros alternativas son GitLab y Bitbucket.

Instalación y configuración inicial

Instalar Git

Windows: Descarga desde git-scm.com o instala con winget:

winget install --id Git.Git -e --source winget

macOS:

brew install git

Linux (Ubuntu/Debian):

sudo apt update && sudo apt install git

Verifica la instalación:

git --version
# git version 2.44.0 o superior

Configuración obligatoria (una sola vez)

Git necesita saber quién eres para registrar cada commit:

# Tu nombre (aparecerá en cada commit)
git config --global user.name "Tu Nombre"

# Tu email (debe coincidir con tu cuenta de GitHub)
git config --global user.email "tu@email.com"

# Establecer la rama principal como "main" (estándar moderno)
git config --global init.defaultBranch main

# Editor por defecto (VS Code en este caso)
git config --global core.editor "code --wait"

# Verificar tu configuración
git config --list

Conceptos fundamentales de Git

Antes de ejecutar comandos, necesitas entender las 3 áreas de Git:

1. Working Directory (tu carpeta de trabajo): Donde editas archivos normalmente.
2. Staging Area (área de preparación): Donde seleccionas qué cambios van en el próximo commit. Piensa en ella como una "lista de empaque".
3. Repository (historial): Donde Git guarda permanentemente los snapshots (commits) de tu proyecto.

El flujo es siempre: editar → agregar al staging → hacer commit.

Tu primer repositorio

# Crear un proyecto nuevo
mkdir mi-proyecto && cd mi-proyecto

# Inicializar Git en esta carpeta
git init

# Crear un archivo
echo "# Mi Proyecto" > README.md

# Ver el estado (Git detecta el archivo nuevo)
git status

# Agregar el archivo al staging area
git add README.md

# Hacer tu primer commit
git commit -m "Primer commit: agregar README"

# Ver el historial
git log --oneline

Comandos de estado que usarás constantemente

# Ver qué archivos han cambiado
git status

# Ver las diferencias en los archivos modificados
git diff

# Ver las diferencias de archivos en staging
git diff --staged

# Ver el historial de commits (formato compacto)
git log --oneline

# Ver historial con gráfico de ramas
git log --oneline --graph --all

El arte del commit

Un buen commit es atómico (un solo cambio lógico) y tiene un mensaje descriptivo:

# Agregar archivos específicos
git add archivo1.js archivo2.js

# Agregar todos los archivos modificados (no los nuevos)
git add -u

# Agregar todo (modificados + nuevos)
git add .

# Hacer commit con mensaje descriptivo
git commit -m "Agregar validación de email en formulario de registro"

# Ver qué incluye un commit específico
git show abc1234

Convenciones para mensajes de commit

La convención más usada es Conventional Commits:

feat: agregar autenticación con Google OAuth
fix: corregir error de validación en campo email
docs: actualizar instrucciones de instalación
style: formatear código con Prettier
refactor: simplificar lógica de cálculo de precios
test: agregar tests para el módulo de pagos
chore: actualizar dependencias a última versión

Ramas (Branches): el superpoder de Git

Las ramas te permiten trabajar en funcionalidades nuevas sin afectar el código principal. En mi experiencia, es la característica más importante de Git.

# Ver las ramas existentes (* indica la actual)
git branch

# Crear una rama nueva
git branch nueva-funcionalidad

# Cambiar a esa rama
git switch nueva-funcionalidad

# Atajo: crear y cambiar en un solo comando
git switch -c otra-funcionalidad

# Trabajar en la rama...
echo "código nuevo" > feature.js
git add . && git commit -m "feat: agregar nueva funcionalidad"

# Volver a main
git switch main

# Fusionar los cambios de la rama
git merge nueva-funcionalidad

# Eliminar la rama (ya no la necesitas)
git branch -d nueva-funcionalidad

Estrategias de branching

Para proyectos en equipo, la estrategia más práctica es GitHub Flow:

1. main siempre tiene código estable y desplegable
2. Para cada feature/fix, creas una rama desde main
3. Trabajas en tu rama y haces commits
4. Abres un Pull Request en GitHub
5. El equipo revisa el código
6. Se fusiona a main y se elimina la rama

# Flujo típico de trabajo diario
git switch main
git pull origin main              # Actualizar con los últimos cambios
git switch -c feature/login-page  # Crear rama para tu tarea
# ... trabajar, hacer commits ...
git push -u origin feature/login-page  # Subir tu rama a GitHub
# Abrir Pull Request en GitHub

Resolver conflictos de merge

Los conflictos ocurren cuando dos personas modifican las mismas líneas del mismo archivo. Git no puede decidir automáticamente qué versión mantener y te pide que lo resuelvas manualmente:

# Cuando haces merge y hay conflicto, Git te muestra esto en el archivo:
<<<<<<< HEAD
const precio = calcularPrecio(producto);
=======
const precio = obtenerPrecioConDescuento(producto);
>>>>>>> feature/descuentos

Para resolverlo:

1. Abre el archivo con conflicto en tu editor
2. Elige qué código mantener (o combina ambos)
3. Elimina los marcadores <<<<<<<, =======, >>>>>>>
4. Guarda el archivo
5. Haz git add del archivo resuelto y luego git commit

# Después de resolver manualmente:
git add archivo-con-conflicto.js
git commit -m "fix: resolver conflicto de merge en cálculo de precios"

Tip: VS Code tiene una interfaz visual excelente para resolver conflictos — te muestra ambas versiones lado a lado y te permite elegir con un click.

Conectar con GitHub

Crear cuenta y repositorio

1. Crea una cuenta en github.com
2. Click en "New repository" (botón verde)
3. Dale un nombre y descripción
4. No inicialices con README si ya tienes un proyecto local

Configurar SSH (recomendado)

SSH evita tener que escribir tu contraseña cada vez que haces push/pull:

# Generar clave SSH
ssh-keygen -t ed25519 -C "tu@email.com"

# Copiar la clave pública
# Windows:
clip < ~/.ssh/id_ed25519.pub
# macOS:
pbcopy < ~/.ssh/id_ed25519.pub
# Linux:
cat ~/.ssh/id_ed25519.pub

Pega la clave en GitHub → Settings → SSH and GPG keys → New SSH key. Sigue la guía oficial de SSH en GitHub para más detalles.

Subir tu proyecto a GitHub

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

# Subir tu código (primera vez)
git push -u origin main

# Las siguientes veces solo necesitas:
git push

Clonar un repositorio existente

# Descargar un proyecto de GitHub
git clone git@github.com:usuario/proyecto.git

# Esto crea una carpeta con todo el código e historial
cd proyecto
git log --oneline

Pull Requests: colaboración profesional

Un Pull Request (PR) es la forma estándar de proponer cambios en un proyecto. El flujo:

# 1. Crear rama y trabajar
git switch -c fix/error-login
# ... hacer cambios y commits ...

# 2. Subir la rama a GitHub
git push -u origin fix/error-login

# 3. En GitHub, click en "Compare & pull request"
# 4. Escribir descripción del cambio
# 5. Asignar revisores
# 6. Esperar aprobación y hacer merge

Un buen PR tiene:

• Título claro y conciso
• Descripción de qué cambia y por qué
• Screenshots si hay cambios visuales
• Referencia al issue que resuelve: "Closes #42"

El archivo .gitignore

Hay archivos que nunca deben subirse al repositorio. Crea un archivo .gitignore en la raíz:

# Dependencias
node_modules/
vendor/

# Variables de entorno (contienen secretos)
.env
.env.local
.env.production

# Archivos del sistema operativo
.DS_Store
Thumbs.db

# Archivos de IDE
.vscode/settings.json
.idea/

# Builds y compilados
dist/
build/
*.min.js

# Logs
*.log
npm-debug.log*

Consulta github/gitignore para plantillas específicas de cada lenguaje y framework.

Comandos de emergencia: deshacer errores

Todos cometemos errores. Estos comandos te salvarán más de una vez:

# Deshacer cambios en un archivo (antes de add)
git checkout -- archivo.js

# Quitar un archivo del staging (después de add, antes de commit)
git restore --staged archivo.js

# Corregir el último commit (cambiar mensaje o agregar archivos)
git commit --amend -m "Mensaje corregido"

# Deshacer el último commit (mantiene los cambios)
git reset --soft HEAD~1

# Deshacer el último commit (descarta los cambios)
git reset --hard HEAD~1

# Ver historial de TODO lo que hiciste (incluso resets)
git reflog

# Recuperar un commit "perdido" usando reflog
git reset --hard abc1234

Regla de oro: nunca hagas git reset --hard o git push --force en ramas compartidas con otros. Puedes reescribir su trabajo.

Stash: guardar trabajo temporal

Estás trabajando en algo y te piden que arregles un bug urgente en otra rama. No puedes cambiar de rama con cambios sin commit. La solución: git stash.

# Guardar cambios temporalmente
git stash

# Ahora puedes cambiar de rama limpiamente
git switch main
# ... arreglar el bug ...
git switch mi-rama

# Recuperar tus cambios guardados
git stash pop

# Ver la lista de stashes guardados
git stash list

# Aplicar un stash específico sin eliminarlo
git stash apply stash@{0}

Cheat sheet de comandos Git

Próximos pasos

Con estos fundamentos puedes trabajar de forma profesional con Git y GitHub. Para profundizar, te recomiendo:

• GitHub Actions: Automatiza tests, builds y deployments directamente desde tu repositorio.
• Learn Git Branching: Juego interactivo para practicar branching y merging visualmente.
• Pro Git (libro oficial): El libro definitivo de Git, gratuito y en español.
• Git rebase: Técnica avanzada para mantener un historial lineal y limpio.

Git tiene una curva de aprendizaje inicial, pero una vez que dominas estos comandos básicos, se convierte en algo automático. Mi consejo: usa Git desde el primer día de cualquier proyecto, aunque sea personal. La práctica diaria es lo que realmente consolida el conocimiento.