Il existe plusieurs systèmes de gestion de versions. Le plus connu/utilisé à l’heure actuelle est Git, notamment pour sa (très) grande flexibilité et sa rapidité d’exécution. L’adoption massive de Git a d’ailleurs rendu la coopération beaucoup facile sur de nombreux projets : avant Git (et Github, qui a popularisé Git), chaque projet utilisait un système de contrôle de version différent. A présent, savoir contribuer à un projet permet de contribuer à tous les projets cite:[roads_and_bridges(89)].
Il est une aide précieuse pour développer rapidement des preuves de concept, switcher vers une nouvelle fonctionnalité, un bogue à réparer ou une nouvelle release à proposer au téléchargement. Ses deux plus gros défauts concernent sa courbe d’apprentissage pour les nouveaux venus et la complexité des actions qu’il permet de réaliser.
Git Isn’t Just for Developers. It Might Be the Best Writing Tool Ever/
Unit of work
Même pour un développeur solitaire, un système de gestion de versions (quel qu’il soit) reste indispensable, car il permet d’isoler un ensemble de modifications dans une unité de travail, jusqu’à ce que celles-ci forment un tout cohérent :
- Chaque “branche” correspond à une tâche à réaliser: un bogue à corriger (Hotfix A), une nouvelle fonctionnalité à ajouter ou un “truc à essayer” (Feature A et Feature B).
- Chaque “commit” correspond à une sauvegarde atomique d’un état ou d’un ensemble de modifications cohérentes entre elles. Il convient donc de s’abstenir de modifier le CSS d’une application et la couche d’accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up. De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.
L’historique d’un module est ainsi disponible, sauvé et traçable: qui a réalisé quelle modification à quel moment. Ceci permet notamment de dessiner l’évolution du code et de mettre un surbrillance que certains modules distincts évoluent un peu trop main dans la main (et devraient donc être refactoriser, selon les principes de développement énumérés plus tôt).
Cas pratique: vous développez une nouvelle fonctionnalité qui va révolutionner le monde de demain et d’après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
Il suffit alors de:
- Sauver le travail en cours (
git add . && git commit -m [WIP]) - Revenir sur la branche principale (
git checkout main) - Créer un “hotfix” (
git checkout -b hotfix/pci-compliance) - Solutionner le problème (sans doute un
;en trop ?) - Sauver le correctif sur cette branche (
git add . && git commit -m "Did it!") - Récupérer ce correctif sur la branche principal (
git checkout main && git merge hotfix/pci-compliance) - Et revenir tranquillou sur votre branche de développement pour fignoler ce générateur de noms de dinosaures rigolos que l’univers vous réclame à cor et à a cri (
git checkout features/dinolol)
Il existe plusieurs méthodes pour gérer ces flux d’informations. Les plus connues sont https://www.gitflow.com/[Gitflow] et https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/[Threeflow].
La gestion de versions de fichiers permet de conserver un historique de toutes les modifications enregistrées, associées à un horodatage et une description.
Décrire ses changements
La description d’un changement se fait via la commande git commit.
Il est possible de lui passer directement le message associé à ce changement grâce à l’attribut -m, mais c’est une pratique relativement déconseillée : un commit ne doit effectivement pas obligatoirement être décrit sur une seule ligne. Une description plus complète, accompagnée des éventuels tickets ou références de tâches, sera plus complète, plus
agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.
De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique. Par exemple:
La première ligne est reprise comme étant le titre (normalement, sur 50 caractères maximum); le reste est repris comme une description (optionnelle).
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Il est possible de suivre les recommandations de Conventional Commits, qui ont pour objectifs de :
- Générer automatiquement un CHANGELOG
- Déterminer automatiquement des sauts de versions (en se basant sur les types de commits)
- Communiquer la nature des changements appliqués au code
- Déclencher (automatiquement, toujours) des processus de construction ou de publication
- Rendre l’accès au code plus lisible, en facilitant l’exploration du code au travers de commits mieux structurés.
En bref, cela permet d’éviter ceci :
Ignorer des fichiers ou patterns
Par défaut, Git prendra l’ensemble des fichiers présents dans votre espace.
Afin d’éviter certaines erreurs, il est important de configurer correctement Git pour qu’il ignore systématiquement certains fichiers ou chemins.
Pour cela, la solution consiste à créer un fichier .gitignore que vous placerez à la racine de votre dépôt.
Si vous ne savez pas quoi y mettre, inspirez-vous du dépôt github/gitignore - qui contient un fichier brut contenant les principales règles pour la majorité des langages.