Flujo de trabajo Git para desarrolladores Go: del caos al código limpio

¿Por qué el flujo de trabajo Git es un dolor para cada desarrollador Go?

¿Alguna vez ha pasado medio día tratando de entender por qué la compilación se rompió en la rama master, aunque ayer todo funcionaba? ¿O se ha confundido con las versiones de los módulos Go cuando dos desarrolladores modificaban el mismo paquete al mismo tiempo? ¿Le suena familiar? Bienvenido al club.

Go es un lenguaje simple y elegante. Pero sin un flujo de trabajo Git para desarrolladores Go adecuado, incluso el código más limpio se convierte en un desastre. En este artículo, no analizaremos teorías abstractas, sino escenarios reales: cómo trabajar con go modules, cómo no romper el CI/CD y cómo hacer que el code review sea rápido y útil. Abróchese el cinturón, será práctico.

Lo básico: Git Flow y su adaptación a Go

El Git Flow clásico (ramas main, develop, feature/*, release/*, hotfix/*) funciona muy bien para proyectos grandes. Pero en el mundo de Go hay matices.

¿Por qué Trunk-Based Development a menudo gana?

A la comunidad Go le encanta la simplicidad. Trunk-Based Development (trabajar en una rama principal con ramas de funcionalidad de corta duración) encaja perfectamente con la filosofía de Go. Menos ramas significan menos dolores de cabeza con las fusiones. Para equipos pequeños (hasta 5 personas), esta suele ser la mejor opción.

Sin embargo, si tiene un ciclo de lanzamiento de 2 semanas y varias funciones en paralelo, Git Flow sigue siendo el rey. Solo recuerde: cada rama no debe vivir más de 2-3 días. De lo contrario, los conflictos son inevitables.

# Ejemplo de creación de una rama de funcionalidad para un nuevo middleware\ngit checkout -b feature/add-request-logger\n# Trabajamos, hacemos commit, hacemos push\ngit push origin feature/add-request-logger\n# Después del code review — squash y fusión en main\n

Go Modules y Git: Cómo no volverse loco

El problema más común en el flujo de trabajo git golang son las dependencias. Go Modules (desde Go 1.11) resolvieron muchos problemas, pero agregaron otros nuevos.

Trabajo correcto con etiquetas

Su módulo es una API pública. Si lo cambia, cambie la versión. El versionado semántico (semver) no solo está de moda, es obligatorio.

\n
• v0.x.x — versión inestable, se puede romper la compatibilidad.
\n
• v1.x.x — estable, la compatibilidad hacia atrás es obligatoria.
\n
• v2+ — cambios importantes, debe cambiar la ruta del módulo.
\n

Ejemplo de etiquetado correcto:

git tag v1.2.3\ngit push origin v1.2.3\n

Y ahora un ejemplo de cómo NO hacerlo:

# Mal: etiqueta sin sincronización con go.mod\ngit tag v1.0.0\n# Y en go.mod todavía está la versión v0.5.0\n

Primero actualice siempre go.mod, luego ponga la etiqueta. De lo contrario, go get se volverá loco.

Cómo actualizar dependencias en equipo

Supongamos que ha actualizado la biblioteca github.com/gin-gonic/gin. En lugar de enviar un diff enorme, siga la regla: un commit, un cambio.

# Actualizamos una dependencia\ngo get github.com/gin-gonic/gin@v1.9.1\ngo mod tidy\ngit add go.mod go.sum\ngit commit -m "chore: update gin to v1.9.1"\ngit push\n

Esto simplifica el code review: el colega ve exactamente lo que cambió, no la "magia" en go.sum.

Code Review para Go: Flujo de trabajo Git al servicio de la calidad

El code review no se trata de "encontrar errores". Se trata de transferir conocimiento y mantener el estilo. Pero si su flujo de trabajo Git para proyectos golang no está configurado, la revisión se convierte en un infierno.

Cómo hacer que la revisión sea rápida

\n
• PR pequeños: 200-300 líneas de código como máximo. Más grande, divídalo.
\n
• Linting automático: golangci-lint debe ejecutarse antes de la revisión, no después. Configure un hook de pre-commit o CI.
\n
• Estilo unificado: use gofmt (sí, es obligatorio). Sin discusiones