git-parsec — da criação de worktree ao merge do PR com um único ticket

Uma ferramenta CLI que automatiza um fluxo de trabalho de desenvolvimento paralelo baseado em Git worktree.

Problema que resolve

Quando você trabalha em vários tickets ao mesmo tempo sem trocar de branch, git worktree é uma ótima opção.
Mas, para usar isso no dia a dia, há muitas tarefas repetitivas:

• criar a worktree e definir o nome da branch → tudo em uma linha com parsec start PROJ-123
• dar push, criar o PR e anexar o link do ticket → tudo em uma linha com parsec ship PROJ-123
• verificar a CI, fazer o merge e limpar a worktree → tudo em uma linha com parsec merge PROJ-123

As tarefas que você repetia toda vez se reduzem a um comando por etapa.

Fluxo de trabalho principal

parsec start PROJ-123       # worktree + branch + integração com ticket do Jira  
# ... codando ...  
parsec ship PROJ-123        # push → cria PR (inclui automaticamente título/link do ticket)  
parsec ci PROJ-123          # exibe a tabela de status da CI  
parsec merge PROJ-123       # espera a CI → squash merge → limpeza automática da worktree  

Principais recursos

Integração com trackers

• Jira / GitHub Issues — aplica automaticamente o título do ticket, transição de status, visualização de board e caixa de entrada
• parsec ticket — consulta detalhes do ticket no terminal
• parsec board — visualiza o board de sprint do Jira via CLI

Gerenciamento de worktree

• Integração com shell — parsec switch move automaticamente o cd entre worktrees
• PRs em pilha — use a opção --on para montar uma cadeia de PRs, com rebase em lote via stack sync
• Undo — recupere com um comando uma worktree limpa por engano

Automação

• Release — gera automaticamente tag + merge + GitHub Release + changelog
• Modos de saída Human / JSON / Quiet — fácil de integrar com scripts de CI
• 27 subcomandos — start, list, status, ship, merge, ci, diff, sync, adopt, rename etc.

Instalação

cargo install git-parsec  

Ou você pode baixar os binários para macOS / Linux em GitHub Releases.

Útil para quem

• trabalha em vários tickets ao mesmo tempo (desenvolvimento paralelo baseado em worktree)
• está cansado de tarefas repetitivas entre Jira + Git
• quer reduzir o custo de troca de contexto em um monorepo
• quer dar ambientes de trabalho independentes para agentes de IA (como Claude Code)

Links

• GitHub: https://github.com/erishforG/git-parsec
• Instalação: cargo install git-parsec

Escrito em Rust, é leve e pode ser aplicado imediatamente a repositórios Git existentes.
Feedback e perguntas são bem-vindos!

[puddingman220]

Recentemente li um post técnico sobre worktrees paralelos e fiquei interessado, mas foi uma pena não poder ver os detalhes da implementação; acho que vou precisar explorar este open source mais a fundo!

Abaixo está o post do blog que eu vi.
https://medium.com/ajd-tech/…

[erish2150]

Obrigado! Dei uma olhada por cima no que você escreveu no blog e ficou realmente muito bem feito.
Se tiver oportunidade de conferir e achar que há algo de que não goste ou que queira melhorar, fique à vontade para abrir uma issue ou enviar um PR!

[shaun0927]

Acho que o worktree em paralelo segue uma abordagem de levar o trabalho de sujo para limpo de forma elegante,

e acredito que isso vai se tornar o principal modo de desenvolvimento no futuro.

Parece um ótimo repositório.

[erish2150]

Obrigado :) Você descreveu muito bem os pontos que eu tinha em mente.

[bigcataroido]

A abordagem de forçar trabalho paralelo com base em worktree é bem interessante.

Eu também, quando lido com vários tickets ao mesmo tempo, venho usando uma combinação de tmux + várias branches para separar cada ambiente de trabalho, mas no fim acabava tendo problemas porque o gerenciamento de estado sempre se enrolava.

Agrupar o ciclo de vida em start/ship/merge, como no parsec, parece até ser um caminho melhor para reduzir erros.

Fiquei com uma dúvida: quando vários PRs estão abertos ao mesmo tempo e a ordem de merge muda, ou quando surge uma situação em que é necessário fazer rebase, como o stack sync funciona?

[erish2150]

Obrigado pelo interesse!

stack sync executa o rebase em ordem topológica com base na relação entre pai e filho.

Como funciona

parsec start PROJ-1                 # baseado na main  
parsec start PROJ-2 --on PROJ-1     # baseado na branch PROJ-1  
parsec start PROJ-3 --on PROJ-2     # baseado na branch PROJ-2  

parsec stack sync                   # rebase automático na ordem abaixo  
# 1. PROJ-1 → rebase sobre origin/main  
# 2. PROJ-2 → rebase sobre a branch PROJ-1  
# 3. PROJ-3 → rebase sobre a branch PROJ-2  

A estrutura percorre a partir da raiz em BFS, fazendo o rebase de cada filho sobre a branch pai. Se a main for atualizada, as mudanças se propagam naturalmente a partir da raiz.

Quando a ordem de merge muda

Atualmente, o design parte do pressuposto de que o merge é feito de baixo para cima na stack, começando pelos pais. Se um PR intermediário for merged primeiro, os filhos desse nó não conseguirão encontrar o pai no próximo stack sync e a operação falhará. Nesse caso,
será necessário redefinir manualmente a base.

Em caso de conflito

Se ocorrer um conflito durante o rebase, apenas a branch em questão é revertida com rebase --abort, e o restante continua. Como o resultado mostra em tabela quais tickets tiveram sucesso ou falharam, basta resolver manualmente apenas os que falharam.