Quand on développe un produit de sécurité (firewall, VPN, application de chiffrement…) on cherche a donner confiance dans son produit et on est bien souvent amené pour cela à passer des certifications (CSPN, Critères Communs, etc) et à ainsi prouver qu’on applique de «bonnes pratiques» de matière développement : gestion des bugs, tests, utilisation d’un SCM. Un point important est de montrer que le code source du produit est maîtrisé, c’est à dire qu’aucune modification, intentionnelle ou non, ne peut être intégrée au produit sans avoir été validé. Et pour cela Git est un outil qui peut réellement aider.
Subversion, probablement le SCM le plus utilisé aujourd’hui, impose un modèle de développement centralisé. Tous les développeurs poussent leurs modifications vers un unique dépôt central partagé. Ce modèle a plusieurs inconvénients quand on désire tracer les modifications dans la base de code.
D’abord il faut donner aux développeurs des droits d’accès suffisamment fins pour qu’ils puissent commiter dans le dépôt, sans pour autant les autoriser à avoir accès à toute la base de code, tant en écriture qu’en lecture. Ensuite il faut suivre les modifications apportées au code par les équipes de développement. Il est possible de développer les nouvelles fonctionnalités ou corriger les bugs dans des branches, avec tous les problèmes de merge qui peuvent survenir. On peut également forcer l’utilisation du numéros de référence d’un ticket du bugtracker dans les messages de commits. Dans ce cas il faudra bien sûr compter avec les erreurs sur le numéro du ticket ou les oublis mais également avec la relecture de complexes et multiples diff… Et je ne parle pas de l’historique du dépôt.
Avec Git, le problème du workflow disparaît car vous pouvez l’adapter à votre façon de développer. On peut illustrer ça avec l’exemple du modèle de développement du noyau Linux (schéma ci-dessous) : un développeur privilégié (le dictateur) est autorisé à écrire dans le dépôt de référence (blessed repository). Les développeurs clonent ce dépôt, et poussent leurs patchs vers des «développeurs de confiance» (les lieutenants). Les lieutenants valident ces modifications, le dictateur peut alors venir les chercher auprès des lieutenants. Le dictateur décide alors d’intégrer ou non ces modifications dans le dépôt de référence.
En outre, avec Git finis les multiples commits pour implémenter une fonctionnalité : grâce au merge de branches et au rebase, le développeur fournit est en mesure de ne livrer qu’un unique commit. De cette façon l’historique du dépôt est clair et propre mais surtout cela simplifie énormément la revue de code.
Pour finir j’ajoute également que Git permet de signer les tags permettant ainsi de garantir l’origine de toutes les modifications du code importées dans le dépôt de référence.
Pour conclure je terminerai sur le fait que ce que je raconte ici sur Git est également vrai pour d’autres DVCS tels que Mercurial ou Bazaar (à vérifier tout de même pour la signature des tags).
Quelques références :
Si vous chercher à mieux comprendre le fonctionnement du modèle de sécurité Android je vous conseille fortement de regarder cette vidéo. Dans cette excellente session de la conférence 
