¿Cuáles son las buenas prácticas de Git en proyectos profesionales?

Las buenas prácticas de Git son convenciones que los equipos profesionales siguen para mantener un historial limpio, colaborar sin conflictos y entregar software confiable.

En empresas como Mercado Libre o FEMSA, decenas de desarrolladores trabajan sobre el mismo repositorio. Sin reglas claras, el historial se vuelve un caos. Con las prácticas correctas, cualquier persona del equipo puede entender qué cambió, cuándo y por qué.

Mensajes de commit profesionales

Un mensaje de commit bien escrito es la documentación más rápida que existe. Describe exactamente qué cambió y por qué, en una sola línea.

Formato recomendado (Conventional Commits):

tipo(alcance): descripción corta en imperativo

Los tipos más usados son:

Ejemplos correctos:

feat(carrito): agregar validación de cupones de descuento
fix(pagos): corregir cálculo de IVA en facturas CFDI
docs(readme): actualizar instrucciones de instalación en Linux

Ejemplos incorrectos:

arreglos
cambios varios
WIP
no sé qué hice pero funciona

Un mensaje vago no le dice nada a tu equipo. En una revisión de código en Liverpool o Bimbo, un commit con mensaje "arreglos" generará preguntas y retrasos.

Regla práctica: Si no puedes describir el commit en una línea, probablemente estás haciendo demasiados cambios a la vez. Divide el trabajo en commits más pequeños.

Estrategias de ramificación

Una estrategia de ramificación define qué ramas existen en el repositorio y cómo fluye el código entre ellas.

Git Flow

Git Flow es la estrategia más usada en proyectos con ciclos de lanzamiento definidos. Usa cinco tipos de ramas:

Flujo básico en Git Flow:

1. Creas una rama feature/login-google desde develop.
2. Desarrollas y haces commits ahí.
3. Abres un Pull Request hacia develop.
4. Cuando develop está listo para lanzar, creas release/1.2.0.
5. Pruebas finales y correcciones menores van en esa rama.
6. Fusionas release/1.2.0 en main y en develop.

Trunk-Based Development

Otra estrategia popular es Trunk-Based Development. Aquí todos los desarrolladores integran cambios pequeños directamente a main (o a ramas de vida muy corta, de uno o dos días). Es más rápido, pero requiere pruebas automatizadas sólidas.

Empresas como FEMSA Digital usan esta estrategia porque les permite lanzar cambios varias veces al día.

¿Cuál elegir?

• Git Flow: equipos medianos o grandes, lanzamientos cada semana o mes.
• Trunk-Based: equipos ágiles, integración continua y entrega diaria.

Para tu primer empleo como desarrollador en México, lo más probable es que encuentres Git Flow o una variante de él.

Etiquetado de versiones con git tag

Una etiqueta (tag) es un marcador permanente sobre un commit específico. Se usa para identificar versiones de software.

Convención de versionado semántico (SemVer):

vMAYOR.MENOR.PARCHE

• MAYOR: cambio que rompe compatibilidad con versiones anteriores.
• MENOR: nueva funcionalidad compatible hacia atrás.
• PARCHE: corrección de errores.

Cómo crear y publicar una etiqueta:

# Crear etiqueta anotada
git tag -a v1.2.0 -m "Lanzamiento versión 1.2.0: módulo de pagos SPEI"

# Publicar la etiqueta en GitHub
git push origin v1.2.0

# Publicar todas las etiquetas pendientes
git push origin --tags

Ejemplo real: El equipo de e-commerce de Liverpool lanza una actualización del módulo de envíos. El commit que va a producción se etiqueta como v3.1.0. Si el lanzamiento tiene un error crítico, pueden hacer un git checkout v3.1.0 para ver exactamente el código que estaba en producción.

Errores comunes en proyectos profesionales

1. Hacer commits directamente en main

Empujar cambios sin revisar directo a main puede romper producción. Configura protección de rama en GitHub para que nadie pueda hacer git push a main sin pasar por un Pull Request.

2. Commits gigantes con demasiados cambios

Un commit que modifica 40 archivos y corrige tres bugs distintos es imposible de revisar. El equipo no puede entender qué pasó ni hacer git revert limpiamente si hay un error. Haz commits pequeños y enfocados.

3. Ignorar el archivo .gitignore

Subir archivos como node_modules/, .env o archivos con contraseñas es un error grave. El archivo .gitignore debe configurarse desde el primer día del proyecto. Nunca subas credenciales al repositorio.

4. No sincronizar la rama antes de trabajar

Empezar a trabajar sin hacer git pull primero genera conflictos evitables. Antes de comenzar cualquier tarea, actualiza tu rama local:

git checkout develop
git pull origin develop
git checkout -b feature/mi-tarea

5. Mensajes de commit en tiempo pasado o sin contexto

Escribir "agregué validación" en lugar de "agregar validación" no sigue el estándar de la industria. Usa el imperativo presente: "agregar", "corregir", "actualizar". Es la convención que siguen proyectos de código abierto y equipos profesionales en toda Latinoamérica.

Resumen de convenciones clave

Tus próximos pasos como desarrollador

Terminar este curso es el primer paso. Para seguir creciendo, hay un camino claro:

Nivel inmediato (próximas 2 semanas):

• Crea un repositorio personal en GitHub y aplica todo lo que aprendiste.
• Contribuye a un proyecto de código abierto mexicano. Busca en GitHub organizaciones como mexico-tech o proyectos del gobierno en datos.gob.mx.
• Configura Git Flow en tu repositorio con las ramas main y develop.

Nivel intermedio (próximos 3 meses):

• Aprende GitHub Actions para automatizar pruebas y despliegues.
• Estudia integración continua (CI/CD): es lo que usa Mercado Libre para lanzar cientos de cambios al día.
• Practica el comando git rebase para mantener un historial lineal y limpio.

Nivel avanzado (próximos 6 meses):

• Aprende a gestionar monorepos con herramientas como Nx o Turborepo.
• Estudia estrategias de despliegue: blue-green, canary releases.
• Obtén experiencia real: muchas empresas en México como Konfio, Clip o Kueski contratan desarrolladores junior con buen manejo de Git y trabajo en equipo.

Salarios de referencia en México para desarrolladores con dominio de Git:

Dominar Git no garantiza ese salario por sí solo, pero es una habilidad base que todo equipo profesional exige desde el primer día.

Lo que aprendiste en este curso

A lo largo de estas ocho lecciones cubriste todo el ciclo de vida de Git:

• Qué es el control de versiones y por qué existe.
• Cómo inicializar un repositorio y hacer tus primeros commits.
• Cómo trabajar con ramas para desarrollar en paralelo.
• Cómo resolver conflictos de fusión con calma y método.
• Cómo conectar tu trabajo a GitHub y colaborar con otros.
• Cómo usar forks, Pull Requests y revisiones de código.
• Cómo escribir mensajes de commit profesionales y aplicar Git Flow.

Git es una herramienta que se domina con la práctica diaria. Cada proyecto que tomes, cada PR que abras y cada conflicto que resuelvas te hará más rápido y más seguro. Empieza hoy.