Un utilitaire borné pour transporter état de branche et assets de projet entre machines. Le handoff v1.0 existe ; cette page ne revendique pas un usage quotidien sans preuve.
Profil de mission
- Réduire une relève de machine à une commande délibérée de chaque côté.
- Refuser d’agir dès que l’état du dépôt est ambigu, au lieu de deviner.
- Transporter l’état que Git ne transporte pas : bases de données, gros actifs de travail et matériel non suivi.
- Consigner quelle machine détient le travail, dans un canal qui ne pollue jamais l’historique du projet.
- Bloquer les secrets évidents et les fichiers non suivis surdimensionnés avant qu’ils n’atteignent un remote.
Architecture
État vérifié
Ce qui existe et a été exercé au moment de la rédaction.
- Une relève tient en deux commandes : départ sur la machine quittée, arrivée sur la machine reprise.
- L’état de relève vit dans une référence de notes Git dédiée : aucun fichier BAM n’entre dans l’historique principal.
- Le départ exécute les contrôles configurés, capture les bases SQLite via l’API de la base plutôt qu’en copiant des fichiers en cours d’écriture, commite, pousse et publie une note consignant commit, branche, machine, statut et sauvegardes.
- L’arrivée refuse d’écraser un arbre sale, récupère, tire en fast-forward uniquement, restaure Git LFS et les sous-modules, restaure les états hors Git configurés et prend possession de la relève.
- La branche de travail n’est jamais poussée en force.
- Huit conditions documentées arrêtent l’outil : branche divergente, merge, rebase, cherry-pick ou revert en cours, HEAD détachée, modifications locales à l’arrivée, secrets évidents, fichiers non suivis surdimensionnés, hook en échec et checksum invalide lors d’une restauration de base.
- Une copie locale de sécurité est conservée avant toute restauration de base.
- La configuration par projet peut exiger des tests avant le départ et lancer des commandes après l’arrivée.
- L’outil a été exercé sur l’ensemble du portefeuille actif en une seule passe d’état.
Limites assumées
Ce que ce projet n’est pas, écrit ici pour que personne n’ait à le découvrir plus tard.
- Le handoff v1.0 existe. L’adoption quotidienne n’est pas affirmée ici, faute d’artefacts capables de l’attester.
- Une partie de ce que fait cet outil est désormais aussi couverte par l’hydratation de worktrees et la reprise du plan de contrôle du portefeuille. Le recouvrement est énoncé plutôt que masqué.
- C’est un outil interne d’un seul fichier, sans dépôt dédié ni suite de tests automatisée propre.
- Il synchronise des dépôts déjà clonés. Il ne crée pas de dépôts distants et ne clone pas un compte entier.
- Il s’arrête sur divergence plutôt que de la résoudre. L’opérateur décide encore de ce que signifie un conflit.
- Le chemin Windows est documenté et installable, mais les preuves exercées viennent du côté Linux.
La plus petite infrastructure utile
BAM existe parce que le studio tourne sur deux machines et que la panne coûteuse n’est pas un disque qui meurt. C’est arriver quelque part et découvrir que le travail intéressant est resté derrière, non commité, sur l’autre bureau. Une commande au départ, une à l’arrivée, et la question cesse d’être intéressante.
Le refus est la fonctionnalité
L’essentiel de l’outil tient dans les conditions où il décline : branche divergente, opération déjà en cours, HEAD détachée, arbre sale à l’arrivée, secret dans la charge utile, fichier non suivi trop gros pour être un accident. Il s’arrête et explique au lieu d’improviser. Un outil de relève qui devine est pire que pas d’outil du tout.
L’état que Git ne transporte pas
Les bases sont capturées via l’API de la base plutôt que copiées en cours d’écriture, les gros actifs de travail circulent hors Git, et une copie de sécurité est conservée avant toute restauration. Le registre de possession vit dans une référence de notes distincte, ce qui garde l’historique du projet exempt de bavardage opérationnel.