Estrategias de Ramificación y Flujo Basado en Tronco
El flujo basado en tronco mantiene la rama main siempre lista para lanzar mientras las ramas de características se mantienen cortas.
//
Busca en todas las páginas de la documentación
El flujo basado en tronco mantiene la rama main siempre lista para lanzar mientras las ramas de características se mantienen cortas.
Los equipos de Go combinan ese modelo con CI que ejecuta las comprobaciones go test ./..., go vet y go mod tidy en cada push.
La mayoría de las bibliotecas y servicios de Go se envían desde una única rama de integración.
Los desarrolladores crean ramas durante horas o días, fusionan a través de pull requests y etiquetan lanzamientos semver desde la misma línea.
Las ramas de lanzamiento de larga duración se reservan para versiones principales soportadas, no para el trabajo diario de características.
Ese ritmo coincide con la forma en que los proxies de módulos seleccionan versiones de las etiquetas en la rama predeterminada.
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
git switch main && git pull --ff-only
git switch -c feat/short-lived-change
# edita, prueba localmente
go test ./...
go mod tidy && git diff --exit-code go.mod go.sum
git push -u origin feat/short-lived-change
# abre PR, fusiona cuando CI esté en verde, elimina la ramaCuándo usar esto:
go.sum de ramas obsoletas.v1.x desde main sin una rama de lanzamiento GitFlow.Un equipo de biblioteca envía mejoras en la API de métricas:
# Día 1
git switch -c feat/metrics-api
# implementa + pruebas
go test ./...
git push -u origin feat/metrics-api
# PR abierto, CI se ejecuta en ubuntu con Go 1.26.x
# Día 2 - rebasa sobre main fresco
git fetch origin
git rebase origin/main
go test ./...
git push --force-with-lease
# Después de la aprobación
# squash-merge o merge commit según la política del equipo
git switch main && git pull
git tag -a v1.5.0 -m "v1.5.0"
git push origin v1.5.0Lo que esto demuestra:
main (tronco) contiene el estado canónico del módulo.go test, lint y a menudo la detección de desviaciones de go mod tidy.El basado en tronco no significa "confirmar directamente en main sin revisión".
Significa integrar frecuentemente y evitar líneas paralelas de larga duración que divergen en dependencias.
| Rama | Duración | Propósito |
|---|---|---|
main | Permanente | Integración + fuente de lanzamiento |
feat/*, fix/* | Horas a pocos días | Cambios individuales |
release/v1 (opcional) | Meses a años | Solo parches para versiones principales antiguas |
hotfix/* | Horas | Parche urgente, puede ser cherry-pick a la rama de lanzamiento |
| Comprobación | Por qué importa |
|---|---|
go test ./... | Detecta paquetes rotos antes de fusionar |
go vet ./... | Comprobaciones estáticas de errores comunes |
go mod tidy + diff | Evita desviaciones de dependencias inesperadas en el tronco |
golangci-lint | Estilo del equipo y patrones de errores |
| Detector de carreras (jobs selectos) | Regresiones de concurrencia |
Squash-merge mantiene el historial del tronco con un commit por PR.
Rebase-merge preserva commits individuales cuando ya están bien formados.
Rebasa las ramas de características sobre main antes de fusionar para detectar conflictos tempranamente, especialmente en go.sum.
go.sum y archivos generados entran en conflicto a menudo. Solución: dividir el trabajo en PRs más pequeños o fusionar main diariamente.go.mod - Los cambios en las dependencias aún necesitan pruebas completas. Solución: los filtros de ruta excluyen solo rutas de documentación reales.--force-with-lease.| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| GitFlow (develop + release) | QA escalonada intensiva con versiones paralelas | Biblioteca Go pequeña con lanzamientos continuos del tronco |
| Ramas de lanzamiento por versión principal | Parches de v1 a largo plazo mientras v2 evoluciona en el tronco | El equipo carece de disciplina de cherry-pick |
| PRs apilados / flujo de graphite | Cambio grande dividido para revisión | CI no puede ejecutar grafos parciales de forma económica |
| Commits directos a main | Mantenedor en solitario, bajo riesgo | Repositorio de equipo sin comprobaciones requeridas |
Apunta a un PR revisable, generalmente con menos de 400 líneas de cambio en Go.
Si es más largo, divide por paquete o comportamiento detrás de banderas de características.
Squash mantiene el tronco legible y mapea un PR a una entrada del registro de cambios.
Preserva el historial de múltiples commits cuando los commits ya son atómicos y los mensajes están curados.
No, si las etiquetas en cada rama siguen semver y las rutas de los módulos se mantienen consistentes.
Documenta qué línea principal mantiene cada rama de lanzamiento.
Requerir revisiones de PR, prohibir force-push en main y requerir comprobaciones de estado para test + tidy.
Opcional: requerir commits firmados o etiquetas firmadas para lanzamientos.
Acepta un lado, ejecuta go mod tidy, vuelve a ejecutar las pruebas, confirma el resultado de tidy.
Nunca edites manualmente las líneas de checksum sin comprender el cambio de dependencia.
Sí, con rutas de CI por módulo y documentación clara de etiquetado.
El desarrollo local con go.work no reemplaza la política de integración del tronco.
Cuando la certificación de lanzamiento lleva semanas y múltiples versiones reciben parches en paralelo.
Incluso entonces, mantén main cerca de ser lanzable para reducir el costo de fusión.
Ramifica desde el commit de lanzamiento o la rama de lanzamiento soportada, haz cherry-pick al tronco, etiqueta el semver del parche.
Verifica go test ./... en ambas líneas cuando el mantenimiento dual esté activo.
Las banderas permiten que el tronco integre trabajo incompleto sin exponer el comportamiento.
Go usa etiquetas de compilación o configuración en tiempo de ejecución; la duración de la rama aún puede ser corta.
Actualiza README del módulo, disparadores de CI y protección de ramas después de renombrar de master a main.
Los proxies de módulos siguen las etiquetas en la rama predeterminada actual.
Los contribuyentes todavía usan forks y PRs.
Los mantenedores integran en el tronco canónico rápidamente después de la revisión.
Etiqueta después de fusionar cuando las notas de lanzamiento estén listas.
No etiquetes a mitad de PR; los consumidores necesitan commits que pasaron CI completa en el tronco.
Versiones de pila: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea, go fix modernizadores - 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