Git worktree o submodule: decide por el historial
Los bloques son casos distintos, no un único script. Elige el que encaja con tu repositorio. Sustituye ramas, rutas y VERIFIED_COMMIT antes de usarlos. Los comandos de cancelación solo corresponden a su operación activa; no ejecutes ambas alternativas.
Respuesta breve
Usa worktree para otro checkout del mismo repositorio en tareas paralelas o revisión de ramas. Usa submodule cuando un repositorio deba registrar un commit concreto de otro como dependencia. Uno añade un directorio de trabajo al historial compartido; el otro incorpora un repositorio con versionado propio cuya selección queda registrada en el padre.
| Decisión | Worktree | Submodule |
|---|---|---|
| Historial | Mismo repositorio; objetos y referencias compartidos | Repositorio hijo separado; el padre registra un commit |
| Archivos | HEAD, índice y directorio propios | Checkout hijo, pin de HEAD del padre e índice pueden diferir |
| Versión | Rama o commit del mismo repositorio | Commit hijo seleccionado, no solo .gitmodules |
| Actualizar | Revisar e integrar la rama elegida | Checkout al pin registrado; --remote es otra decisión |
| Límite | Normalmente un checkout por rama; no aísla permisos | Soporte incompleto en múltiples worktrees; trabajo hijo separado |
Ejemplo y condiciones
Primero determina quién mantiene el historial. Dos agentes probando arreglos para una aplicación suelen necesitar ramas y árboles separados. Una biblioteca con su propio proceso de versiones puede necesitar una dependencia fijada. Ningún mecanismo es un aislamiento de permisos: los del sistema de archivos y los agentes siguen siendo independientes.
Inspecciona antes de cambiar
Un worktree enlazado tiene HEAD, índice y archivos propios, pero comparte objetos y la mayoría de las referencias del repositorio. Permite revisar otra rama sin sustituir tus cambios actuales. Git normalmente impide abrir la misma rama en dos worktrees. Compartir objetos no hace aparecer automáticamente en el otro directorio las modificaciones sin preparar.
git status --short
git branch --show-current
git worktree listConserva una referencia o checkout separado
Inspecciona el estado y crea review/worktree en ../topic-review. Usa git -C para leer ese checkout y comparar sus commits antes de integrar el resultado elegido. Los directorios separados reducen la mezcla accidental de tareas, pero no garantizan cambios compatibles. Comprueba la integración y evita dos herramientas modificando el mismo checkout a la vez.
git worktree add -b review/worktree ../topic-review HEAD
git -C ../topic-review status --short
git -C ../topic-review branch --show-currentPrimer flujo
Un submódulo es otro repositorio en una ruta del padre. El árbol confirmado del padre registra un gitlink, normalmente modo 160000, a un commit hijo. El índice puede preparar otro commit y el checkout hijo puede diferir de ambos. .gitmodules describe ruta y URL; la versión seleccionada viene del commit registrado.
Elige deliberadamente la otra opción
Para deps/library, inspecciona por separado submodule status, el gitlink de HEAD del padre, el gitlink preparado y HEAD del hijo. Un pull del padre puede cambiar el pin sin mover el checkout hijo. Submodule update consume la selección registrada; --remote sigue deliberadamente una selección remota y es otra decisión de versión, no una limpieza de estado.
git submodule status -- deps/library
git ls-tree HEAD -- deps/library
git ls-files --stage -- deps/library
git -C deps/library rev-parse HEAD
git --no-optional-locks -C deps/library status --shortLímites y excepciones
Git documenta soporte incompleto de submódulos en múltiples worktrees. Añadir --recursive no convierte cualquier combinación en un entorno aislado soportado. Comprueba los límites y el flujo real de checkout y actualización; considera un clone separado si necesitas estado independiente. Esta comparación no es una receta universal de automatización para combinarlos.
Conflictos y limpieza
Antes de quitar un worktree, revisa archivos locales e historial, y usa worktree remove en lugar de borrar el directorio a ciegas. Conserva la rama útil o el merge revisado. Antes de cambiar un pin, confirma y publica el cambio hijo mediante su propio flujo para que otro clone pueda obtenerlo; después registra la selección en el padre.
git -C ../topic-review status --short
git worktree remove ../topic-review
git worktree listVerifica el resultado
En worktrees, verifica rama, estado e integración elegida. En submódulos, compara los tres estados y confirma que el público previsto puede obtener el objeto hijo. Un padre limpio no garantiza hijos limpios. Ninguno conserva una copia permanente de archivos sin commit; la verificación depende de la relación entre historiales.
git worktree list
git submodule status -- deps/libraryPreguntas habituales
¿Por qué worktree? Para otra rama sin reemplazar el checkout actual. ¿Cuándo submodule? Para una dependencia con versiones propias y un pin en el padre. ¿Por qué evitarlos? Sus reglas de actualización añaden coordinación. Package manager, vendoring, subtree o clone separado son alternativas según propiedad de versiones y entrega, no un ganador universal.
Revisa la operación en FluxGit
Usa el historial visual y la vista de cambios de FluxGit para revisar la operación y los commits pertinentes. Conserva las comprobaciones de rama, historial compartido y archivos locales del ejemplo. La página de descarga muestra las versiones y plataformas disponibles.