Prácticas recomendadas de Git y GitHub
Hábitos portátiles de Git y GitHub para repositorios de módulos Go.
//
Busca en todas las páginas de la documentación
Hábitos portátiles de Git y GitHub para repositorios de módulos Go.
Estas reglas mantienen el tronco liberable, los gráficos de módulos ordenados y los lanzamientos confiables para el go get descendente.
main siempre liberable. Cada fusión debe pasar go test ./... y las comprobaciones de ordenación de módulos en CI.go.sum.release/vN y cómo se seleccionan los parches del tronco.internal/parse: rechazar entrada vacía.go.mod y go.sum con el código que causó los cambios de dependencia. Nunca divida entre fusiones no detectadas.retract y etiquetas de corrección futura.--force-with-lease solo en ramas de características personales. Nunca en ramas compartidas o de lanzamiento.go.mod.v1.2.3 que coincide con la línea principal de go.mod.git tag -a o git tag -s.git push origin v1.2.3 - las etiquetas no son predeterminadas en un push simple./v2 para cambios incompatibles en la API. No rompa a los consumidores bajo la ruta de importación v1.go.mod en lugar de eliminar etiquetas. Documente la migración en el registro de cambios.go de go.mod. Utilice go-version-file en setup-go.go.sum. Incluya sumas anidadas en monorepos.GOPRIVATE para los módulos de la organización y escale de forma estrecha. Evite deshabilitar sumdb para dependencias públicas.GOWORK=off antes de etiquetar módulos de monorepo. Simula la resolución del consumidor..gitignore consciente de Go. Binarios, perfiles, ruido de IDE; nunca ignore go.sum..gitattributes para go.sum si es necesario. union reduce las líneas de conflicto manuales.replace específicas de la máquina. Utilice go.work localmente o archivos de espacio de trabajo confirmados por el equipo.go.mod.-ldflags de git describe o entorno de CI.Nunca fusiones al tronco sin CI que ejecute go test ./... y falle por deriva de ordenación.
Todo lo demás apoya esa puerta de enlace.
Squash mantiene el tronco legible para las bibliotecas.
Elija rebase-merge si el historial a nivel de commit está curado y los revisores desean arqueología granular.
Bibliotecas: cuando la API o las correcciones justifican semver.
Servicios: etiquete commits desplegables; los consumidores pueden ser solo internos.
Los commits firmados ayudan a la procedencia.
Las etiquetas de lanzamiento firmadas a menudo tienen un ROI más alto para los consumidores de módulos que firmar cada commit.
Rutas por módulo para go.mod y paquetes exportados.
Requiera la revisión del propietario cuando cambien la API pública o las dependencias.
Útil con CI y revisión humana en cambios transitivos.
Las fusiones ciegas corren el riesgo de sorpresas en la cadena de suministro.
Los mantenedores seleccionan o fusionan desde PR de forks después de CI.
No otorgue secretos a flujos de trabajo de forks no confiables.
CI con aislamiento, entornos regulados o recuperación ante desastres fijada.
Documente la cadencia de actualización del proveedor en README.
Habilite cuando muchos PR se fusionan por hora y las pruebas del tronco son confiables.
Requiere una duración de CI consistente bajo el SLA del equipo.
Utilice la misma cadena semver siempre que sea posible.
Compile imágenes desde SHAs etiquetados en CI, no desde cabezas de rama flotantes.
Cuando todo el equipo comparte los mismos módulos del espacio de trabajo.
Los superconjuntos personales permanecen sin seguimiento.
Etiquetar antes de la migración de la ruta /v2 en un cambio que rompe la compatibilidad.
Los consumidores fijan gráficos de importación rotos.
Versiones de pila: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea, go fix modernizadores - verifique el parche en la compilación), chi (última versión - verifique en la compilación), gin (última versión - verifique en la compilación), echo (última versión - verifique en la compilación), google.golang.org/grpc (última versión - verifique en la compilación), sigs.k8s.io/controller-runtime (última versión - verifique en la compilación), kubebuilder (última versión - verifique en la compilación), tinygo (última versión - verifique los objetivos de la placa en la compilación), wazero (última versión - verifique en la compilación) y golangci-lint (última versión - verifique el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 18 jul 2026