9 min lecture • Guide 864 of 877
Lier les tâches aux dépôts GitHub, GitLab et Bitbucket
Connecter les tâches aux dépôts de code élimine le fossé entre la gestion de projet et le travail de développement réel. Quand les commits, branches et pull requests sont liés directement aux tâches, les équipes obtiennent une visibilité complète sur quels changements de code correspondent à quelles exigences—plus de devinettes ni de suivi manuel.
Aperçu de l'intégration Git
| Plateforme | Méthode de connexion | Fonctionnalités |
|---|---|---|
| GitHub | OAuth + Webhook | Commits, PRs, branches, issues |
| GitLab | OAuth + Webhook | Commits, MRs, branches |
| Bitbucket | OAuth + Webhook | Commits, PRs, branches |
Configurer l'intégration Git
CONNECTER VOTRE DÉPÔT
═════════════════════
ÉTAPE 1 : ACCÉDER AUX PARAMÈTRES D'INTÉGRATION
─────────────────────────────────────
GitScrum → Projet → Paramètres → Intégrations
├── Sélectionner "GitHub" / "GitLab" / "Bitbucket"
├── Cliquer sur "Connecter"
└── Autoriser l'accès GitScrum
ÉTAPE 2 : SÉLECTIONNER LE DÉPÔT
─────────────────────────────────────
Après autorisation :
├── La liste des dépôts apparaît
├── Sélectionner le dépôt du projet
├── Configurer le webhook automatiquement
└── Statut de connexion : "Connecté"
ÉTAPE 3 : CONFIGURER LE COMPORTEMENT
─────────────────────────────────────
Paramètres optionnels :
├── Modèle de noms de branches
├── Format des messages de commit
├── Modèle de description de PR
└── Déplacement auto sur fusion
VÉRIFICATION :
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Intégration GitHub │
│ ──────────────────────────────── │
│ Dépôt : acme/dashboard │
│ Statut : ✓ Connecté │
│ Dernière sync : il y a 2 min │
│ │
│ [Déconnecter] [Actualiser] [Config] │
└─────────────────────────────────────┘
Lier les commits aux tâches
CONVENTIONS DE MESSAGES DE COMMIT
═════════════════════════════════
RÉFÉRENCER LA TÂCHE DANS LE COMMIT :
─────────────────────────────────────
Inclure l'ID de tâche dans le message de commit :
git commit -m "Ajouter validation paiement #task-123"
git commit -m "Corriger bug login [GS-456]"
git commit -m "Implémenter endpoint API (Task: 789)"
GitScrum automatiquement :
├── Détecte la référence de tâche
├── Lie le commit à la tâche
├── Affiche le commit dans l'activité de la tâche
└── Met à jour la chronologie de la tâche
LE COMMIT APPARAÎT DANS LA TÂCHE :
─────────────────────────────────────
┌─────────────────────────────────────────────────┐
│ Tâche : Implémenter validation des paiements │
├─────────────────────────────────────────────────┤
│ ACTIVITÉ │
│ │
│ 🔀 Commit lié il y a 2 min│
│ "Ajouter validation paiement #task-123" │
│ par jean@acme.co │
│ → main (a4f2b1c) │
│ │
│ 💬 Commentaire ajouté il y a 1 h │
│ "Début de l'implémentation" │
│ │
└─────────────────────────────────────────────────┘
BONNES PRATIQUES :
─────────────────────────────────────
✓ Toujours référencer l'ID de tâche dans les commits
✓ Utiliser un format cohérent dans toute l'équipe
✓ Inclure l'ID de tâche en première ligne
✓ Ajouter le contexte dans le corps du commit
Nommage des branches pour liaison
CONVENTIONS DE NOMS DE BRANCHES
═══════════════════════════════
FORMATS RECOMMANDÉS :
─────────────────────────────────────
feature/task-123-validation-paiement
bugfix/GS-456-erreur-login
hotfix/789-patch-securite-critique
Structure :
├── type/ → feature, bugfix, hotfix
├── task-id → correspond à la tâche GitScrum
└── description → résumé lisible
LIAISON AUTOMATIQUE DES BRANCHES :
─────────────────────────────────────
Quand la branche contient l'ID de tâche :
├── GitScrum détecte la création de branche
├── Lie la branche à la tâche
├── Affiche le statut de branche dans la tâche
└── Suit le cycle de vie de la branche
VUE DE TÂCHE AVEC BRANCHE :
─────────────────────────────────────
┌─────────────────────────────────────────────────┐
│ Tâche : Validation des paiements │
├─────────────────────────────────────────────────┤
│ STATUT │
│ ────── │
│ Colonne : En cours │
│ Branche : feature/task-123-validation-paiement │
│ ↳ 3 commits devant main │
│ PR : #42 (Ouverte - Prête pour revue) │
│ │
└─────────────────────────────────────────────────┘
Intégration des Pull Requests
LIER LES PULL REQUESTS AUX TÂCHES
═════════════════════════════════
MODÈLE DE DESCRIPTION DE PR :
─────────────────────────────────────
## Résumé
Implémente la logique de validation des paiements.
## Tâche associée
Closes #task-123
## Modifications
- Ajout du middleware de validation
- Mise à jour des réponses API
- Ajout des tests unitaires
## Tests
- [x] Tests unitaires passent
- [x] Tests manuels terminés
DÉTECTION PAR GitScrum :
─────────────────────────────────────
Quand la PR est ouverte :
├── Détecte la référence de tâche
├── Lie la PR à la tâche
├── Affiche le statut de la PR dans la tâche
└── Met à jour avec les changements de la PR
CYCLE DE VIE DE LA PR DANS LA TÂCHE :
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Pull Request #42 │
│ ────────────────── │
│ Statut : Ouverte │
│ Revues : 1/2 approuvées │
│ Checks : ✓ Tous passent │
│ Fusionnable : Oui │
│ │
│ [Voir sur GitHub] │
└─────────────────────────────────────┘
Mises à jour automatiques des tâches
AUTOMATISER LE FLUX AVEC LES ÉVÉNEMENTS GIT
════════════════════════════════════════════
AUTOMATISATION DE COLONNE : SUR FUSION DE PR
─────────────────────────────────────
Paramètres Projet → Tableau → Paramètres Colonne → Done
Déclencheur d'automatisation :
├── Quand : Pull Request fusionnée
├── Action : Déplacer la tâche vers cette colonne
├── Additionnel : Auto-archiver après 7 jours
Résultat :
├── Le développeur fusionne la PR
├── La tâche se déplace vers Done automatiquement
├── Pas de mise à jour manuelle nécessaire
└── Statut du projet toujours précis
FLUX D'AUTOMATISATION :
─────────────────────────────────────
Développeur GitScrum
│ │
│ Créer branche │
│ feature/task-123-... │
├──────────────────────────►│ Branche liée
│ │
│ Push commits │
│ "Fix validation #123" │
├──────────────────────────►│ Commits liés
│ │
│ Ouvrir Pull Request │
│ │
├──────────────────────────►│ PR liée
│ │ Tâche → En revue
│ │
│ Fusionner PR │
│ │
├──────────────────────────►│ Tâche → Done
│ │ (automatique)
│ │
Projets multi-dépôts
TRAVAILLER AVEC PLUSIEURS DÉPÔTS
════════════════════════════════
SCÉNARIO : FRONTEND + BACKEND
─────────────────────────────────────
Projet : Plateforme E-commerce
├── Dépôt 1 : acme/frontend (React)
├── Dépôt 2 : acme/backend (Node.js)
└── Dépôt 3 : acme/mobile (React Native)
CONFIGURATION :
─────────────────────────────────────
1. Connecter tous les dépôts au même projet
2. Utiliser des références de tâches cohérentes
3. Suivre le travail multi-dépôt dans une seule tâche
TÂCHE AVEC PLUSIEURS DÉPÔTS :
─────────────────────────────────────
┌─────────────────────────────────────────────────┐
│ Tâche : Implémenter flux de checkout │
├─────────────────────────────────────────────────┤
│ CODE LIÉ │
│ │
│ acme/frontend │
│ ├── Branche : feature/task-123-checkout │
│ ├── Commits : 5 │
│ └── PR : #67 (Fusionnée) │
│ │
│ acme/backend │
│ ├── Branche : feature/task-123-checkout-api │
│ ├── Commits : 8 │
│ └── PR : #45 (Ouverte) │
│ │
└─────────────────────────────────────────────────┘
Visibilité et rapports
DONNÉES GIT DANS LES RAPPORTS DE PROJET
═══════════════════════════════════════
MÉTRIQUES PAR TÂCHE :
─────────────────────────────────────
Pour chaque tâche :
├── Total des commits
├── Contributeurs
├── Lignes modifiées (+/-)
├── Temps du premier commit à la fusion
└── Temps de réponse des revues
MÉTRIQUES DU PROJET :
─────────────────────────────────────
Sur tout le projet :
├── Commits par sprint
├── PRs ouvertes/fusionnées/fermées
├── Temps moyen de fusion
├── Churn de code par fonctionnalité
└── Activité des contributeurs
RAPPORT DE SPRINT AVEC DONNÉES GIT :
─────────────────────────────────────
┌─────────────────────────────────────────────────┐
│ Sprint 24 - Activité de code │
├─────────────────────────────────────────────────┤
│ │
│ Commits : 127 │
│ Pull Requests : 18 (16 fusionnées, 2 ouvertes) │
│ Contributeurs : 5 │
│ Lignes ajoutées : 2 340 │
│ Lignes supprimées : 890 │
│ │
│ Revue PR moy. : 4,2 heures │
│ Temps fusion moy. : 6,8 heures │
│ │
└─────────────────────────────────────────────────┘
Étapes d'implémentation dans GitScrum
GUIDE DE CONFIGURATION COMPLET
══════════════════════════════
ÉTAPE 1 : CONNECTER LE DÉPÔT
─────────────────────────────────────
Paramètres Projet → Intégrations
├── Sélectionner le fournisseur (GitHub/GitLab/Bitbucket)
├── Autoriser OAuth
├── Sélectionner le dépôt
└── Vérifier la connexion
ÉTAPE 2 : CONFIGURER LES CONVENTIONS D'ÉQUIPE
─────────────────────────────────────
Convenir de :
├── Noms de branches : type/task-id-description
├── Format de commit : "Message #task-id"
├── Modèle de PR avec référence de tâche
└── Documenter dans le wiki du projet
ÉTAPE 3 : CONFIGURER LES AUTOMATISATIONS
─────────────────────────────────────
Paramètres Tableau → Automatisations de colonnes
├── "En revue" → Quand PR ouverte
├── "Done" → Quand PR fusionnée
└── Activer les notifications
ÉTAPE 4 : FORMER L'ÉQUIPE
─────────────────────────────────────
Partager avec les développeurs :
├── Comment référencer les tâches
├── Conventions de noms de branches
├── Comportement attendu des automatisations
└── Avantages de la liaison
ÉTAPE 5 : SURVEILLER ET AFFINER
─────────────────────────────────────
Après 1-2 sprints :
├── Vérifier la précision des liaisons
├── Revoir les déclencheurs d'automatisation
├── Recueillir les retours de l'équipe
└── Ajuster les conventions si nécessaire
Bonnes pratiques
- Nommage cohérent - Utiliser des noms de branches standards avec IDs de tâches
- Référencer dans les commits - Toujours inclure l'ID de tâche dans les messages de commit
- Modèles de PR - Créer des modèles qui demandent la référence de tâche
- Automatiser les transitions - Configurer les déplacements de colonnes sur événements PR
- Connecter tous les dépôts - Lier tous les dépôts du projet pour une visibilité complète
- Former l'équipe - S'assurer que tous connaissent les conventions
- Réviser régulièrement - Vérifier que la liaison fonctionne comme prévu
- Documenter les conventions - Stocker les standards d'équipe dans NoteVault