Git Health - hygiène du dépôt

Git Health regarde comment un dépôt est utilisé, pas le code qu’il contient : branches mortes, merges sans revue, force-push sur branches protégées, commits démesurés et autres signaux d’hygiène.

Fonctionnement

• Il s’exécute côté serveur, contre le fournisseur Git, avec l’identifiant connecté du projet - pas de collector, pas d’étape CI. Tout projet avec un identifiant est couvert. Les quatre hébergeurs Git sont couverts - GitLab, GitHub, Bitbucket Cloud et Azure DevOps Repos ; une règle à laquelle un hébergeur ne peut pas répondre (par exemple la suppression par défaut de la branche source sur Bitbucket) est ignorée, pas mise en échec.
• Les analyses sont mises en file et traitées en arrière-plan ; déclenchables depuis le projet ou par les analyses planifiées.
• Chaque règle produit un constat avec l’un de quatre états ; le score du projet est une somme pondérée - un force-push pèse plus qu’un détail de nommage.

Conditions de merge et règles de push

Au-delà de la protection de branche elle-même, Git Health lit ce qu’un merge exige réellement et ce que la protection laisse encore passer :

• Approbations - une merge request exige au moins une approbation, au moins deux, et son auteur ne peut pas l’approuver lui-même.
• Conditions de merge - le merge exige un pipeline réussi et des discussions résolues.
• Pushs sur la branche par défaut - pas de force push, et pas de push direct qui contourne une merge request. Une branche protégée peut encore autoriser les maintainers, ou des personnes nommées sur la branche, à pousser directement : cela compte pour moitié ; si les développeurs peuvent pousser, cela ne compte pas du tout. Une branche non protégée est signalée une seule fois, par la règle de protection de branche ; les deux règles de push attendent que la branche soit protégée.
• Tags - au moins un tag est protégé, pour qu’une version publiée ne puisse être ni déplacée ni supprimée. Lorsqu’un projet suit ses versions par tag, la règle de protection des versions vérifie ces tags et celle-ci s’efface.

Ces points sont lus sur GitLab et GitHub ; Bitbucket Cloud et Azure DevOps les gardent dans des politiques de branche qui ne sont pas encore lues, les règles n’y sont donc pas appliquées. La protection des tags n’est lue que sur GitLab.

Attention

Les approbations exigent un GitLab sous licence. Les approbations de merge request sont une fonctionnalité de GitLab Premium / Ultimate. Sur une instance GitLab Free, les trois règles d’approbation sont ignorées (pas en échec) avec le motif les paramètres d’approbation exigent un GitLab sous licence ; les autres règles restent évaluées. GitHub n’a pas besoin de licence pour cela.

Les règles de pipeline recherchent aussi, à côté de l’analyse des secrets et des dépendances, une étape d’analyse de sécurité statique (SAST), l’analyse des images de conteneur et une nomenclature logicielle générée (CycloneDX ou SPDX). Les fichiers inclus sont lus eux aussi, modèles GitLab compris : les modèles GitLab d’analyse des dépendances et des conteneurs produisent eux-mêmes une SBOM CycloneDX. Les modèles de merge request et d’issue sont vérifiés comme fichiers du dépôt.

Note

Git Health et Conformité se partagent le travail : Git Health lit les paramètres du fournisseur et le pipeline (protection de branche, conditions de merge, étapes CI, fichiers secrets commités), Conformité lit les documents propres au dépôt (README, .gitignore, SECURITY.md, .editorconfig). Un manque est signalé par l’un des deux, pas par les deux.

Lire les résultats

• Score et note du projet, avec les constats derrière ; chacun explique ce qui a été observé et pourquoi cela compte.
• Vue de l’espace de travail - quels projets sont couverts, lesquels n’ont jamais été analysés (jamais analysé est signalé comme inconnu, pas comme sain).
• La zone Administration montre la même image à l’échelle de l’installation.

Note

Les règles se règlent par espace de travail ; une règle qui ne colle pas à votre flux se désactive au lieu de se discuter.

Clés de ticket, Sonar et versions

• La règle de branches exige une clé de ticket (GIT_BRANCH_RULE_REQUIRES_ISSUE_KEY, GitLab) - la règle de push du projet (branch name regex) est lue. Elle est respectée quand la règle refuse une branche sans clé (feature/add-login) et en accepte une avec clé (feature/PROJ-123-add-login, ou en minuscules feature/proj-123-...). Elle est jugée sur ce qu’elle fait à des noms d’exemple, pas sur sa formulation.
• Résultats Sonar dans la merge request (CI_SONAR_MR_REPORT) - le pipeline écrit le résultat SonarQube dans la merge request : un job qui le publie dans la description, ou l’analyse de merge request propre à Sonar (sonar.pullrequest.key). Un pipeline sans SonarQube est ignoré ici ; ce manque est signalé par la règle SonarQube.
• Les clés en minuscules comptent : bugfix/proj-123 nomme le ticket aussi clairement que bugfix/PROJ-123 dans la règle de nommage des branches.
• Promotions de version - une merge request qui amène une branche release/ dans la branche par défaut porte tous les tickets de la version ; elle n’est donc pas comptée dans la règle des titres de merge request, comme les commits de fusion ne le sont pas dans la règle des commits.
• Protection par motif - une branche protégée par un motif (release/*) compte comme protégée, dans la règle des branches de version et partout ailleurs.
• Les fichiers de verrouillage sont cherchés jusqu’à trois dossiers de profondeur (src/<layer>/<Project>/packages.lock.json), dossiers de code d’abord ; une recherche que l’analyse n’a pas pu terminer est ignorée, jamais absente.

Règles retirées

Ces règles ne s’exécutent plus. Les constats des analyses précédentes restent dans l’historique ; la règle qui répond désormais à la même question figure à côté de chacune.

Règle	Remplacée par	Pourquoi
REPO_README_PRESENT	Conformité DOC_README_EXISTS	Les documents du dépôt sont vérifiés par Conformité ; le même fichier manquant était signalé dans les deux modules.
REPO_GITIGNORE_PRESENT	Conformité REPO_GITIGNORE_EXISTS	Même raison.
REPO_SECURITY_MD_PRESENT	Conformité SEC_POLICY_EXISTS	Même raison.