grove

Un pool rápido de worktrees de Git reutilizables con reservas persistentes, disponible como CLI y SDK.

Si ejecutas muchas tareas sobre el mismo repositorio, conoces la rutina. Agentes, CI, tareas paralelas, lo que sea. Clonar otra vez. Hacer fetch otra vez. Esperar. Creé Grove para evitar eso.

Es un SDK y una CLI de TypeScript que mantienen un pool de worktrees de Git listos para usar. Adquieres una reserva, obtienes un checkout aislado asociado a un leaseId estable, haces tu trabajo y lo liberas al terminar. Sin volver a clonar todo cada vez. Sin quedarte mirando git fetch mientras otras tres tareas se acumulan detrás.

Ver el código en GitHub

Qué problema resuelve

La mayoría de las herramientas trata cada tarea como un comienzo desde cero. Grove trata los checkouts más como algo que tomas prestado y devuelves.

Reservas un espacio con un ID de reserva, haces checkout de una rama o referencia, ejecutas tu tarea (incluso si el proceso se reinicia) y después liberas, reparas o destruyes el espacio. Tus commits y cambios sin guardar se conservan hasta que eliges una política de limpieza: conservarlos (preserve), restablecerlos (reset) o ponerlos en cuarentena si algo salió mal.

Lo que me gusta

Algunas cosas de las que estoy especialmente orgulloso:

  • Reservas persistentes. El estado sobrevive a los reinicios. Recupera el mismo leaseId y continúa donde lo dejaste.
  • Reutilización rápida. El restablecimiento usa git clean -fd, no -xfd, así que los archivos ignorados, como node_modules, permanecen entre ejecuciones.
  • Recuperación ante fallos. Registro anticipado del estado y un repair() explícito cuando una operación queda a medias.

CLI y SDK

Grove ofrece dos formas de uso.

Hay una CLI (@ferueda/grove-cli) para ejecutar comandos desde la terminal o scripts de shell. Todos los comandos admiten --json con estructuras de respuesta estables, ideal para integrar herramientas y automatizar tareas rápidas.

También creé un SDK de TypeScript (@ferueda/grove) porque mis agentes y automatizaciones necesitaban crear worktrees directamente desde código. Sin invocar una CLI mediante shell ni analizar stdout. Tu orquestador llama a acquire, recibe una ruta, ejecuta su trabajo y llama a release. Esa es la interfaz que realmente quería para los flujos de agentes.