git

Git sin drama: lo que necesitas saber para no arruinar el código de tu equipo

Git tiene fama de complicado.

No es merecida — o al menos, no del todo. Git es complicado cuando no entiendes qué está haciendo. Cuando lo entiendes, la mayoría de los comandos tienen un sentido lógico tan claro que te pregunta por qué no lo viste antes.

Este post no es un manual completo de Git. Es lo que necesitas saber para empezar a usarlo sin miedo — y sin el pánico de hacer algo que rompa el trabajo de tu equipo.

La idea central que lo explica todo

Git es un sistema de control de versiones. En términos simples: es una herramienta que guarda el historial completo de cambios de tu código.

Piénsalo como un documento de Google Docs con historial de versiones — pero para código, mucho más poderoso, y que funciona sin internet.

Cada vez que "guardas" en Git, no solo guardas el estado actual — guardas quién hizo el cambio, cuándo lo hizo, y por qué lo hizo (si escribe un buen mensaje). Eso significa que puedes volver a cualquier punto de la historia de tu proyecto en cualquier momento.

Git no borra nada. Casi todo lo que parece que rompiste, se puede recuperar.

Esa frase sola debería quitarte el 80% del miedo.

Instalación — dos líneas y listo

Si ya tienes Homebrew instalado — y si llegaste hasta aquí probablemente lo tienes desde el post de Homebrew — es tan simple como:

brew install git

# Verificar que quedó instalado
git --version
# git version 2.x.x

Después de instalar, la configuración mínima que necesitas hacer una sola vez:

# Tu nombre y email — aparecen en cada commit que hagas
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

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

Los 7 comandos que usas el 90% del tiempo

No necesitas memorizar 50 comandos. Estos siete cubren prácticamente todo el trabajo diario:

git init — Inicializar un repositorio Convierte cualquier carpeta en un repositorio de Git. Se usa una sola vez al inicio del proyecto.

git init

git clone — Copiar un repositorio existente Descarga un repositorio remoto (de GitHub, GitLab, etc.) a tu máquina.

git clone https://github.com/usuario/repositorio.git

git status — ¿Qué está pasando? El comando más usado. Te dice qué archivos cambiaron, cuáles están listos para guardar, y cuáles no.

git status

git add — Preparar cambios para guardar Selecciona qué cambios quieres incluir en el próximo guardado.

git add archivo.txt        # agregar un archivo específico
git add .                  # agregar todos los cambios

git commit — Guardar los cambios con un mensaje El "guardado real" en Git. Cada commit es un punto en la historia al que puedes volver.

git commit -m "Agrega función de login"

Un buen mensaje de commit describe QUÉ cambia y POR QUÉ — no solo "cambios" o "fix". Tu yo del futuro te lo agradecerá.

git push — Subir cambios al repositorio remoto Envía tus commits locales a GitHub u otro servidor remoto.

git push origin main

git pull — Descargar cambios del repositorio remoto Trae los cambios que otros hicieron al repositorio.

git pull origin main

Ramas — el concepto que cambia todo

Las ramas (branches) son la funcionalidad más poderosa de Git — y la que más confunde al principio.

Una rama es básicamente una copia paralela de tu código donde puedes hacer cambios sin afectar la versión principal. Imagina que puedes abrir una dimensión alternativa de tu proyecto, trabajar ahí, y cuando estés satisfecho — fusionarla con la dimensión original.

# Ver en qué rama estás
git branch

# Crear una nueva rama y moverte a ella
git checkout -b feature/nueva-funcionalidad

# Volver a la rama principal
git checkout main

# Fusionar una rama con la principal
git merge feature/nueva-funcionalidad

La regla de oro que te ahorrará problemas: nunca trabajes directamente en main. Siempre crea una rama para cada funcionalidad o corrección, y fusiona cuando esté lista y probada.

Los errores más comunes — y cómo salir de ellos

"Hice commit de algo que no debería"

# Deshacer el último commit pero mantener los cambios
git reset --soft HEAD~1

# Deshacer el último commit y descartar los cambios
git reset --hard HEAD~1

"Modifiqué un archivo y quiero volver al estado anterior"

git checkout -- archivo.txt

"Tengo cambios sin commit y necesito cambiar de rama"

# Guardar cambios temporalmente sin hacer commit
git stash

# Recuperar los cambios guardados
git stash pop

"¿Quién escribió esta línea y cuándo?"

git blame archivo.txt

Útil para entender el historial de un archivo — y para descubrir que fuiste tú mismo quien escribió esa línea confusa hace tres meses.

git blame tiene un nombre dramático pero es simplemente una herramienta de historial. No culpes a nadie, úsalo para entender.

.gitignore — lo que Git no debería ver

Hay archivos que nunca deberían subir a un repositorio: credenciales, API keys, archivos de configuración local, carpetas de dependencias como node_modules.

El archivo .gitignore le dice a Git qué ignorar:

# Crear el archivo en la raíz del proyecto
touch .gitignore

Un .gitignore básico para proyectos de Node.js:

node_modules/
.env
.DS_Store
*.log

Regla simple: antes de hacer tu primer commit en un proyecto, crea el .gitignore. Arreglar un repositorio que subió archivos que no debería es mucho más tedioso que prevenirlo.

Git con Oh My Zsh — la combinación perfecta

Si seguiste el post de Oh My Zsh, ya tienes el plugin de Git activado por defecto. Eso significa que tienes acceso a una lista de aliases que hacen el trabajo diario mucho más rápido:

Alias	Comando completo
`gst`	`git status`
`ga .`	`git add .`
`gcmsg "mensaje"`	`git commit -m "mensaje"`
`gp`	`git push`
`gl`	`git pull`
`gco -b rama`	`git checkout -b rama`

Una vez que los aprendes, escribir los comandos completos se siente como conducir con el freno de mano puesto.

El flujo de trabajo básico — el que usas todos los días

Resumiendo todo en el ciclo que se repite en cada sesión de trabajo:

# 1. Actualizar tu copia local
git pull origin main

# 2. Crear una rama para lo que vas a hacer
git checkout -b feature/lo-que-vas-a-hacer

# 3. Hacer cambios, agregar y commitear
git add .
git commit -m "Descripción clara de lo que hiciste"

# 4. Subir la rama
git push origin feature/lo-que-vas-a-hacer

# 5. Crear un Pull Request en GitHub para fusionar

Eso es el 90% del trabajo diario con Git. El otro 10% son situaciones especiales que vas aprendiendo según aparecen — y cuando aparecen, ya tienes el contexto para entender qué está pasando.

Por qué vale la pena aprenderlo bien desde el principio

Git tiene una curva de aprendizaje inicial que muchos evitan — y terminan usándolo mal durante años, con miedo de hacer algo que rompa el repositorio.

Dos horas invertidas en entender los fundamentos te ahorran meses de confusión. No es exageración.

Y una vez que lo entiendes bien, se convierte en una de esas herramientas que no puedes imaginar no tener — como la terminal después de perderle el miedo, o Homebrew después de instalarlo por primera vez. 🐱