Git & Versioning
Définition
Git est un système de gestion de versions distribué permettant de suivre les modifications apportées à un ensemble de fichiers au cours du temps. Créé en 2005 par Linus Torvalds pour les besoins du développement du noyau Linux, il s'est imposé comme le standard de fait dans le développement logiciel et l'ingénierie informatique. Contrairement aux systèmes de gestion de versions centralisés, Git repose sur un modèle distribué : chaque utilisateur dispose d'une copie complète du dépôt, ce qui offre une grande flexibilité, une meilleure résilience face aux pannes, et permet de travailler de manière indépendante avant de synchroniser les modifications.
Dans la pratique, Git ne s'utilise presque jamais seul : il est complété par des plateformes d'hébergement qui ajoutent une couche de collaboration, de gestion d'incidents, de revue de code et d'automatisation. Les principales sont GitHub (très utilisée pour l'open source mondial), GitLab (plus orientée DevOps, disponible en auto-hébergement), et plus marginalement Bitbucket et Gitea.
L'actualité récente de l'écosystème Git renforce l'importance d'en maîtriser les fondamentaux. La généralisation des chaînes CI/CD et de l'Infrastructure as Code a fait du dépôt Git le point d'entrée de quasiment toutes les opérations modernes : un push déclenche désormais souvent un build, des tests, un scan de sécurité, voire un déploiement en production. La compromission de chaînes d'approvisionnement logicielles via des dépôts Git (cas SolarWinds, attaques sur PyPI, npm) rappelle aussi que la sécurité de la chaîne de versionning est devenue un sujet stratégique en soi.
Plateformes pratiquées
La compétence en pratique
Maintenir un projet open source sur GitHub
Mon repository public Docker-IDS-Sensor est mon utilisation la plus structurée de Git aujourd'hui. Démarré en octobre 2025, il a accumulé une dizaine de commits significatifs en 2 semaines jusqu'à la publication de la v1. Tous les commits sont aujourd'hui sur la branche main, car je suis seul contributeur et que travailler en branches feature sur un projet solo aurait été plus de cérémonie que de valeur ajoutée.
Avec le recul, cette approche commit-direct-sur-main n'est pas une bonne pratique transférable dès qu'un projet grandit ou s'ouvre à des contributeurs. La discipline professionnelle attendue serait d'isoler chaque composant dans une branche feature (par exemple feature/arkime-integration, feature/opencanary, fix/dockerfile-suricata), puis de fusionner via une pull request une fois la fonctionnalité validée. Cette structuration apporte trois bénéfices que je ne capte pas aujourd'hui : la possibilité de tester une feature en isolation sans casser la branche principale, un historique lisible où chaque merge raconte une étape du projet, et un point de revue de code formel via la pull request. Je compte adopter ce workflow dès que je commencerai à travailler à plusieurs sur des projets open source ou que la sonde IDS gagnera en complexité.
Auto-héberger GitLab pour mes projets non publics
Je maintiens un GitLab auto-hébergé sur mon homelab Proxmox, dans une VM Debian dédiée. Il accueille mes projets en cours qui ne sont pas encore mûrs pour être publiés (outils de cybersécurité expérimentaux, scripts de durcissement système, prototypes de détection), ainsi que des projets purement personnels (notes versionnées, configurations sensibles).
Au-delà du stockage, j'utilise cette instance pour apprendre les concepts Git plus avancés que je ne pratique pas dans mon contexte professionnel. C'est notamment là que je teste les chaînes CI/CD GitLab sur des projets jouets : un pipeline qui lance un linter Bash sur mes scripts à chaque push, un autre qui build des images Docker de test pour vérifier que mes Dockerfiles compilent, et un troisième qui exécute des analyses de sécurité statique sur le code Python que j'écris pour des CTF. J'expérimente aussi avec Dependabot pour le suivi automatique des vulnérabilités sur les dépendances de mes projets.
Cinq ans d'autodidaxie suivis d'un cours formel : un apprentissage bancal mais honnête
Mon parcours sur Git est révélateur de comment j'ai construit mes compétences en général. J'ai commencé à utiliser Git en 2020, principalement pour mes projets personnels, sans aucune formation préalable et sans être développeur de formation. Je l'ai utilisé "comme je pensais qu'il fallait l'utiliser", en pratiquant les commandes de base au quotidien mais sans maîtriser la logique sous-jacente (objet commit, structure DAG, références, index vs working tree).
Je n'ai eu mon premier cours formel sur Git qu'en 2025, dans le cadre de mon Mastère à l'ESIEA, soit cinq ans après avoir commencé à l'utiliser. Ce cours a été à la fois éclairant et frustrant : éclairant car il m'a fait comprendre pourquoi certaines commandes que j'utilisais fonctionnaient (et pourquoi d'autres que j'aurais pu utiliser auraient été plus appropriées), frustrant car il m'a fait réaliser que j'avais probablement appris quelques mauvaises habitudes pendant ces cinq années que je devrai désapprendre. Je pense d'ailleurs continuer à faire des erreurs de débutant régulièrement, malgré l'expérience accumulée.
Première vraie expérience de Git en équipe sur des projets pédagogiques
Le contexte le plus formateur sur l'aspect collaboratif de Git a été mes projets de groupe à l'ESIEA, menés à 3 ou 4 étudiants sur plusieurs mois. Sur ces projets, j'ai dû passer d'une utilisation strictement individuelle à un workflow partagé : création de branches feature par contributeur, ouverture de pull requests pour intégrer les évolutions à la branche principale, et résolution des inévitables conflits de fusion qui surviennent dès que deux personnes touchent au même fichier de configuration.
Cette expérience a confirmé qu'écrire du code à plusieurs n'est pas une extension naturelle du code seul : c'est un changement de discipline. Il faut apprendre à écrire des messages de commit qui parlent aux autres, à découper son travail en commits atomiques plutôt qu'en gros lots, à réviser le code de ses coéquipiers sans juger leur style, et à accepter que ses propres choix soient discutés. C'est aussi en projet à plusieurs que les erreurs Git deviennent douloureuses : un force-push mal placé peut effacer le travail d'un coéquipier, un mauvais merge peut perdre des heures de progression collective.
Première contribution en pull request sur un projet existant
En dehors des projets de groupe scolaires, j'ai eu l'occasion de contribuer à un projet privé d'un proche via le workflow complet : fork mental du projet, branche feature dédiée, modifications ciblées, commit propre avec message explicite, et pull request avec description du changement et de sa justification. Le projet n'étant pas public, je ne peux pas le partager ouvertement, mais l'exercice était identique à celui d'une contribution open source classique.
La pull request a été discutée avec le mainteneur avant intégration, ce qui m'a familiarisé avec la mécanique de code review collaborative : explication des choix, ajustement après remarques, parfois reformulation complète d'un commit. C'est un exercice très différent du commit-direct-sur-main, et qui m'a donné une première vraie expérience du workflow que pratiquent les grands projets open source.
Mon niveau de maîtrise
Mes niveaux varient fortement selon le volet de Git considéré. Je suis très à l'aise sur les fondamentaux et l'usage quotidien d'un repo solo, mais je suis honnêtement perfectible sur les workflows collaboratifs avancés et les commandes de réécriture d'historique. Cette différence reflète mon parcours autodidacte sur la durée : j'ai utilisé intensivement ce que j'avais besoin d'utiliser, sans creuser ce dont je n'avais pas eu l'occasion d'avoir besoin.
Contextualisation : ma compétence est solide dans son contexte habituel (projets solo, contributions occasionnelles, administration d'une instance GitLab personnelle), et reste insuffisante dans un contexte d'équipe structurée où GitFlow, rebases interactifs, et code review formels sont des prérequis quotidiens. Je sais que ce gap existe, et je sais où aller le combler.
Place dans mon profil et vitesse d'acquisition
Git occupe une place de compétence transverse indispensable dans mon profil, mais pas de compétence centrale au sens où elle ne définit pas mon métier. C'est un outil dont je ne pourrais pas me passer pour aucune de mes autres compétences (configuration système, scripting, sécurité, infrastructure), mais ce n'est pas l'outil sur lequel ma valeur ajoutée professionnelle se construit.
Vitesse d'acquisition : contrairement à d'autres compétences que j'ai acquises rapidement, Git a été pour moi une compétence à acquisition lente. J'ai utilisé l'outil pendant cinq ans avant de comprendre sa logique profonde, ce qui est probablement le pire ratio "temps passé / niveau atteint" de tout mon parcours. Le passage par un cours formel m'a confirmé qu'il existe des outils qu'on n'apprend pas correctement seul : Git en fait partie, parce que sa puissance se révèle seulement quand on en comprend les concepts internes, pas quand on en mémorise les commandes superficiellement.
Mon recul sur la compétence
Avec l'expérience que j'ai aujourd'hui, je conseille avant tout de commiter souvent, avec des messages clairs. C'est un conseil basique mais c'est probablement celui qui a le plus d'impact sur la durée. Un historique propre, fait de petits commits atomiques bien décrits, vaut infiniment mieux qu'un historique de gros commits cryptiques avec des messages du type "fix" ou "update". Ce n'est ni technique ni avancé, c'est juste de la discipline quotidienne, et c'est ce qui distingue les projets dans lesquels on peut intervenir des projets qu'on doit réécrire.
Je conseille ensuite de ne pas attendre cinq ans avant de chercher à comprendre les concepts internes. Si je devais refaire mon apprentissage, je passerais quelques jours dès le départ à lire la documentation officielle ou un livre de référence, pour intégrer la logique d'objets commit, de références et de DAG. Cela m'aurait évité plusieurs années de manipulation à l'aveugle, où je faisais marcher les choses sans vraiment savoir pourquoi elles marchaient.
Le dernier conseil, et c'est probablement le plus important sur la durée, est de collaborer dès que possible. Git seul, c'est commit / push / pull. Git à plusieurs, c'est branches, pull requests, conflits, code review, discussions, ajustements. C'est dans la collaboration que la compétence Git devient vraiment riche, et que les fameuses "commandes avancées" trouvent leur sens : on ne fait pas un rebase interactif pour le plaisir, on le fait pour rendre un historique d'équipe lisible.
Évolution et formations
Mon objectif sur cette compétence est clair : passer du Git solo bien fait au Git collaboratif solide. Cela signifie travailler les workflows que je n'utilise pas encore (GitFlow, trunk-based development, conventional commits), les commandes avancées de réécriture d'historique (rebase --interactive, cherry-pick, reflog pour récupérer une situation accidentelle), et la pratique du code review sur des projets que je ne maintiens pas seul.
Sur le plan des lectures, ma priorité immédiate est de lire intégralement le Pro Git book de Scott Chacon et Ben Straub, disponible gratuitement en ligne sur git-scm.com. C'est la référence officielle, dense mais accessible, et c'est exactement le type d'ouvrage que j'aurais dû lire en 2020 plutôt qu'en 2025. Je conseillerais d'ailleurs ce livre à toute personne qui veut bâtir une vraie maîtrise de Git plutôt que de patcher ses lacunes par des recherches Stack Overflow.
Sur le plan des contributions concrètes, je veux franchir le cap de la première vraie contribution à un projet open source d'envergure. Plusieurs pistes me semblent atteignables à moyen terme : contribuer à un outil de sécurité que j'utilise quotidiennement (un module Suricata, une règle Wazuh, une amélioration d'Arkime), ou contribuer à un paquet Debian que je connais bien. L'objectif est de passer de la consommation pure de l'open source à la contribution réelle, ce qui est cohérent avec mon objectif personnel de devenir contributeur reconnu de l'écosystème libre.
Sur le plan des chaînes CI/CD, je veux approfondir GitLab CI au-delà de mes expérimentations actuelles, en couvrant des pipelines plus complexes avec stages multiples, artefacts, environnements de déploiement et secrets correctement gérés. Cela complète directement ma compétence en conteneurisation et en virtualisation, en construisant le pont entre code et déploiement.
Concernant ma veille, elle suit la même structure que pour mes autres compétences : flux RSS, échanges sur Keybase avec ma communauté technique, et Twitter sur les comptes pertinents (mainteneurs de Git, équipes GitHub et GitLab, contributeurs open source actifs).
Réalisations rattachées
Cette compétence est mobilisée dans deux réalisations principales. La Sonde IDS conteneurisée matérialise ma pratique de Git en projet open source : repository public, commits réguliers, README structuré. Le Portfolio auto-hébergé illustre l'intégration de Git dans un pipeline de déploiement personnel, avec un script deploy.sh qui prend en charge la mise à jour de la version active à partir d'un export versionné.