Worktrunk: árboles paralelos, ciclo de vida y análisis del código
Arquitectura de Worktrunk: configuración, aprobación y orden de hooks
Sigue el control desde una operación hasta sus comandos y hooks, con dependencias de inicio y límites de recuperación durante la fusión.
Qué aprenderás
- La configuración introduce comportamiento ejecutable
- Los hooks previos y posteriores tienen dependencias diferentes
- La fusión es una secuencia de operaciones, no un alias de Git merge
Antes de empezar
- Ramas Git y navegación básica por terminal
- Un repositorio desechable para ejercicios opcionales
Explicar límites del árbol, verificar un primer checkout y revisar comandos antes de automatizar.
Conclusiones clave
- Separa mutaciones Git y resultados de hooks.
- Coloca prerrequisitos reales en una fase bloqueante.
- Un fallo tardío no revierte necesariamente las fases anteriores.
La configuración introduce comportamiento ejecutable
Una operación combina intención de la CLI y configuración. Una plantilla determina la ruta y los hooks vinculan comandos de terminal a eventos del ciclo de vida. Los ajustes personales y los compartidos tienen supuestos de confianza distintos. El proyecto puede distribuir una plantilla, pero la ruta inspeccionada de aprobación decide localmente si permite ejecutar el comando del proyecto.
Separa dos flujos relacionados: cambios de estado Git y ejecución externa. Un checkout correcto puede coexistir con un fallo posterior de un hook en segundo plano. Rechazar un comando del proyecto tampoco implica necesariamente cancelar toda la operación. Identificar a qué flujo pertenece cada mensaje facilita interpretar los registros.
Los hooks previos y posteriores tienen dependencias diferentes
La documentación describe hooks previos bloqueantes: un fallo detiene la operación en ese punto. Los posteriores normalmente se ejecutan en segundo plano con registros. En el inicio, pre-start termina antes de post-start y del comando solicitado con --execute. Instalar dependencias en un post-start paralelo puede competir con el arranque; usa una fase bloqueante o una secuencia explícita.
Una cadena representa un comando, una tabla agrupa comandos concurrentes y una secuencia de hooks ordena pasos, permitiendo concurrencia dentro de cada paso. Los hooks previos del usuario preceden a los del proyecto; las fuentes posteriores funcionan independientemente. El orden escrito no garantiza acceso secuencial al mismo archivo, base de datos o estado Git.
La fusión es una secuencia de operaciones, no un alias de Git merge
La documentación fijada describe commit o compresión, rebase, comprobaciones previas, avance del destino local y limpieza. A diferencia de git merge, wt merge integra la rama actual en el destino. Nunca hace fetch. La preparación predeterminada puede incluir todos los cambios del directorio: revisa las diferencias y trata la sincronización remota como una tarea aparte.
Un fallo no implica reversión transaccional. Un conflicto puede dejar abierto un rebase y pre-remove puede fallar después de la fusión. Comprueba referencias y estado antes de reintentar. Los hooks post-merge y post-remove ocurren después de la limpieza y no deben asumir que el directorio de origen existe. Describimos la secuencia documentada, no una fusión ejecutada.
Cómo elegir
| Criterio | Opción A | Opción B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Pasos de implementación
- 1
Enumera comandos y eventos configurados.
- 2
Anota origen, aprobación y comportamiento bloqueante.
- 3
Dibuja dependencias antes de añadir concurrencia.
- 4
Define una comprobación de recuperación por fase mutante.
Ejemplo para copiar
# Configuración ilustrativa; no ejecutada en esta revisión.
# Pasos secuenciales; comandos concurrentes dentro de cada paso.
[[pre-merge]]
test = "cargo test"
[[pre-merge]]
lint = "cargo clippy"Preguntas frecuentes
¿Un fallo de hook deshace todo lo anterior?
No necesariamente: al detenerse una fase, las mutaciones anteriores pueden haberse realizado.
¿wt merge descarga la rama remota más reciente?
La documentación fijada dice que no hace fetch; la sincronización se gestiona por separado.
Fuentes
- Worktrunk / docs/src/content/docs/config.mdFuente verificada 2026-09-14
- Worktrunk / docs/src/content/docs/hook.mdFuente verificada 2026-09-14
- Worktrunk / docs/src/content/docs/merge.mdFuente verificada 2026-09-14
- Worktrunk / src/commands/command_approval.rsFuente verificada 2026-09-14