Intégration Git

Les opérations Git s’exécutent sur la machine serveur dans le dépôt du projet. L’application bureau les visualise et les déclenche ; elle ne copie pas un dépôt distant sur le client.

Dépôt principal ou worktree

À la création d’une carte, choisissez si l’agent travaille dans le chemin principal ou un worktree Git isolé.

• Le dépôt principal est simple, mais des tâches concurrentes peuvent toucher les mêmes fichiers et le même index.
• Le worktree crée un dossier de travail et une branche séparés, isolant système de fichiers et index Git.

Les worktrees exigent un dépôt Git valide et une colonne compatible. Stib peut générer la branche depuis la carte ou accepter un nom personnalisé. Toute branche que Stib crée pour une carte porte son numéro : un nom fix/scroll est enregistré comme fix/card-<id>-scroll, et un nom qui ne laisse plus de place au numéro est refusé. Créer un worktree ne commit, push, merge ni ouvre une pull request automatiquement. Avant de le créer, Stib récupère la branche de base sur son remote (une quinzaine de secondes au plus, une fois par branche et par demi-minute) pour que la carte parte d’un code à jour : une branche locale en retard est avancée en fast-forward si aucun worktree ne l’utilise, sinon la carte part de la branche distante. Si le remote ne répond pas, la carte part de la branche locale.

Politique de worktree du projet

Un projet peut décider pour ses cartes dans Paramètres du projet → Git, un onglet affiché uniquement pour les dépôts Git.

• Worktree des nouvelles cartes :

  • Au choix, décoché (par défaut) : le formulaire de création propose un worktree, désactivé.
  • Au choix, coché : le formulaire part avec le worktree activé. On peut toujours le retirer.
  • Obligatoire : chaque nouvelle carte a son propre worktree, quelle que soit son origine — formulaire, CLI, API ou import d’intégration.
  • Interdit : chaque nouvelle carte travaille dans le dépôt principal. Préparer un worktree depuis le board et forker une conversation dans une nouvelle carte sont refusés.

  La politique s’applique à la création d’une carte ; les cartes existantes gardent leur réglage. Une carte existante peut encore être alignée sur la politique, jamais s’en écarter. Les deux modes « au choix » ne font que pré-remplir les formulaires : le CLI et l’API gardent leur propre défaut, qui est le worktree.

• Branche de base par défaut : la branche dont part un nouveau worktree quand sa création n’en précise aucune. Une branche distante (origin/dev) est acceptée. Vide, c’est la branche active du dépôt principal.

• Nommer les branches par IA : quand personne n’a saisi de nom, Stib en génère un depuis le prompt de la carte au moment où il crée le worktree, avec le même identifiant que le bouton ✦ du formulaire, et y ajoute le numéro de la carte (fix/card-<id>-scroll-jump). En cas d’échec, la branche porte le nom tiré de la carte (feat/card-<id>-<titre>).

Onglet Diff de la carte

L’onglet Diff suit les changements du dépôt/worktree actif. Relisez-les avant d’envoyer une consigne ou déplacer la carte. Un agent annulé ou en erreur peut avoir laissé un diff utile.

Des fichiers générés envahissent la liste (sortie de build, logs) ? Clic droit sur un fichier, une sélection ou un dossier, puis Ajouter au .gitignore. Stib ajoute une règle exacte par chemin (/chemin/vers/dist/ pour un dossier) au .gitignore à la racine du dépôt. Une règle n’a aucun effet sur les fichiers déjà suivis par Git : quand la cible en contient, Ignorer et ne plus suivre les retire aussi de l’index. Ils restent sur le disque, et leur retrait apparaît dans Stagés, prêt à être commité avec le .gitignore. Le même menu existe dans l’espace Git du projet.

Espace Git

Ouvrez le menu d’un projet puis Dépôt Git.

Il comprend :

• Historique — graphe et détails des commits ;
• Changements — fichiers staged/unstaged, hunks, diff, staging et préparation du commit ;
• Branches — informations locales et distantes ;
• Worktrees — dossiers liés et leurs branches ;
• Stashes — entrées de stash du dépôt ;
• Recherche — commits ou historique du dépôt.

Les actions propres au bureau ouvrent un fichier dans l’éditeur préféré ou révèlent le projet. Les opérations distantes dépendent des identifiants et du fournisseur Git configurés.

Séquence de revue sûre

1. Confirmez le dépôt/worktree dans l’en-tête.
2. Rafraîchissez puis inspectez fichiers non suivis, unstaged et staged.
3. Relisez le diff complet, y compris fichiers générés ou lockfiles.
4. Lancez les commandes de validation du projet.
5. Stagez volontairement et écrivez un commit explicite.
6. Pushez ou ouvrez une revue avec votre workflow fournisseur habituel.

Stib protège certaines opérations lorsque des changements pourraient être perdus, mais ne sait pas si chaque fichier généré est volontaire.

Nettoyage

Une colonne peut nettoyer son worktree à la transition et les outils projet peuvent supprimer en masse les worktrees éligibles. Le nettoyage peut être bloqué par des changements non commités ou un processus actif. Préservez le travail important avant : archiver la carte ne sauvegarde pas ses fichiers non commités.

Suite : Cartes et Fonctions bureau.