Conceptos básicos de Git para proyectos Go

10 ejemplos para empezar con Git y GitHub: 7 básicos y 3 intermedios.

Prerrequisitos

• Instala Git 2.40+ y Go 1.26.x desde go.dev/dl.
• Configura tu identidad: git config --global user.name "Tu Nombre" y git config --global user.email "tu@ejemplo.com".
• Ten acceso SSH o HTTPS a tu host de módulos (GitHub, GitLab, etc.).
• Para módulos privados, configura GOPRIVATE con el prefijo de tu organización, por ejemplo export GOPRIVATE=github.com/miorg/*.

Ejemplos básicos

1. Clonar un repositorio de módulos Go

Empieza desde el remoto que coincida con la ruta del módulo de tu go.mod.

git clone git@github.com:myorg/widget.git
cd widget
go test ./...

• La URL de clonación debe coincidir con la ruta donde go get resuelve el módulo.
• Ejecuta las pruebas inmediatamente para verificar el toolchain y el acceso a la caché de módulos.
• go.mod en la raíz del repositorio define la ruta del módulo para las importaciones.

Relacionado: Git para equipos Go - por qué Git y los módulos comparten una historia de lanzamiento

2. Comprobar el estado antes de tocar go.mod

Ver los cambios rastreados y si los archivos de dependencias han variado.

git status
git diff go.mod go.sum

• Las diferencias en go.mod / go.sum a menudo significan cambios en las dependencias o en tidy.
• Los binarios no rastreados generalmente indican que .gitignore necesita /bin/ o *.exe.
• Haz commit de los cambios en los archivos de dependencias en el mismo PR que el código que los causó.

Relacionado: go.mod, go.sum y Selección de Versión Mínima - qué significan esos archivos

3. Crear una rama de funcionalidad

Mantén main lista para lanzar; crea una rama por cambio.

git switch -c feat/add-metrics

• Usa nombres de rama cortos y descriptivos (fix/nil-panic, feat/grpc-health).
• Un solo cambio lógico por rama mantiene la revisión del PR y el bisect sencillos.
• Haz rebase o merge desde main frecuentemente para evitar conflictos en go.sum.

Relacionado: Estrategias de Ramificación y Flujo Basado en Tronco - hábitos de flujo basado en tronco

4. Preparar y hacer commit de fuentes Go

Haz commit de unidades compilables con mensajes claros.

git add internal/metrics/collector.go internal/metrics/collector_test.go
git commit -m "metrics: agregar colector de procesos"

• Incluye los archivos _test.go junto con el código que cubren.
• Evita hacer commit de binarios de go test o salidas de perfil.
• El estilo de mensaje paquete: verbo coincide con muchas convenciones de proyectos Go.

5. Registrar cambios en las dependencias

Después de go get o ediciones de importación, haz tidy y haz commit de los archivos del módulo.

go get golang.org/x/sync@v0.10.0
go mod tidy
git add go.mod go.sum
git commit -m "go.mod: actualizar golang.org/x/sync"

• go mod tidy elimina requires no utilizados y agrega indirects faltantes.
• Revisa el crecimiento de go.sum para módulos transitivos inesperados.
• La CI debería fallar si tidy cambiara archivos después del merge.

6. Subir rama y abrir un PR

Publica el trabajo para revisión sin etiquetar una versión todavía.

git push -u origin feat/add-metrics

• -u establece el upstream para que git push / git pull posteriores funcionen sin argumentos adicionales.
• Abre una solicitud de extracción (pull request) contra main con el plan de pruebas y el impacto del módulo anotados.
• Espera a que go test ./... de la CI se complete antes de hacer merge.

Relacionado: Revisión de Código con PRs de GitHub - tamaño del PR y revisión consciente de módulos

7. Obtener la última versión del tronco antes del merge

Integra los cambios de otros y vuelve a ejecutar las pruebas.

git switch main
git pull --ff-only
git switch feat/add-metrics
git merge main
go test ./...

• --ff-only en main evita commits de merge accidentales al actualizar el tronco local.
• Resuelve los conflictos de go.sum cuidadosamente; vuelve a ejecutar go mod tidy después de la resolución.
• Nunca hagas merge con pruebas fallidas o diferencias de tidy sin commitear.

Ejemplos intermedios

8. Inspeccionar el historial para una regresión

Usa el historial de Git con el flujo rápido de bisect de Go.

git log --oneline -n 10
git bisect start
git bisect bad
git bisect good v1.3.0
go test ./internal/parse -run TestDecode

• git bisect se combina bien con las banderas de paquete go test enfocadas.
• Los nombres de etiqueta como v1.3.0 son límites válidos de bisect para módulos publicados.
• Documenta el resultado de bisect en el PR de corrección para lectores futuros.

Relacionado: Rebasing, Cherry-Pick y Worktrees - herramientas de higiene del historial

9. Crear una etiqueta de lanzamiento semver

Etiqueta el commit que quieres que los consumidores del módulo resuelvan.

git switch main
git pull --ff-only
go test ./...
git tag -a v1.4.0 -m "v1.4.0: colector de métricas"
git push origin v1.4.0

• Usa etiquetas anotadas (-a) para lanzamientos; llevan metadatos del mensaje y del etiquetador.
• Etiqueta solo después de que la CI esté en verde en el commit exacto.
• Los consumidores ejecutan go get github.com/myorg/widget@v1.4.0 después de que el proxy indexa la etiqueta.

Relacionado: Etiquetas Firmadas y Lanzamientos de Módulos Go - firma y comportamiento del proxy

10. Guardar trabajo en progreso (stash) y usar un worktree

Trabajo paralelo sin conflictos en las salidas de go build.

git stash push -m "wip metrics" -- internal/metrics
git worktree add ../widget-hotfix main
cd ../widget-hotfix
go test ./...

• Guarda rutas (stash paths) para evitar incluir experimentos no relacionados de go.mod.
• Los worktrees proporcionan un segundo checkout que comparte una única base de datos .git.
• Cada worktree necesita su propia ejecución de go test; la caché de módulos se comparte.

Relacionado: Patrones de Git para Monorepos con go work - múltiples módulos, un repositorio

Versiones de la pila: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, modernizadores de go fix - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica los objetivos de placa en la compilación), wazero (última versión - verifica en la compilación) y golangci-lint (última versión - verifica el conjunto de linters en la compilación).