Stratégie Git et worktree

Git offre à Agent Teams le meilleur parcours de revue : des diffs ciblés, une visibilité des branches, des modifications délimitées par tâche et un travail parallèle plus sûr.

Choisir une stratégie

Stratégie	À utiliser quand	Compromis
Worktree principal	Travail en solo, modifications de documentation uniquement, ou un seul coéquipier à la fois	Simple, mais les modifications parallèles peuvent entrer en collision
Branche de fonctionnalité	Une équipe travaille sur une modification cohérente unique	Cible de revue propre, mais les coéquipiers partagent toujours les fichiers
Isolation par worktree	Plusieurs coéquipiers OpenCode peuvent modifier le même dépôt en parallèle	Meilleure isolation, mais la fusion/revue demande plus de discipline

Commencez simple. Ajoutez l'isolation par worktree lorsque des modifications parallèles sont probables, et non parce que chaque tâche nécessiterait un checkout distinct.

Quand activer l'isolation par worktree

Activez-la pour les coéquipiers OpenCode quand :

• deux coéquipiers ou plus peuvent modifier le même dépôt en même temps
• une tâche peut exécuter des formateurs, des générateurs de code ou des tests étendus
• vous souhaitez que la branche et le diff de chaque coéquipier restent séparés
• l'espace de travail du lead est sale et ne devrait pas recevoir de modifications directes

Laissez-la désactivée quand :

• la tâche est en lecture seule
• un seul coéquipier détient toutes les modifications
• le dépôt n'est pas suivi par Git
• vous avez besoin d'un chemin de runtime qui ne prend pas en charge ce mode d'isolation

WARNING

L'isolation par worktree s'applique actuellement aux membres OpenCode et nécessite un projet suivi par Git.

Hygiène des branches

Avant de démarrer un travail en parallèle :

git status --short
git branch --show-current

Utilisez une branche propre lorsque c'est possible. Si le worktree principal contient déjà des modifications de l'utilisateur, demandez aux agents de ne pas annuler les fichiers sans rapport et de garder un périmètre de tâche étroit.

Style de branche recommandé :

agent/<team-or-task>/<short-purpose>

Exemples :

agent/docs/mcp-guide
agent/review/task-log-filtering
agent/ui/code-review-polish

Flux de revue

Pour les worktrees isolés, examinez le diff du coéquipier avant de fusionner ou d'appliquer les modifications dans l'espace de travail principal.

1. Vérifiez que le commentaire de résultat de la tâche nomme le périmètre modifié et la vérification.
2. Inspectez le diff de la tâche dans l'interface de revue.
3. Demandez des modifications sur la tâche si le diff touche des fichiers sans rapport.
4. Approuvez uniquement après que les tests ou les vérifications manuelles correspondent au risque de la tâche.
5. Fusionnez ou appliquez les modifications délibérément.

Ne fusionnez pas automatiquement la sortie d'un worktree juste parce que la tâche est terminée. L'achèvement signifie que l'agent estime que le travail est prêt pour la revue.

Politique de conflits

Utilisez cette politique pour les équipes en parallèle :

Situation	Action
Deux coéquipiers modifient le même fichier	Mettez une tâche en pause ou désignez un responsable unique de l'intégration
Des fichiers générés ont été modifiés de manière étendue	Exigez un commentaire expliquant le générateur et la commande
Le worktree principal contient des modifications sans rapport	Préservez-les et n'examinez que les modifications propres à la tâche
La branche du worktree diverge	Rebasez ou fusionnez manuellement après la revue, pas dans une tâche d'agent floue

Exemple de prompt de tâche

Implement the settings validation fix in your assigned worktree. Keep edits inside src/features/settings and focused tests. Do not touch provider auth or task storage. Post the test command and result before completing the task.

Ce prompt fonctionne parce qu'il nomme la zone autorisée, les frontières sensibles et la preuve d'achèvement.

Guides associés

• Créer une équipe
• Revue de code
• Exemples de briefs d'équipe
• Configuration du runtime