git-parsec — de la création d’un worktree au merge de PR avec un seul ticket

Un outil CLI qui automatise un workflow de développement parallèle basé sur Git worktree.

Problème résolu

Quand on travaille sur plusieurs tickets en parallèle sans changer de branche, git worktree est un excellent choix.
Mais pour l’utiliser en production, il faut répéter beaucoup d’opérations :

• créer un worktree et nommer la branche → en une seule ligne avec parsec start PROJ-123
• pousser, créer une PR et ajouter le lien du ticket → en une seule ligne avec parsec ship PROJ-123
• vérifier la CI, merger et nettoyer le worktree → en une seule ligne avec parsec merge PROJ-123

Les tâches répétitives de tous les jours se réduisent ainsi à une seule commande chacune.

Workflow principal

parsec start PROJ-123       # worktree + branche + intégration du ticket Jira  
# ... code ...  
parsec ship PROJ-123        # push → création de PR (titre/lien du ticket inclus automatiquement)  
parsec ci PROJ-123          # affiche un tableau d’état de la CI  
parsec merge PROJ-123       # attente de la CI → merge squash → nettoyage automatique du worktree  

Fonctionnalités principales

Intégration avec les trackers

• Jira / GitHub Issues — reprise automatique du titre du ticket, transition d’état, vue board, inbox
• parsec ticket — consulter le détail d’un ticket depuis le terminal
• parsec board — consulter le sprint board Jira en CLI

Gestion des worktrees

• Intégration shell — avec parsec switch, déplacement automatique en cd entre worktrees
• Stacked PR — construction d’une chaîne de PR avec l’option --on, rebase groupé avec stack sync
• Undo — restaurer en une commande un worktree nettoyé par erreur

Automatisation

• Release — génération automatique du tag + merge + GitHub Release + changelog
• Modes de sortie Human / JSON / Quiet — intégration facile avec des scripts CI
• 27 sous-commandes — start, list, status, ship, merge, ci, diff, sync, adopt, rename, etc.

Installation

cargo install git-parsec  

Ou téléchargez les binaires macOS / Linux depuis GitHub Releases.

Utile pour

• les personnes qui travaillent sur plusieurs tickets en parallèle (développement parallèle basé sur worktree)
• les personnes lassées des tâches répétitives entre Jira et Git
• les personnes qui veulent réduire le coût du context switching dans un monorepo
• les personnes qui veulent fournir un environnement de travail isolé à des agents IA (comme Claude Code)

Liens

• GitHub: https://github.com/erishforG/git-parsec
• Installation: cargo install git-parsec

Écrit en Rust, il reste léger et peut être appliqué directement à un dépôt git existant.
Les retours et questions sont les bienvenus !

[puddingman220]

J’ai récemment lu un blog technique sur les worktrees parallèles et cela m’a intrigué, mais j’ai été déçu de ne pas pouvoir voir les détails de l’implémentation ; il va donc falloir que j’explore cet open source plus en profondeur !

Voici l’article de blog que j’ai lu.
https://medium.com/ajd-tech/…

[erish2150]

Merci ! Le contenu de votre article de blog est lui aussi excellent, même à une lecture rapide.
Si vous en avez l'occasion, n'hésitez pas à le parcourir et, s'il y a des points qui ne vous plaisent pas ou que vous souhaitez améliorer, ouvrez librement une issue ou envoyez une PR !

[shaun0927]

Je considère que les worktrees parallèles suivent une approche du type work dirty -> clean nicely, et je pense que cela deviendra à l’avenir la principale manière de développer. Ça a l’air d’être un bon repo.

[erish2150]

Merci :) Vous avez très bien formulé les points que j’avais en tête.

[bigcataroido]

L’approche qui consiste à imposer le travail en parallèle sur la base de worktree est assez impressionnante.

Moi aussi, quand je traite plusieurs tickets en même temps,
j’utilise une combinaison de tmux + plusieurs branches pour séparer chaque environnement de travail,
mais au final, j’avais toujours des problèmes d’état qui finissaient par s’emmêler.

Le fait de regrouper le cycle de vie avec start/ship/merge, comme parsec,
semble au contraire aller dans le sens d’une réduction des erreurs.

J’ai une question :
quand plusieurs PR sont ouvertes en même temps, si l’ordre de merge change
ou qu’une situation nécessite un rebase, comment fonctionne le stack sync ?

[erish2150]

Merci pour votre intérêt !

stack sync effectue les rebase dans l’ordre du tri topologique, en se basant sur la relation parent-enfant.

Fonctionnement

parsec start PROJ-1                 # basé sur main  
parsec start PROJ-2 --on PROJ-1     # basé sur la branche PROJ-1  
parsec start PROJ-3 --on PROJ-2     # basé sur la branche PROJ-2  

parsec stack sync                   # rebase automatique dans l’ordre ci-dessous  
# 1. PROJ-1 → rebase sur origin/main  
# 2. PROJ-2 → rebase sur la branche PROJ-1  
# 3. PROJ-3 → rebase sur la branche PROJ-2  

La structure parcourt l’arbre en BFS à partir de la racine, puis rebase chaque enfant sur la branche parente. Si `main` a été mis à jour, les changements se propagent naturellement à partir de la racine.  

## Quand l’ordre de merge change  

Actuellement, l’outil est conçu en partant du principe qu’on merge depuis le bas de la stack (les parents) vers le haut. Si une PR intermédiaire est merge en premier, les enfants de ce nœud ne trouveront plus leur parent lors du prochain `stack sync`, ce qui provoquera un échec. Dans ce cas,  
il faut redéfinir manuellement la base.  

## En cas de conflit  

Si un conflit survient pendant un rebase, seule la branche concernée est annulée via `rebase --abort`, et le reste continue. Comme le résultat indique sous forme de tableau quels tickets ont réussi ou échoué, il suffit ensuite de résoudre manuellement uniquement ceux qui ont échoué.