Dans le livre 97 Things every programmer should know, Diomidis Spinellis nous parle de l’importance du versionnage d’un projet.

Voici l’article de Diomidis Spinellis, en Français.

Mettez tout dans tous vos projets sous contrôle de version. Les ressources dont vous avez besoin sont là : des outils gratuits comme Subversion, Git, Mercurial et CVS; un espace disque abondant; serveurs bon marché et puissants; mise en réseau omniprésente; et même des services d’hébergement de projet. Après avoir installé le logiciel de contrôle de version, tout ce dont vous avez besoin pour mettre votre travail dans son référentiel est d’émettre la commande appropriée dans un répertoire propre contenant votre code. Et il n’y a que deux nouvelles opérations de base à apprendre: vous validez vos modifications de code dans le référentiel et vous mettez à jour votre version de travail du projet avec la version du référentiel.

Une fois que votre projet est sous contrôle de version, vous pouvez évidemment suivre son historique, voir qui a écrit quel code, et se référer à un fichier ou une version de projet à travers un identifiant unique. Plus important encore, vous pouvez faire des changements de code sans crainte – plus de code commenté au cas où vous en auriez besoin à l’avenir, car l’ancienne version vit en toute sécurité dans le référentiel. Vous pouvez (et devez) étiqueter une version logicielle avec un nom symbolique afin de pouvoir facilement réexaminer à l’avenir la version exacte du logiciel exécuté par votre client. Vous pouvez créer des branches de développement en parallèle: la plupart des projets ont une branche de développement active et une ou plusieurs branches de maintenance pour les versions publiées qui sont activement prises en charge.

Un système de contrôle de version minimise les frictions entre les développeurs. Lorsque les programmeurs travaillent sur des parties logicielles indépendantes, celles-ci sont intégrées presque par magie. Lorsqu’ils marchent les uns sur les autres, le système les remarque et leur permet de régler les conflits. Avec une configuration supplémentaire, le système peut informer tous les développeurs pour chaque changement engagé, en établissant une compréhension commune de la progression du projet.

Lorsque vous configurez votre projet, ne soyez pas avare : placez tous les actifs du projet sous contrôle de version. En plus du code source, incluez la documentation, les outils, les scripts de construction, les cas de test, les illustrations et même les bibliothèques. Avec le projet complet en toute sécurité rentré dans le référentiel (régulièrement sauvegardé), les dommages potentiels de perdre votre disque ou vos données sont minimisés. Mettre en place pour le développement sur une nouvelle machine consiste simplement à vérifier le projet à partir du référentiel. Cela simplifie la distribution, la construction et le test du code sur différentes plates-formes: sur chaque machine, une seule commande de mise à jour garantit que le logiciel est la version actuelle.

Une fois que vous avez vu la beauté d’un travail basé sur un système de contrôle de version, quelques règles vous rendront (vous et votre équipe) encore plus efficace :

• Valider chaque changement logique dans une opération distincte. Il est difficile de les démêler dans la fonction si vous modifiez plusieurs changements en une seule opération. Ceci est particulièrement important lorsque vous effectuez des refactorings à l’échelle du projet ou des changements de style, ce qui peut facilement masquer d’autres modifications.
• Accompagner chaque commit avec un message explicatif. Au minimum, décrivez succinctement ce que vous avez changé, mais si vous voulez également enregistrer la justification du changement, c’est le meilleur endroit pour le stocker.
• Enfin, évitez de créer du code qui brisera la construction d’un projet, sinon vous deviendrez impopulaire avec les autres développeurs du projet. La vie sous un système de contrôle de version est trop belle pour le gâcher avec des faux pas facilement évitables.

Qu’en pensez-vous ?