Los worktrees de Git permiten mantener múltiples directorios de trabajo activos simultáneamente sobre un mismo repositorio, eliminando la necesidad de alternar constantemente entre ramas. Esta funcionalidad, disponible desde Git 2.5, resulta especialmente útil en flujos de trabajo que involucran agentes de código IA, los cuales requieren espacios de trabajo aislados para operar en paralelo sin interferir en el entorno principal del desarrollador. A diferencia de las ramas, que comparten un único directorio de trabajo, los worktrees comparten la base de datos de objetos y las referencias, pero poseen su propio índice y HEAD, lo que permite ejecutar tareas largas o revisar pull requests sin interrumpir el trabajo en curso. El principal inconveniente es que los archivos no versionados, como dependencias y cachés de compilación, deben configurarse nuevamente en cada worktree.
En el ecosistema de Emacs, Magit ofrece soporte nativo para gestionar estos worktrees mediante atajos de teclado específicos bajo la tecla Z. Comandos como 'Z b' permiten verificar una rama existente en un nuevo worktree, mientras que 'Z c' crea una rama y un worktree nuevos de forma simultánea. La interfaz de Magit trata cada worktree como un proyecto independiente, integrándose naturalmente con gestores de proyectos como project.el. Para una experiencia óptima, se recomienda crear los worktrees como directorios hermanos del checkout principal, evitando anidarlos para no confundir herramientas de búsqueda como grep o find. Además, es crucial recordar que Git impide verificar la misma rama en dos worktrees a la vez, regla que Magit respeta y que puede explicar por qué ciertas ramas no permiten el checkout. Aunque Jujutsu (jj) ofrece una alternativa moderna con soporte nativo para directorios paralelos, los worktrees de Git siguen siendo la solución estándar para gestionar el trabajo concurrente en repositorios tradicionales.