¿Por qué Git?
Git no es solo una herramienta de backup. Es un sistema de control de versiones distribuido que te permite colaborar con otros developers, experimentar sin miedo a romper nada, y volver al pasado cuando algo sale mal. En 2026, no saber Git es como no saber escribir: técnicamente podés trabajar, pero vas a tener problemas graves en cuanto trabajes con alguien más.
GitHub, por su parte, es la plataforma social de Git. El repositorio remoto donde vive tu código, donde otros pueden verlo, contribuir, y donde se integran las herramientas de CI/CD que automatizan tus deploys. Son dos cosas distintas: Git es el sistema, GitHub es la plataforma.
Conceptos clave.
Antes de los comandos, los conceptos. Un repositorio es la carpeta de tu proyecto con todo el historial de cambios. Un commit es una foto instantánea del estado de tu código en un momento dado. Un branch es una línea paralela de desarrollo. Un remote es la copia del repositorio en un servidor (como GitHub).
El flujo básico de trabajo es siempre el mismo: modificás archivos, los preparás con git add, los commitás con git commit, y los subís al remote con git push. Cuando querés traer cambios del remote, usás git pull. Simple en teoría, complejo en la práctica cuando trabajás con más personas.
Commits que importan.
Un buen commit tiene dos características: es atómico (un solo cambio lógico) y tiene un mensaje descriptivo. El mensaje debería completar la frase "Si aplico este commit, este proyecto va a...". Nada de "fix", "changes", o el clásico "asdfg". Esos mensajes son inútiles tres meses después cuando buscás cuándo y por qué se rompió algo.
La convención más usada hoy es Conventional Commits: feat: agregar autenticación con Google, fix: corregir cálculo de total con descuento, refactor: extraer lógica de validación a función separada. Esta convención permite generar changelogs automáticos y hace el historial legible para humanos y herramientas.
feat:— nueva funcionalidadfix:— corrección de bugrefactor:— reorganización sin cambio de comportamientodocs:— cambios en documentaciónchore:— mantenimiento, dependencias, configuración
Branches y flujos.
Una branch te permite desarrollar una funcionalidad de forma aislada sin afectar el código principal. La branch principal suele llamarse main (o master en repos más viejos) y debería contener siempre código estable y deployable. Para cada nueva feature o fix, creás una branch, trabajás en ella, y la mergeas de vuelta cuando está lista.
El flujo más usado en equipos pequeños es GitHub Flow: main siempre es deployable, cada cambio viene de una branch de feature, y esa branch se mergea via Pull Request con review. Para proyectos más grandes existe Git Flow con branches de develop, release y hotfix, aunque suele ser sobre-ingeniería para la mayoría de proyectos.
Pull Requests.
Un Pull Request (PR) es una propuesta de mergeo: le decís al equipo "tengo estos cambios listos, revísenlos antes de integrarlos". Los PRs son el corazón de la colaboración en GitHub. Un buen PR tiene una descripción clara de qué hace y por qué, referencia el issue que resuelve, y es pequeño (menos de 400 líneas cambiadas es el ideal).
El code review en un PR no es para buscar errores de sintaxis (eso lo hacen el linter y los tests). Es para asegurarse de que la solución tiene sentido arquitectónicamente, que no introduce deuda técnica innecesaria, y para compartir conocimiento del codebase entre el equipo. Aprendés más en un buen code review que en muchos tutoriales.
Merge conflicts.
Los conflictos ocurren cuando dos personas modificaron las mismas líneas de código en ramas distintas. Git no sabe cuál versión es la correcta, así que te muestra ambas y te pide que decidas. No son tan terribles como parecen al principio, pero sí requieren atención para no pisar el trabajo de alguien más.
La mejor estrategia para minimizar conflictos: hacé branches cortas (idealmente 1-3 días de trabajo), sincronizate frecuentemente con git pull --rebase origin main, y comunicá con tu equipo cuando vayas a modificar archivos compartidos. Los conflictos en archivos de lock (package-lock.json, yarn.lock) son los más frecuentes y generalmente se resuelven regenerando el archivo.
Buenas prácticas.
Nunca trabajes directamente en main. Siempre creá una branch para tus cambios. Hacé commits frecuentes pero significativos: no un commit gigante al final del día, ni un commit por cada línea. Añadí un .gitignore desde el inicio para no commitear node_modules, archivos .env, o carpetas de build.
Para los mensajes de commit, escribilos en imperativo y en el idioma del equipo. Si el equipo habla español, escribilos en español. Revisá con git log --oneline si el historial cuenta una historia coherente de cómo evolucionó el proyecto. Si parece una lista de notas sin sentido, trabajá en tus mensajes de commit.