Git pour les nuls : versioning pour projets électroniques

Un bug apparu après une mise à jour firmware se retrouve parmi 1 000 commits en moins de 10 étapes avec git bisect ; dans un dossier « firmware_v2_final_VRAIMENT_final_corrigé », il ne se retrouve pas. Git pour les nuls : Git est un Distributed Version Control System (DVCS) créé en 2005 par Linus Torvalds, qui enregistre l'historique complet des modifications d'un projet et permet à plusieurs ingénieurs de collaborer sans écraser le travail des autres. Chez AESTECHNO, bureau d'études basé à Montpellier, notre équipe l'utilise depuis plus de 10 ans sur nos projets de logiciel embarqué, avec des commits atomiques sous 200 lignes et une revue de code systématique.

Sommaire

• Qu'est-ce que Git et pourquoi l'utiliser ?
• Les concepts fondamentaux expliqués simplement
• Les commandes Git essentielles
• Avantages concrets pour les projets techniques
• Cas d'usage en électronique et firmware
• Outils et plateformes recommandés
• GitHub vs GitLab vs Bitbucket : lequel choisir ?
• Merge vs rebase : quelle stratégie ?
• En résumé

Qu'est-ce que Git et pourquoi l'utiliser ?

Git est un Distributed Version Control System (DVCS) qui enregistre l'historique complet des modifications apportées à un projet, et permet à plusieurs personnes de collaborer simultanément sans risque de perte de données.

Créé en 2005 par Linus Torvalds pour gérer le noyau Linux, il est devenu l'outil de référence pour le Version Control System (VCS) de code source, firmware et documentation technique. Selon git-scm.com, la version actuelle de référence est Git 2.42 (août 2023) avec le support initial SHA-256 comme alternative à SHA-1. Git est distribué sous licence GNU General Public License (GPL) v2 d'après Wikipedia, avec une adoption supérieure à 95% parmi les projets hébergés sur les plateformes majeures.

Concrètement, Git répond à des problèmes que tout responsable de projet technique connaît :

• La perte de travail : sans Git, un fichier écrasé par erreur est perdu. Avec Git, chaque version est conservée et récupérable en quelques secondes
• Le chaos des versions : fini les dossiers « firmware_v2_final_VRAIMENT_final_corrigé ». Git gère les versions de manière structurée et fiable
• La collaboration difficile : deux ingénieurs qui modifient le même fichier en parallèle ne se marchent plus sur les pieds, Git détecte et gère les conflits
• L'absence de traçabilité : quand un bug apparaît, Git permet de retrouver exactement quelle modification l'a introduit, quand, et par qui

Git a été créé en 2005 par Linus Torvalds pour gérer le développement du noyau Linux, un projet avec des milliers de contributeurs répartis dans le monde entier. L'outil a été écrit par Linus Torvalds en moins de dix jours pour remplacer BitKeeper, comme le souligne Junio Hamano, mainteneur du projet Git depuis 2005. Le noyau Linux absorbe aujourd'hui plus de 75 000 commits par an d'après Wikipedia, tous tracés dans Git. Si Git peut gérer le noyau Linux, il peut gérer votre projet firmware.

Les concepts fondamentaux de Git expliqués simplement

Un dépôt Git est, en interne, un système de trois types d'objets : blob (contenu de fichier), tree (arborescence) et commit (snapshot horodaté), identifiés par un hash SHA-1 de 40 caractères.

La migration vers SHA-256 progresse depuis Git 2.29, et les termes techniques dépôt, commit, branche, merge peuvent sembler intimidants au premier abord, mais les concepts sous-jacents sont en réalité très intuitifs.

Cinq notions suffisent pour démarrer : le dépôt, qui contient le projet et son historique ; le commit, une photo de l'état du projet à un instant donné ; la branche, pour travailler en parallèle sans risque ; le merge, qui réunit les branches ; et le remote, la copie hébergée sur un serveur pour synchroniser l'équipe. Les sections ci-dessous les expliquent une par une, avec des exemples tirés de projets firmware.

Le dépôt (repository)

Un dépôt Git, souvent abrégé « repo », est simplement un dossier de projet qui contient l'historique complet de toutes ses modifications. Quand vous « initialisez un dépôt Git » dans un dossier, Git crée un sous-dossier caché (.git) où il stocke tout l'historique. Le dossier lui-même ne change pas d'apparence, vos fichiers restent exactement là où ils sont.

Un dépôt peut être local (sur votre ordinateur) ou distant (sur un serveur comme GitLab ou GitHub). La force de Git est que chaque personne qui travaille sur le projet possède une copie complète du dépôt, historique inclus. Même si le serveur tombe en panne, rien n'est perdu.

Le commit : une photo de votre projet

Un commit est un instantané de l'état de votre projet à un moment donné. Pensez-y comme une sauvegarde intelligente : au lieu d'enregistrer tous les fichiers à chaque fois, Git ne stocke que les différences par rapport au commit précédent. Chaque commit est accompagné d'un message qui décrit la modification effectuée, par exemple : « Correction du bug de communication SPI en mode esclave ».

Les commits forment une chaîne chronologique, l'historique de votre projet. Vous pouvez à tout moment revenir à n'importe quel commit précédent, comparer deux versions, ou identifier exactement quand un changement a été introduit. C'est cette traçabilité qui fait de Git un outil indispensable pour les projets soumis à des exigences de qualité ou de certification CE/RED.

La branche : travailler en parallèle sans risque

Une branche est une ligne de développement indépendante. Tout dépôt possède une branche principale. Sur GitHub (depuis octobre 2020) et sur GitLab (depuis la version 14.0, en 2021), les nouveaux dépôts la nomment main. L'ancien nom master reste celui des dépôts plus anciens et celui que git init crée en local, sauf si l'option init.defaultBranch (Git 2.28) vaut main. Quand un développeur veut ajouter une fonctionnalité ou corriger un bug, il crée une nouvelle branche à partir de main. Il travaille dessus librement, sans affecter la branche principale ni le travail des autres.

L'analogie la plus parlante : imaginez que main est le tronc d'un arbre, et que chaque branche est... une branche. Elle part du tronc, pousse dans sa direction, et peut éventuellement être rattachée au tronc une fois que le travail est terminé et validé.

En pratique, sur un projet firmware, vous pourriez avoir :

• main, la version stable, celle qui tourne en production
• feature/nouveau-driver-capteur, le développement d'un nouveau driver
• fix/bug-communication-ble, la correction d'un bug Bluetooth
• release/v2.1, la préparation de la prochaine version

Le merge : réunir les branches

Le merge (fusion) est l'opération qui intègre les modifications d'une branche dans une autre, typiquement, intégrer une branche de fonctionnalité dans main. Git analyse les modifications des deux côtés et les combine automatiquement. Dans la grande majorité des cas, cette fusion se fait sans intervention humaine.

Quand deux personnes ont modifié les mêmes lignes du même fichier, Git signale un « conflit » et demande à un humain de trancher. Ce n'est pas une erreur, c'est un mécanisme de sécurité. Mieux vaut résoudre un conflit explicitement que de perdre silencieusement le travail de quelqu'un.

Le remote : synchroniser avec le serveur

Un remote est un dépôt distant, la copie du projet hébergée sur un serveur (GitLab, GitHub, Bitbucket). Les opérations push (envoyer vos commits vers le serveur) et pull (récupérer les commits des autres depuis le serveur) permettent de synchroniser le travail de l'équipe. Le remote sert aussi de sauvegarde centralisée : tant que le serveur est opérationnel, le projet est en sécurité.

Les commandes Git essentielles

Les commandes Git essentielles sont un ensemble de sous-commandes qui couvrent l'initialisation d'un dépôt, le staging, le commit, la gestion des branches et la synchronisation avec un remote. Git est un outil ligne de commande avec environ 150 sous-commandes, mais 10 suffisent à couvrir 90% du travail quotidien selon la documentation officielle git-scm.com.

Le tableau ci-dessous suit l'ordre d'un cycle de travail réel : initialiser le dépôt avec git init, préparer les fichiers modifiés avec git add, enregistrer un snapshot avec git commit, créer une branche pour une nouvelle fonctionnalité avec git branch, l'intégrer avec git merge, puis consulter l'historique avec git log. Ces six commandes couvrent le cycle de base d'un projet firmware.

Les avantages concrets de Git pour les projets techniques

Git permet de garantir quatre bénéfices mesurables sur un projet électronique ou firmware : traçabilité complète, collaboration parallèle sans conflits silencieux, rollback instantané, et revue de code obligatoire via merge request.

Ces bénéfices se renforcent mutuellement. La traçabilité permet de répondre immédiatement à un client qui demande ce qui a changé entre deux versions, et de retrouver avec git bisect le commit responsable d'une régression. Les branches laissent plusieurs ingénieurs avancer en parallèle, le rollback ramène un firmware défaillant à sa version précédente en quelques secondes, et la merge request impose un second regard avant chaque intégration. Pour un projet soumis à IEC 62443-4-1 ou au CRA, cet historique sert aussi lors des audits.

Traçabilité complète

Chaque modification est enregistrée avec son auteur, sa date et son contexte. Quand un client demande « qu'est-ce qui a changé entre la version 1.3 et la version 1.4 ? », la réponse est immédiate via `git log v1.3..v1.4`. Quand un bug apparaît après une mise à jour, la commande git bisect permet de retrouver automatiquement le commit responsable parmi des centaines de modifications, en moins de 10 itérations pour 1000 commits grâce à la recherche dichotomique (log2(1000) ≈ 9,97). Cette traçabilité est un atout majeur lors des audits de certification (IEC 62443-4-1, ISO 27001) ou de due diligence technique.

Collaboration fluide

La collaboration Git permet à plusieurs développeurs de travailler en parallèle sur le même projet sans se marcher sur les pieds. Un ingénieur firmware développe un nouveau driver pendant qu'un autre optimise la consommation, chacun sur sa branche, sans interférence. Le merge intègre ensuite les deux contributions de manière contrôlée. Pour les projets impliquant du design électronique et du firmware, cette capacité à paralléliser le travail est déterminante.

Rollback sécurisé

Une mise à jour firmware a introduit un dysfonctionnement critique ? Avec Git, revenir à la version précédente prend quelques secondes. Pas besoin de chercher dans les archives, de demander à un collègue s'il a gardé une copie, ou de reconstruire le firmware à partir de souvenirs fragmentaires. Le rollback est instantané et fiable parce que chaque version du code est préservée intégralement dans l'historique Git.

Revue de code systématique

La revue de code est un mécanisme de « merge request » (sur GitLab) ou « pull request » (sur GitHub) qui permet de soumettre ses modifications à la revue de l'équipe avant intégration dans la branche principale. Un second regard sur le code avant la fusion réduit les bugs, partage la connaissance au sein de l'équipe, et améliore la qualité globale du projet. Selon une étude SmartBear, chaque heure de revue de code évite en moyenne 4 heures de débogage en aval. C'est une pratique que nous considérons comme indispensable sur tout projet critique soumis à IEC 62443-4-1 ou au CRA.

Cas d'usage dans les projets électronique et firmware

Un dépôt Git en bureau d'études électronique est un outil qui versionne quatre grandes catégories d'artefacts du projet : code firmware, scripts de test, documentation technique et fichiers de conception PCB.

Ces artefacts couvrent C, C++, Rust ou Python côté firmware, et KiCad ou Altium côté hardware. D'après la documentation NVIDIA JetPack et les guidelines Zephyr, le versioning complet incluant le BSP est aujourd'hui une pratique standard.

Chaque catégorie apporte un bénéfice propre. Le firmware est le cas d'usage le plus naturel, avec une branche par fonctionnalité et un tag par version livrée. Les scripts de test et de production évoluent avec le projet et bénéficient du même versioning que le code. La documentation versionnée reste synchronisée avec le firmware, et les schémas et fichiers PCB, même si leur comparaison visuelle est moins intuitive, profitent de l'historique et du rollback.

Firmware et logiciel embarqué

Le firmware embarqué est le cas d'usage le plus naturel de Git. Le code source du firmware, qu'il soit écrit en C, C++, Rust ou Python pour des cibles STM32, nRF52, ESP32 ou Jetson, est versionné dans Git. Les frameworks RTOS comme FreeRTOS, Zephyr et NuttX sont eux-mêmes maintenus sous Git (git.kernel.org pour Linux, GitHub pour Zephyr et FreeRTOS). Chaque fonctionnalité est développée sur une branche dédiée, testée, revue par un pair, puis intégrée dans la branche principale. Les releases sont marquées par des tags Git (v1.0.0 selon Semantic Versioning 2.0) qui permettent de retrouver instantanément le code exact qui correspond à chaque version livrée.

Scripts de test et de production

Les scripts de test fonctionnel, les procédures de programmation en production, les configurations de banc de test, tout cela évolue avec le projet et bénéficie du même versioning que le code firmware. Quand un processus de validation change, l'historique Git permet de retrouver l'ancienne procédure si nécessaire.

Documentation technique

Les spécifications, les notes d'application, les guides d'utilisation, ces documents évoluent avec le produit. Les versionner dans Git garantit que la documentation reste synchronisée avec le code. Un tag de release inclut non seulement le firmware mais aussi la documentation correspondante.

Fichiers de conception électronique

Les schémas et les fichiers de conception PCB (KiCad, Altium) peuvent aussi être versionnés dans Git. Bien que la comparaison visuelle des schémas soit moins intuitive que celle du code texte, l'historique et la capacité de rollback restent précieux. Des outils comme KiCad intègrent de plus en plus nativement le support Git.

Outils et plateformes recommandés

Un écosystème Git de production est composé de trois couches : un serveur remote (GitLab, GitHub, Bitbucket, Gitea), un client local, et une chaîne Continuous Integration / Continuous Delivery (CI/CD) branchée sur chaque push.

Le choix de chaque couche dépend du projet. Pour l'hébergement, nous privilégions GitLab sur les projets industriels, notamment parce que la Community Edition peut être hébergée en interne, tandis que GitHub convient mieux à l'open source et aux collaborations externes. Côté client, la ligne de commande reste la référence, mais les clients graphiques comme GitKraken, Sourcetree ou VS Code facilitent la prise en main pour les membres de l'équipe moins familiers de Git. Les bonnes pratiques listées plus bas s'appliquent quelle que soit la combinaison retenue.

Plateformes d'hébergement

• GitLab : notre recommandation pour les projets industriels. GitLab Community Edition peut être hébergé en interne (on-premise) pour les projets sensibles, intègre nativement la CI/CD (400 minutes gratuites par mois en SaaS), et offre une gestion fine des permissions. C'est l'outil que nous privilégions pour nos projets de DevOps embarqué
• GitHub : la plateforme la plus populaire au monde selon le State of the Octoverse 2024 (100 millions de développeurs), idéale pour les projets open source et la collaboration avec des partenaires externes. Son écosystème d'intégrations (GitHub Actions avec 2000 minutes gratuites, Copilot, Dependabot) est le plus riche du marché
• Bitbucket (Atlassian) : une alternative solide, bien intégrée avec Jira et Confluence si votre organisation les utilise déjà
• Gitea : fork léger de Gogs, écrit en Go, idéal pour un serveur Git auto-hébergé minimaliste (moins de 100 Mo de RAM en idle)

Clients graphiques

Pour les membres de l'équipe qui préfèrent une interface visuelle :

• GitKraken : interface moderne et intuitive, visualisation claire de l'arbre des branches, disponible sur Windows, macOS et Linux
• Sourcetree : client gratuit d'Atlassian, complet et bien documenté, disponible sur Windows et macOS
• VS Code : l'éditeur de code de Microsoft intègre un support Git natif. Pour les développeurs firmware qui utilisent déjà VS Code avec PlatformIO ou l'extension Zephyr, c'est la solution la plus naturelle

Bonnes pratiques pour démarrer

Voici les règles que nous appliquons systématiquement sur nos projets, alignées sur la spécification Conventional Commits 1.0.0 et sur le guide officiel Pro Git :

• Un commit = une modification logique. Pas de commits « fourre-tout » qui mélangent correction de bug, ajout de fonctionnalité et nettoyage de code
• Des messages de commit clairs. « Fix bug » ne dit rien. « fix(spi): correction du timeout DMA sur STM32H7 » permet de comprendre le changement sans ouvrir le code (format Conventional Commits : type(scope): description, 50 caractères max)
• Ne jamais commiter de secrets. Mots de passe, clés API, certificats, ces éléments n'ont pas leur place dans Git. Utilisez un fichier .gitignore pour les exclure automatiquement. Des outils comme git-secrets ou truffleHog scannent le dépôt à chaque push
• Brancher systématiquement. Même pour un « petit changement ». La branche main doit toujours rester dans un état fonctionnel
• Revue de code obligatoire. Aucun merge dans main sans qu'au moins une personne ait relu les modifications
• Authentification forte. Clé Secure Shell (SSH) ed25519 (définie dans RFC 8709) ou Personal Access Token (PAT) avec scope limité, 2FA activé côté plateforme

GitHub vs GitLab vs Bitbucket : lequel choisir ?

GitHub, GitLab et Bitbucket sont les trois plateformes d'hébergement Git les plus répandues en environnement professionnel, mais elles répondent à des besoins différents. Dans notre pratique sur des projets de DevOps embarqué, nous avons constaté que le choix dépend avant tout du niveau de sensibilité des sources et des contraintes réglementaires (CRA EU 2024/2847, IEC 62443-4-1, RGPD, souveraineté des données).

Le tableau ci-dessous compare les trois offres sur cinq critères : les dépôts privés en offre gratuite, les minutes de CI/CD incluses, l'auto-hébergement, la taille de dépôt recommandée et le cas d'usage typique. L'écart le plus structurant pour un projet industriel est l'auto-hébergement, que GitLab propose gratuitement avec sa Community Edition, alors que GitHub et Bitbucket le réservent à des offres payantes.

Notre recommandation : pour un projet firmware soumis au Cyber Resilience Act (CRA) ou à la norme IEC 62443-4-1, GitLab Community Edition auto-hébergé est souvent le meilleur compromis, contrôle total sur les sources, intégration CI native avec runners sur infrastructure interne, conformité RGPD garantie par l'absence de transfert hors UE. Selon la doctrine ANSSI, l'auto-hébergement des dépôts sensibles est recommandé pour les projets soumis au RGS. Pour un projet open source ou prototype rapide, GitHub reste imbattable par la richesse de son écosystème (GitHub Actions, Dependabot, CodeQL).

Merge vs rebase : quelle stratégie pour votre équipe ?

Un rebase consiste à rejouer une séquence de commits sur un nouveau point de base en réécrivant leur SHA-1, tandis qu'un merge préserve les deux histoires parallèles et crée un commit de fusion. Le débat merge vs rebase divise les équipes depuis plus de 10 ans. Les deux commandes intègrent les mêmes modifications : seule change l'histoire que l'équipe relira ensuite.

Trois stratégies coexistent en pratique : le merge, qui préserve l'historique littéral, le rebase, qui produit un historique linéaire, et le squash-merge, qui condense une branche de fonctionnalité en un seul commit. Le bon choix dépend de ce que l'équipe veut lire dans son historique, et de la facilité avec laquelle elle veut localiser une régression avec git bisect.

• Merge préserve l'historique littéral : chaque branche garde sa trace, les commits de merge forment un arbre bifurqué. Idéal pour les équipes qui veulent voir quand et pourquoi une fonctionnalité a été intégrée. Git Flow (Vincent Driessen, 2010) repose sur cette logique.
• Rebase réécrit l'historique de la branche de fonctionnalité par-dessus la dernière version de main. Résultat : un historique linéaire, beaucoup plus facile à lire avec git log --oneline. Recommandé par le modèle trunk-based development (Paul Hammant, 2013) adopté par Google, Facebook, et la plupart des équipes embarquées CRA-ready.
• Squash-merge combine les commits d'une branche de fonctionnalité en un seul commit lors de l'intégration, ce qui simplifie git bisect sur la branche principale.

Notre règle pratique : rebase avant d'ouvrir la merge request (pour un historique propre), merge dans main via squash-merge (pour un commit final atomique par fonctionnalité). Cette approche hybride donne le meilleur des deux mondes et facilite le git bisect en cas de régression, opération qui peut identifier un commit coupable parmi 1000 commits en moins de 10 étapes grâce à la recherche dichotomique.

Notre recommandation : GitLab Flow

GitLab Flow est un modèle de branches décrit dans la documentation GitLab : une branche main toujours intégrable, des branches de fonctionnalité courtes fusionnées par merge request, et des branches de release (release/v1.2) créées le plus tard possible pour chaque version livrée. C'est le modèle que nous recommandons pour un produit électronique.

La raison est propre au matériel : une fois les cartes livrées, plusieurs versions de firmware vivent en parallèle sur le terrain pendant des années. GitHub flow et trunk-based development supposent qu'un seul état, le dernier, est en production. Gitflow gère les versions, mais sa branche develop double le travail d'intégration sans bénéfice pour une petite équipe.

Nous appliquons GitLab Flow avec des merges uniquement. Pour corriger une version livrée, une branche de correctif part de la branche de release concernée, puis elle est fusionnée par merge request dans release/v1.2 (nouveau tag de patch v1.2.1) et dans main. Nous ne recommandons pas git cherry-pick pour ces reports : il copie le commit sous un autre SHA, Git ne sait plus que le correctif est déjà présent, et un oubli ou un conflit mal résolu suffit à faire réapparaître le bug dans la version suivante. Avec un merge, le même commit vit dans les deux branches et Git en garde la trace. Seuls les correctifs entrent dans une branche de release, jamais les nouvelles fonctionnalités. Ce suivi par version est aussi ce que demande le Cyber Resilience Act pour livrer des mises à jour de sécurité pendant toute la période de support.

Pour un service web ou cloud, GitLab Flow propose une variante à branches d'environnement (staging, production) : le code passe de l'une à l'autre par merge request, toujours dans le même sens.

Git comme socle qualité de vos projets techniques

Git est un socle qualité obligatoire pour tout projet électronique ou firmware qui vise une certification CE, Radio Equipment Directive (RED), ou conformité IEC 62443-4-1 et Cyber Resilience Act (CRA) EU 2024/2847. Sans versioning, pas de traçabilité ; sans traçabilité, pas d'audit possible ; sans audit, pas de certification. La chaîne est inviolable.

À retenir : démarrez avec des commits atomiques sous 200 lignes, des messages de commit descriptifs (sujet impératif, 50 caractères max pour la première ligne selon la convention git-scm.com), une branche par fonctionnalité, une revue de code obligatoire avant merge dans main, et une CI/CD qui bloque tout merge avec des tests cassés. Ces cinq règles transforment un projet fragile en projet industrialisable, et c'est ce socle que nous déployons systématiquement chez nos clients dès la phase de cadrage.

FAQ : Git pour les projets électroniques

Cette FAQ est composée de six questions qui reviennent le plus souvent chez nos clients lors de la mise en place du versioning.

Articles connexes

• DevOps pour l'embarqué : CI/CD, tests automatisés et déploiement firmware
• Logiciel embarqué industriel : guide complet
• Bureau d'études électronique : comment choisir le bon partenaire
• Tests et validation d'un produit électronique
• Gestion des risques dans un projet électronique