¿Qué es Git y por qué deberías importarte?

Imagina que estás escribiendo un documento importante. Haces cambios, guardas, al día siguiente te arrepientes de algo y quieres volver a como estaba ayer. O estás trabajando con alguien más y los dos editáis el mismo archivo a la vez.

Git es una máquina del tiempo para tu código. Guarda el historial de cada cambio, te deja volver atrás, trabajar en paralelo sin liarla y sincronizar tu trabajo con otros. No es solo para equipos: aunque trabajes solo, Git te da red de seguridad y orden.

Y sí, Git ≠ GitHub. Git es la herramienta que corre en tu máquina. GitHub (o GitLab, Bitbucket) es donde subes tu código a la nube para hacer backup, compartirlo o colaborar. Primero aprendes Git local, luego lo remoto. Vamos por partes.

Paso 1: Instalar Git (Windows, Mac, Linux)

Windows

1. Ve a git-scm.com/download/win
2. Descarga el instalador (64-bit para casi todos hoy día)
3. Ejecútalo y dale a "Next" en casi todo excepto en estas dos pantallas:

Durante la instalación: elige tu editor (VS Code si lo tienes) y en la pantalla de "Default branch name" selecciona "main".

Resto de opciones: deja los valores por defecto. Termina la instalación.

Mac

Si tienes Homebrew (deberías):

brew install git

O descarga el instalador desde git-scm.com.

Linux (Ubuntu/Debian)

sudo apt update && sudo apt install git

Verifica que funciona

Abre tu terminal (PowerShell, CMD, Terminal, Git Bash...) y escribe:

git --version

Deberías ver algo como git version 2.45.0. Si sale, listo.

Paso 2: Configura tu identidad (solo una vez)

Git necesita saber quién eres para firmar cada commit. Ejecuta:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com

Usa el mismo email que usarás en GitHub/GitLab luego. Para ver tu config:

git config --list

Paso 3: Inicializa tu primer repositorio

Ve a la carpeta de tu proyecto (o crea una de prueba):

cd mis-proyectos
mkdir mi-primer-repo
cd mi-primer-repo
git init

Verás: Initialized empty Git repository in .../.git/

Esa carpeta .git (oculta) es donde Git guarda TODO el historial. No la borres. No la toques. Es tu base de datos.

Paso 4: El ciclo básico — add, commit, status, log

Este es el flujo que repetirás mil veces. Crea un archivo de prueba:

echo "# Mi Proyecto" > README.md

1. git status — ¿qué pasa?

git status

Te dice: "Hay archivos sin rastrear (untracked)". Git los ve, pero aún no los vigila.

2. git add — prepara los cambios

git add README.md

O para añadir todo de golpe:

git add .

Ahora el archivo está en el staging area (zona de preparación). Es como meter cosas en una caja antes de cerrarla y etiquetarla.

3. git commit — guarda la instantánea

git commit -m "Primer commit: añado README"

El flag -m es el mensaje. Escribe mensajes claros: qué hiciste y por qué. Tu yo del futuro te lo agradecerá.

4. git log — mira el historial

git log --oneline --graph --decorate

Verás tu commit con su hash único, autor, fecha y mensaje. --oneline lo hace legible; --graph dibuja ramas (útil luego).

Paso 5: Haz cambios y repite el ciclo

Modifica el README:

echo "Aprendiendo Git paso a paso" >> README.md

Vuelve al ciclo:

git status          # verás "modified: README.md"
git add README.md   # o git add .
git commit -m "Actualizo README con descripción"
git log --oneline   # ahora ves DOS commits

Truco pro: git add -A añade todo (nuevos, modificados, borrados). git commit -am "msg" añade y commitea en uno (solo archivos ya rastreados).

Paso 6: Deshacer cosas (porque pasará)

¿Añadiste algo por error al staging?

git reset HEAD archivo.txt    # lo saca del staging, mantiene cambios
git restore --staged archivo.txt  # forma moderna (Git 2.23+)

¿Quieres tirar los cambios locales de un archivo?

git restore archivo.txt    # vuelve al último commit (CUIDADO: pierdes cambios)

¿El último commit tenía error en el mensaje?

git commit --amend -m "Mensaje corregido"

¿Quieres volver al commit anterior y tirar el último?

git reset --hard HEAD~1    # PELIGROSO: borra historial y cambios

Regla de oro: reset --hard solo en commits tuyos que NO hayas subido a remoto. Si ya hiciste push, usa git revert (crea commit nuevo que deshace el anterior).

Paso 7: Ramas — trabajar en paralelo sin miedo

Por defecto estás en main (antes master). Las ramas te dejan experimentar, arreglar bugs o hacer features sin tocar lo que funciona.

Crear y cambiar de rama

git branch nueva-funcionalidad    # crea rama
git switch nueva-funcionalidad      # cambia a ella (Git 2.23+)
# o el clásico: git checkout nueva-funcionalidad

Corto: git switch -c nueva-funcionalidad crea y cambia en uno.

Ver tus ramas

git branch          # locales
git branch -a       # todas (incluye remotas)

Trabajas en tu rama, commiteas normal

# haces cambios...
git add .
git commit -m "Añado feature X"

Volver a main y traer los cambios (merge)

git switch main
git merge nueva-funcionalidad

Si no hay conflictos, Git hace un "fast-forward" y listo. Si hay conflictos (editaste lo mismo en ambas ramas), Git te lo dice y toca resolver a mano en los archivos marcados. Luego git add . y git commit.

Borrar rama ya mergeada

git branch -d nueva-funcionalidad

Paso 8: Conectar con GitHub (lo justo para empezar)

GitHub es el "remoto": un servidor donde guardas tu repo para backup, compartir o colaborar. GitLab y Bitbucket funcionan igual.

1. Crea cuenta en github.com
2. Crea un repo nuevo (botón "New repository"), nómbralo igual que tu carpeta local, NO marques "Add a README" ni ".gitignore" ni licencia (ya los tienes tú)
3. GitHub te dará comandos. Conecta tu repo local:

git remote add origin https://github.com/TU_USUARIO/TU_REPO.git
git branch -M main          # asegura que tu rama principal se llama main
git push -u origin main     # sube por primera vez (-u vincula la rama)

Te pedirá usuario/contraseña. Usa un Personal Access Token, no tu password. En GitHub: Settings → Developer settings → Personal access tokens → Generate new token (classic) → scopes: repo, workflow. Guárdalo seguro.

Después del primer push, solo necesitas:

git push          # sube commits
git pull          # baja cambios de otros (o tuyos desde otra máquina)

Resumen: tu chuleta diaria

Consejos que me habría gustado saber al principio

• Commit temprano, commit a menudo. Commits pequeños y atómicos (un cambio lógico = un commit) son más fáciles de revisar, revertir y entender.
• Mensajes en presente imperativo: "Añade botón de login" no "Añadí..." ni "Adding...". Estándar de la industria.
• No subas basura. Crea .gitignore desde el día 1: node_modules, .env, dist, .DS_Store, *.log.
• Aprende git diff. Antes de commitear, git diff te muestra qué vas a guardar. git diff --staged lo que ya está en staging.
• Aliases = velocidad. En tu ~/.gitconfig:

  [alias]
    st = status
    co = checkout
    br = branch
    lg = log --oneline --graph --decorate --all
    cm = commit -m
    aa = add -A

  Luego solo escribes git st, git lg, git cm "msg".

¿Y ahora qué?

Ya tienes lo básico para sobrevivir. Lo siguiente (en próximos posts): GitHub/GitLab de verdad (Pull Requests, Issues, code review, CI/CD), flujos de ramas reales (Git Flow, GitHub Flow, trunk-based), y trucos avanzados (rebase interactivo, cherry-pick, bisect, hooks).

Mientras tanto: usa Git en cada proyecto. Aunque sea solo tú. Aunque sea un "hola mundo". El músculo se hace repitiendo.