Rebasing, Cherry-Pick y Worktrees
Rebase, cherry-pick y worktrees ayudan a los equipos de Go a mantener un historial lineal, portar correcciones entre líneas de lanzamiento y trabajar en dos versiones de módulos a la vez.
//
Busca en todas las páginas de la documentación
Rebase, cherry-pick y worktrees ayudan a los equipos de Go a mantener un historial lineal, portar correcciones entre líneas de lanzamiento y trabajar en dos versiones de módulos a la vez.
Usados cuidadosamente, reducen el dolor de los conflictos en go.sum y aceleran las correcciones urgentes sin stash sucios.
Rebase reproduce tus commits sobre una base más nueva, reescribiendo SHAs.
Cherry-pick copia commits individuales a otra rama, común para backports.
Worktrees añade un segundo directorio de checkout que comparte una única tienda .git, ideal para ejecuciones paralelas de go test en diferentes ramas.
Los tres interactúan con las pseudo-versiones de los módulos Go porque esas cadenas incrustan metadatos de commit.
Tarjeta de referencia rápida - lista para copiar y pegar.
# Rebase rama de característica sobre la última main
git fetch origin
git switch feat/my-change
git rebase origin/main
go test ./...
go mod tidy && git diff --exit-code go.mod go.sum
git push --force-with-lease
# Cherry-pick hotfix a la rama de lanzamiento
git switch release/v1
git cherry-pick abc1234
go test ./...
# Checkout paralelo con worktree
git worktree add ../repo-hotfix release/v1Cuándo usar esto:
main a release/v1.Corrige un panic nulo en main, haz backport a la línea de lanzamiento v1, y mantén el trabajo de características en ejecución:
# En main - corrección aterrizada como commit fa1c0ff
git switch main
git pull --ff-only
go test ./...
# Backport a release/v1
git switch release/v1
git pull --ff-only
git cherry-pick fa1c0ff
go test ./...
git tag -a v1.9.4 -m "v1.9.4: corrige panic nulo en el parser"
git push origin release/v1 v1.9.4
# Continúa la rama de características en un worktree
git worktree add ../widget-feat feat/new-api
cd ../widget-feat
go test ./...Lo que esto demuestra:
main en la rama de lanzamiento.stash del trabajo en progreso en la rama de características durante el hotfix.Rebase elimina temporalmente tus commits, avanza rápidamente a la nueva base, y luego vuelve a aplicar los commits uno por uno.
Pueden aparecer conflictos en fuentes Go y go.sum; resuélvelos, git add, git rebase --continue.
Cherry-pick aplica el parche de un commit elegido como un nuevo commit en la rama actual.
Si el commit original tocó go.mod, verifica el estado tidy después del pick.
Worktree crea un directorio de trabajo enlazado con su propio HEAD pero compartiendo objetos y referencias.
Cada árbol puede ejecutar go build / go test de forma independiente; la caché de módulos es global en la máquina.
| Situación | Guía |
|---|---|
| Rama de característica personal antes de fusionar | Haz rebase libremente; haz push con --force-with-lease |
| Rama en la que otros han hecho push | Coordina; prefiere merge |
| Después de que los consumidores usen la etiqueta | No reescribas commits etiquetados |
| PR abierto con muchos revisores | Haz rebase temprano y a menudo, no solo al final |
Cherry-pick trae un commit.
Merge trae el historial completo de la rama.
Para las líneas de parches de Go, cherry-pick mantiene las ramas de lanzamiento mínimas y amigables para el changelog.
~/src/widget/ # trabajo principal en feat/new-api
~/src/widget-hotfix/ # worktree en release/v1
Lista los worktrees: git worktree list.
Eliminar: git worktree remove ../widget-hotfix una vez que la rama esté terminada.
# Después de cualquier reescritura de historial en una rama de la que dependes localmente
go clean -testcache
go test ./...
# Vista previa de pseudo-versión para HEAD actual (sin fijar)
go list -m -json example.com/widget@masterReescribir SHAs cambia las cadenas de pseudo-versión para commits sin etiquetar.
Los lanzamientos etiquetados no se ven afectados una vez que se les hace push.
git push --force-with-lease.go.mod difiere en la rama de lanzamiento. Solución: go test ./... y tidy después de cada pick.go.sum - La fusión manual de líneas de checksum es propensa a errores. Solución: toma un lado, ejecuta go mod tidy, continúa el rebase.| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
Fusionar main en la característica | Rama compartida, baja tolerancia a reescrituras | Quieres historial lineal del tronco |
git merge backport | Línea de lanzamiento divergente grande | Corrección de seguridad de un solo commit |
| Stash | Cambio rápido de contexto, minutos | Compilaciones largas paralelas en dos ramas |
| Clonación separada | Experimentos completamente aislados | Desperdicio de disco y tiempo de fetch |
Los lanzamientos semver etiquetados no cambian después del rebase a menos que muevas o elimines etiquetas.
Los commits sin etiquetar a los que se accede a través de pseudo-versiones mostrarán nuevas cadenas de versión después de los cambios de SHA.
Cuando varias personas hacen commits en la misma rama o cuando preservar el contexto exacto de la fusión es importante para las auditorías.
Sí, si las salidas de protobuf o stringer difieren entre ramas.
Regenera con la cadena de herramientas de la rama, luego continúa el cherry-pick.
Dos o tres por repositorio es lo típico: trunk, feature, hotfix.
Más que eso generalmente indica problemas de política de ramas.
Sí.
Trata las ramas con force-push como nuevos pushes; los grafos de módulos deben volver a validarse.
Fusionar commits de WIP, reformular mensajes, eliminar commits de depuración antes de un PR limpio.
Ejecutar antes de la revisión, no después de fusionar al trunk.
Cada worktree es un directorio separado.
Un archivo go.work en un árbol no se aplica a otro a menos que copies o enlaces simbólicamente intencionalmente.
git cherry-pick --abort durante un conflicto, o git revert sobre el commit incorrecto si ya está confirmado.
Rebasar commits antiguos cambia los SHAs y puede confundir las notas manuales de bisect.
Usa etiquetas y commits de fusión como anclas estables para bisect.
Sí: git worktree add ../widget-v1 v1.9.3.
Útil para reproducir un error del consumidor en una versión exacta del módulo.
Útil si las comprobaciones se vuelven a ejecutar de manera fiable.
Asegúrate de que go mod tidy y las pruebas se ejecuten después del rebase del bot, no solo la resolución de conflictos.
Las mismas reglas, pero los conflictos pueden abarcar múltiples archivos go.mod.
Ejecuta tidy en cada raíz de módulo afectada después de la resolución.
Versiones de la Pila: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC,
go fixmodernizadores - verifica el parche en la compilación), chi (última - verifica en la compilación), gin (última - verifica en la compilación), echo (última - verifica en la compilación), google.golang.org/grpc (última - verifica en la compilación), sigs.k8s.io/controller-runtime (última - verifica en la compilación), kubebuilder (última - verifica en la compilación), tinygo (última - verifica objetivos de placa en la compilación), wazero (última - verifica en la compilación) y golangci-lint (última - verifica el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 18 jul 2026