git-parsec — desde crear un worktree hasta hacer merge del PR con un solo ticket

Es una herramienta CLI que automatiza un flujo de trabajo de desarrollo en paralelo basado en Git worktree.

Problema que resuelve

Cuando trabajas en varios tickets al mismo tiempo sin cambiar de rama, git worktree es una muy buena opción.
Pero para usarlo en el trabajo diario, hay muchas tareas repetitivas:

• Crear el worktree y nombrar la rama → en una sola línea con parsec start PROJ-123
• Hacer push, crear el PR y adjuntar el enlace del ticket → en una sola línea con parsec ship PROJ-123
• Revisar CI, hacer merge y limpiar el worktree → en una sola línea con parsec merge PROJ-123

Las tareas repetitivas de siempre se reducen a un solo comando por cada paso.

Flujo de trabajo principal

parsec start PROJ-123       # worktree + rama + integración con ticket de Jira  
# ... programando ...  
parsec ship PROJ-123        # push → creación de PR (incluye automáticamente título/enlace del ticket)  
parsec ci PROJ-123          # muestra una tabla con el estado de CI  
parsec merge PROJ-123       # espera CI → squash merge → limpieza automática del worktree  

Funciones principales

Integración con trackers

• Jira / GitHub Issues — refleja automáticamente el título del ticket, transición de estado, vista de tablero, inbox
• parsec ticket — consulta los detalles del ticket desde la terminal
• parsec board — revisa el tablero de sprint de Jira desde la CLI

Gestión de worktrees

• Integración con shell — cambio automático con cd entre worktrees usando parsec switch
• Stacked PRs — construye cadenas de PR con la opción --on, rebase en lote con stack sync
• Undo — recupera de una vez incluso worktrees limpiados por error

Automatización

• Release — generación automática de tag + merge + GitHub Release + changelog
• Modos de salida Human / JSON / Quiet — fácil integración con scripts de CI
• 27 subcomandos — start, list, status, ship, merge, ci, diff, sync, adopt, rename y más

Instalación

cargo install git-parsec  

O también puedes descargar binarios para macOS / Linux desde GitHub Releases.

A quién le puede servir

• Quienes trabajan con varios tickets al mismo tiempo (desarrollo en paralelo basado en worktree)
• Quienes están cansados de las tareas repetitivas entre Jira y Git
• Quienes quieren reducir el costo del cambio de contexto en un monorepo
• Quienes quieren dar entornos de trabajo independientes a agentes de IA (como Claude Code)

Enlaces

• GitHub: https://github.com/erishforG/git-parsec
• Instalación: cargo install git-parsec

Está hecho en Rust, es ligero y se puede aplicar de inmediato a repositorios git existentes.
¡Se agradecen comentarios o preguntas!

[puddingman220]

Hace poco vi una entrada de blog técnico sobre worktrees en paralelo y me interesó, pero me dio pena no poder ver cómo estaba implementado; ¡con este proyecto open source sí que habría que explorarlo a fondo!

Abajo está la entrada de blog que vi.
https://medium.com/ajd-tech/…

[erish2150]

¡Gracias! Incluso viéndolo por encima, el contenido que escribiste en el blog está realmente muy bien hecho.
Si se da la oportunidad, échale un vistazo y, si hay algo que no te convenza o que te gustaría mejorar, no dudes en abrir un issue o mandar un PR.

[shaun0927]

Creo que los worktree en paralelo siguen un enfoque de pasar de un work dirty a un clean nicely,
y pienso que esta será la forma principal de desarrollo en el futuro.
Parece un muy buen repo.

[erish2150]

Gracias :) Expresaste muy bien lo que yo tenía en mente.

[bigcataroido]

Es llamativo el enfoque de forzar el trabajo en paralelo basado en worktree.

Yo también, cuando manejo varios tickets al mismo tiempo,
he estado trabajando con una combinación de tmux + varias branches para separar cada entorno de trabajo,
pero al final siempre tuve el problema de que la gestión del estado terminaba enredándose.

Agrupar el lifecycle como start/ship/merge, como hace parsec,
parece que más bien podría ir en la dirección de reducir errores.

Tengo una duda:
cuando hay varios PR abiertos al mismo tiempo y cambia el orden de merge
o se da una situación en la que hace falta hacer rebase, ¿cómo funciona stack sync en ese caso?

[erish2150]

¡Gracias por el interés!

stack sync realiza el rebase en orden topológico según la relación padre-hijo.

Cómo funciona

parsec start PROJ-1                 # basado en main  
parsec start PROJ-2 --on PROJ-1     # basado en la rama PROJ-1  
parsec start PROJ-3 --on PROJ-2     # basado en la rama PROJ-2  

parsec stack sync                   # rebase automático en el siguiente orden  
# 1. PROJ-1 → rebase sobre origin/main  
# 2. PROJ-2 → rebase sobre la rama PROJ-1  
# 3. PROJ-3 → rebase sobre la rama PROJ-2  

La estructura recorre desde la raíz con BFS y hace rebase de cada hijo sobre la rama padre. Si `main` se actualiza, los cambios se propagan naturalmente desde la raíz.  

## Cuando cambia el orden del merge  

Actualmente está diseñado asumiendo que se hace merge empezando por la parte inferior del stack (los padres). Si un PR intermedio se mergea primero, en el siguiente `stack sync` los hijos de ese nodo fallarán porque no podrán encontrar al padre. En ese caso,  
hay que reasignar manualmente la base.  

## Cuando hay conflictos  

Si ocurre un conflicto durante el rebase, solo esa rama se revierte con `rebase --abort` y el resto continúa. Como el resultado muestra en una tabla qué tickets tuvieron éxito o fallaron, solo hace falta resolver manualmente los que fallaron.