Git para equipos Go
Los equipos Go tratan Git como la fuente de verdad para el código y para las versiones de módulos.
//
Busca en todas las páginas de la documentación
Los equipos Go tratan Git como la fuente de verdad para el código y para las versiones de módulos.
Las etiquetas en la rama predeterminada se convierten en lanzamientos semver que go get y los proxies de módulos consumen.
Ese acoplamiento define cómo creas ramas, revisas, etiquetas y conectas la CI alrededor de go.mod y go.sum.
go.sum rompen las compilaciones posteriores; un historial limpio acelera la automatización de bisect y lanzamientos.go list -m resolvió una versión, o estandarizar las verificaciones de PR para repositorios Go.go mod tidy y políticas de proxy/sumdb. Los monorepos grandes intercambian el etiquetado simple por la coordinación de múltiples módulos.Un módulo Go es un árbol de directorios con go.mod en la raíz.
Los consumidores fijan tu módulo con una cadena de versión que generalmente proviene de una etiqueta Git en la rama predeterminada de tu repositorio.
El comando go mapea las etiquetas v1.2.3 a versiones de módulos y compila pseudo-versiones a partir de hashes de commit cuando no existe una etiqueta.
Por lo tanto, Git cumple una doble función: almacena el código fuente y nombra los lanzamientos.
Los equipos se estandarizan en un trunk (a menudo main) que siempre pasa las pruebas go test ./... y las puertas de lint relacionadas.
El trabajo de características se realiza en ramas de corta duración que se fusionan a través de solicitudes de extracción (pull requests).
Las ramas de lanzamiento son opcionales; muchas bibliotecas Go etiquetan directamente desde trunk después de la revisión.
.gitignore típicamente excluye binarios (/bin/, *.exe), vendor/ cuando no está confirmado, carpetas de IDE y anulaciones locales de go.work cuando son específicas del desarrollador.
go.mod y go.sum siempre se rastrean.
Para módulos privados, GOPRIVATE y las credenciales de VCS deben alinearse con cómo clona la CI y cómo se autentican los desarrolladores.
Cuando publicas la etiqueta v1.4.0, los proxies de módulos (y go get directo) obtienen esa instantánea de commit.
Las rutas de importación deben coincidir con la ruta del módulo en go.mod; las etiquetas en la rama incorrecta o sin directivas go actualizadas pueden confundir a los consumidores.
Versionado semántico de importación significa que los módulos v2+ viven bajo un sufijo de ruta /v2; las etiquetas Git todavía usan el semver estilo v2.0.0.
Las solicitudes de extracción deben mostrar las diferencias de go.mod / go.sum claramente porque esos archivos afectan a todas las compilaciones posteriores.
La CI se ejecuta en cada push para validar el grafo de módulos antes de la fusión.
# Verificaciones típicas pre-fusión (local o CI)
go test ./...
go vet ./...
go mod tidy && git diff --exit-code go.mod go.sumLos monorepos pueden contener múltiples archivos go.mod o un go.work raíz para el desarrollo local.
Git todavía tiene un historial, pero cada módulo puede etiquetar de forma independiente.
Los cherry-picks y rebases interactúan con las pseudo-versiones: las marcas de tiempo y los hashes de commit cambian la cadena de pseudo-versión que el proxy sirve.
Las reglas de rama protegida (revisiones requeridas, verificaciones de estado requeridas) reemplazan la cultura informal de "no romper main" con puertas aplicables.
Etiquetas firmadas (git tag -s) ayudan a los consumidores y equipos de seguridad a verificar la integridad del lanzamiento antes de que un proxy de módulo almacene en caché la versión.
Retract en go.mod dirige las nuevas resoluciones lejos de una etiqueta Git incorrecta sin reescribir el historial.
Los entornos air-gapped o regulados pueden empaquetar módulos; el flujo de trabajo de Git incluye entonces PRs periódicas de actualización de go mod vendor con revisión de checksum.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Basado en Trunk + etiqueta en main | Lanzamientos rápidos, una línea de integración | Requiere CI sólida y PRs pequeñas | Bibliotecas y la mayoría de servicios |
| Rama de lanzamiento por versión principal | Ventana de estabilización para parches | Desviación de etiquetas entre ramas | Productos empresariales de soporte a largo plazo |
| Monorepo + go.work | Cambios atómicos entre módulos | Etiquetado complejo por módulo | Equipos de plataforma con bibliotecas compartidas |
| Fork + replace (temporal) | Desbloquea parches de emergencia | No publicable; fácil de olvidar | Flujos de trabajo de contribución de corta duración |
Ganchos de observabilidad: registra la versión del módulo en las compilaciones binarias con -ldflags de git describe o variables de entorno de CI para que los registros de producción coincidan con el estado de VCS.
v1.2.3); las etiquetas ligeras y los nombres no semver son ignorados o se comportan de forma inesperada para go get.retract y una etiqueta correctiva.go.sum para compilaciones reproducibles y verificadas.Los consumidores de módulos resuelven versiones a partir de etiquetas en su rama predeterminada.
Sin etiquetas semver, solo están disponibles las pseudo-versiones de hashes de commit, que son más difíciles de comunicar en changelogs y políticas de soporte.
Las ramas de larga duración divergen del trunk, aumentan los conflictos de fusión en go.sum y retrasan la integración de correcciones de seguridad.
Los equipos Go prefieren días, no semanas, con CI demostrando que el módulo todavía compila y las pruebas son limpias.
go.mod y go.sum para cualquier cambio que altere las dependencias.
El código fuente de los paquetes que exportas, y los incrementos de la directiva go cuando adoptas nuevas características del lenguaje.
GOPRIVATE le dice al comando Go que omita la base de datos de checksum pública y el proxy de módulos para las rutas de módulos coincidentes.
Tus credenciales Git (tokens HTTPS o SSH) deben permitir que la CI y los portátiles clonen esos repositorios privados.
Muchas bibliotecas Go etiquetan parches desde main después de cherry-picks o PRs de corrección directas.
Las ramas de lanzamiento son útiles cuando debes soportar múltiples líneas principales con diferentes cadencias de parches.
Las pseudo-versiones codifican la hora y el hash del commit (por ejemplo, v0.0.0-20240312120000-abcdef123456).
Permiten que go get fije commits sin etiquetar de forma reproducible.
Solo si mantienes intencionalmente lanzamientos sincronizados.
Los módulos independientes generalmente etiquetan de forma independiente; documenta a qué rutas se aplican cada etiqueta.
Las PRs fusionadas cambian el contenido del módulo en el trunk.
La próxima etiqueta semver nombra el lanzamiento que los consumidores instalan; las descripciones de las PR deben notar el impacto en la API o go.mod.
En ramas de características personales antes de la revisión, a veces.
Nunca en ramas compartidas o después de una etiqueta de versión que los consumidores ya puedan resolver.
.gitattributes para la estrategia de fusión de go.sum (union), ignorar blame para protobufs generados y hooks o CI que ejecuten go mod tidy antes de la fusión.
go.work permite ediciones locales de múltiples módulos sin commits de replace.
Mantén go.work opcional fuera de las ramas compartidas a menos que todo el equipo use el mismo diseño de espacio de trabajo.
Generalmente no lo haces.
Compila artefactos de lanzamiento en CI a partir de fuentes etiquetadas; almacena binarios en almacenamiento de artefactos, no en el repositorio de módulos.
Versiones de pila: Esta página fue escrita para Go 1.26.x (predeterminado de Green Tea GC, go fix modernizers - verificar parche en la compilación), chi (última - verificar en la compilación), gin (última - verificar en la compilación), echo (última - verificar en la compilación), google.golang.org/grpc (última - verificar en la compilación), sigs.k8s.io/controller-runtime (última - verificar en la compilación), kubebuilder (última - verificar en la compilación), tinygo (última - verificar objetivos de placa en la compilación), wazero (última - verificar en la compilación), y golangci-lint (última - verificar conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026