BranchBox · Ingénierie à code source ouvert
Isoler tout l’environnement d’exécution, pas seulement la branche.
BranchBox donne à chaque fonctionnalité son propre worktree et sa propre frontière d’exécution afin que les développeurs et les agents de codage puissent travailler en parallèle sans se disputer le même environnement applicatif.
v0.11.1 · Code source ouvert · MIT
Le problème
Isoler la branche ne suffit pas si l’environnement d’exécution reste partagé.
Le développement en parallèle devient fragile lorsque des travaux supposément séparés partagent encore des ports, des bases de données, des réseaux Docker, l’état de l’environnement ou des hypothèses de nettoyage.
Git isole l’historique du code source. Il n’isole pas le système dans lequel le code s’exécute réellement. Plus le travail se fait en parallèle — surtout avec des agents de codage — plus cette distinction devient opérationnelle.
Décision clé
Le travail logiciel en parallèle exige d’isoler l’état d’exécution, pas seulement de séparer les branches Git.
BranchBox donne à chaque fonctionnalité son propre worktree et sa propre frontière d’exécution afin que les développeurs et les agents de codage puissent travailler en parallèle sans se disputer le même environnement applicatif.
-
checkout-reliability Environnement de fonctionnalité
- Worktree
- Contexte d’exécution
- État applicatif
-
billing-rules Environnement de fonctionnalité
- Worktree
- Contexte d’exécution
- État applicatif
-
search-index Environnement de fonctionnalité
- Worktree
- Contexte d’exécution
- État applicatif
Voir en action
La séparation des environnements se voit dans la ligne de commande.
-
Démarrer un environnement de fonctionnalité
Le démarrage d’une fonctionnalité crée un arbre de travail, une branche, un environnement d’exécution conteneurisé, un projet Compose, une URL d’application et une copie de l’environnement propres à ce travail.
-
Examiner l’environnement actif
La liste des fonctionnalités montre l’environnement actif ainsi que l’exécution, la branche, les modules et l’URL qui lui appartiennent.
Architecture
La frontière d’isolation, rendue explicite.
Par fonctionnalité / isolé
Ce que BranchBox isole
Chaque fonctionnalité dispose de son propre worktree et de son propre contexte d’exécution. L’état applicatif qui provoque couramment des collisions dans le travail en parallèle demeure séparé selon l’environnement d’exécution et les modules de projet choisis.
- WorktreeBranche de fonctionnalité
- Contexte d’exécution / fournisseurConteneur dans cette capture
- État applicatif / conteneurSéparé par l’environnement d’exécution
- Ressources créées par les modulesCompose · réseau · ports · base de données selon les modules choisis
Partage délibéré par défaut
Ce que BranchBox partage délibérément
BranchBox peut monter dans les environnements de fonctionnalité certains éléments d’authentification des développeurs et de configuration des agents de codage, afin que les outils existants fonctionnent sans configuration répétée. Dans la version actuelle, branchbox init --no-coding-agents désactive les montages .codex, .claude et .gh.
- .codexAuthentification / configuration sélectionnée
- .claudeAuthentification / configuration sélectionnée
- .ghAuthentification / configuration sélectionnée
Contrôle de l’opérateur
Le compromis
BranchBox isole l’espace de travail et l’état d’exécution qui ne doivent pas entrer en collision. Il ne prétend pas que chaque identifiant ou fichier de configuration est dupliqué pour chaque fonctionnalité. Le partage de l’authentification est un choix explicite entre ergonomie et sécurité, et non un état caché.
- branchbox init --no-coding-agentsDésactive les montages des agents de codage pendant l’initialisation
- Frontière expliciteAucune garantie rétroactive pour chaque identifiant hôte ou outil tiers
Pourquoi c’est important
Le travail en parallèle exige plus que des historiques de code distincts.
BranchBox accélère le travail en parallèle en séparant les environnements applicatifs qui se nuiraient autrement, tout en rendant explicite et configurable la frontière des outils partagés.
- Pensée de produit pour plateforme de développement plutôt qu’automatisation ponctuelle
- Isolation de l’environnement d’exécution et de l’état applicatif pour le développement parallèle humain et assisté par IA
- Ingénierie d’une CLI Rust publiée et intégrée à une infrastructure applicative conventionnelle
- Frontière explicite et configurable pour l’authentification des développeurs et la configuration des agents de codage partagées
- Gestion publiée du démontage des worktrees et des ressources créées par les modules
- Transformation d’un problème d’ingénierie récurrent en logiciel réutilisable
Code source ouvert