Dépôts Git et synchronisation des tickets
Connectez un compte Git, associez un dépôt au projet et configurez la synchronisation des tickets avec son fournisseur.
Connecter un compte Git personnel, lier un dépôt au projet et synchroniser les tickets du fournisseur sont des actions distinctes. Autorisez d’abord le compte ; le propriétaire du projet choisit ensuite le dépôt et peut activer la synchronisation avec les permissions requises chez le fournisseur.
Connecter Git et lier un dépôt au projet
Dans les paramètres Git du compte, connectez GitHub ou GitLab et terminez l’autorisation dans le navigateur. Accordez seulement les dépôts nécessaires. Sur desktop, revenez à l’application après le navigateur. La connexion se réutilise entre projets, sans lier automatiquement tous les dépôts.
Le propriétaire ouvre la section Git des paramètres du projet, sélectionne un dépôt disponible et confirme. Vérifiez fournisseur, nom complet du dépôt et compte d’action affiché. Les membres ne peuvent pas remplacer ce lien réservé au propriétaire. Il fournit le contexte du dépôt, le suivi des pull requests et les skills du dépôt ; la synchronisation des tickets a un interrupteur distinct.
Dépôt absent ou accès expiré
Si la liste est vide, vérifiez les permissions et l’autorisation de l’organisation ou du dépôt voulu. Reconnectez un compte expiré plutôt que de placer des jetons dans les tickets. La suppression du lien nécessite le propriétaire ; lisez la confirmation.
Une instance self-hosted peut utiliser le relais géré configuré ou les applications propres à l’opérateur. La connexion au relais est explicite et ne rend pas le fournisseur local. La disponibilité dépend de la configuration. Vérifiez la politique de l’opérateur avant d’autoriser.
Synchroniser les tickets du fournisseur Git
Comme propriétaire, ouvrez Git dans les paramètres après liaison du dépôt. Activez la synchronisation avec les permissions d’écriture requises. Les tickets importés arrivent au triage. Vérifiez le rattrapage affiché, puis titre, description et état d’un ticket distant connu.
Les états ouvert et fermé se reflètent dans les deux sens. Pour GitHub, titre et corps deviennent titre et description ; les labels alimentent catégories, priorité et effort reconnus ; le premier assigné lié est retenu et l’échéance du milestone devient celle du ticket. Les commentaires conservent auteur, identité, URL et dates distants. Les relations de blocage exigent les deux tickets dans le même projet importé. Les URL des pièces jointes restent ; leurs octets et les champs GitHub Projects n’ont pas d’équivalent natif.
Permissions, conflits et désactivation
La GitHub App nécessite Issues en lecture/écriture et les abonnements Issues, Issue comments et Issue dependencies. Les installations existantes doivent accepter les nouveaux droits. Ces correspondances GitHub ne garantissent pas tous les champs GitLab.
Un événement GitHub daté plus ancien ne remplace pas une modification locale récente. Les identifiants de livraison et de commentaires évitent les effets en doublon. Comparez les dates, puis les événements fournisseur et journaux opérateur si le rattrapage manque. Désactivez dans le même réglage réservé au propriétaire ; examinez séparément le travail déjà importé.