Lorsque j’étais en Picardie la semaine dernière, en discutant avec Joris, nous en venons à parler de nos plateformes de développement personnelles.
Du coup forcément je lui explique l’architecture contraignante que je m’impose (développement local -> commit svn -> test sur serveur de préproduction -> push en production).
Et la il me dit « je n’ai jamais compris l’utilité de SVN ». Honte sur lui que je dis. Et je m’engage à lui expliquer cela.
Comme après on est arrivés au bar, je n’ai pas eu le temps de le faire. Mais c’est tous bénéfices pour vous puisque je le fais donc maintenant 
Commençons par un peu d’histoire. Il y a trois générations de grands systèmes de gestion de version.
Il en existe d’autres évidemment. Mais je les épargne. Ce billet n’est pas là pour faire une liste de tous les systèmes de gestion de versions.
Alors comment ça fonctionne ? C’est au final assez simple.
Lorsque vous développez votre application seul et toujours sur la même machine, il est assez aisé de s’y retrouver. Vous avez toujours les dernières modifications de disponibles en local.
Le jour ou vous commencez à développer à deux ou à passer d’une machine à l’autre par contre, c’est plus embêtant.
Si vous êtes toujours seul, il vous suffirait d’une clé usb pour avoir toujours tous vos documents. Quand vous êtes à deux en revanche, cela n’est pas faisable.
Et c’est la qu’intervient le contrôle de versions.
Supposons trois fichiers : A, B, C
Vous modifiez le contenu du fichier A. Pendant ce temps un second développeur modifie le contenu du fichier B.
Ici on a que trois documents. Du coup il n’est pas difficile de s’y retrouver et de merger les modifications. Mais sur des gros projets ?
En faisant un commit sur votre contrôleur de versions, vous ne mettrez donc que le fichier A à jour. Le second développeur ne perdra pas ses modifications.
Et lorsqu’il mettra à jour sa version locale avec la version distante, il récupèrera le contenu du fichier A tel que vous l’avez modifié.
Poussons maintenant le vice plus loin
Le document A est particulièrement long et vous modifiez le début de celui-ci, les lignes 50 et 75 par exemple.
Le second développeur modifie les lignes 60 et 160.
Eh bien vos modifications pourront toujours être prises en compte par le contrôleur de versions, qui verra les lignes que vous avez ajouté dans le document et celles que vous avez modifié et sera capable de ne modifier que cela
On ira pas plus loin que cela. Il ne faut pas bousser le bouchon trop loin et il n’est pas capable de merger des modifications sur la même ligne.
En revanche, vous pouvez lui demander un café et voir ce qu’il répondra.
Ensuite, ous constaterez rapidement, en faisant quelques commits sur le contrôleur de version que vous pouvez placer un commentaire sur chacune d’elle.
Ainsi vous avez un historique de toutes les modifications apportées à chacun des fichiers de votre projet (et par qui).
C’est notamment fortement pratique dans un projet libre. Vous pouvez par exemple suivre toutes les modifications apportées à votre projet préféré.
Voici un exemple. Il s’agit du dernier commit fait sur Ruby on Rails, durant la nuit (heure française).
Pour finir, quel contrôleur de version choisir ?
J’en utilise pour ma part, deux. SVN, sur ma machine de développement pour tous mes projets privés.
Et GIT sur github.com pour mes projets publics.
Entre les deux, je préfère git. Principalement car celui-ci implémente le contrôle de version complet en local. Vous pouvez donc faire votre commit en local puis le « pusher » et il sera en ligne. Ainsi, lors d’un voyage en train, je développe en découpant en commits lisibles et fait un push en arrivant. C’est comme si j’avais eu un accès internet durant mon voyage
Alors que les commits SVN font directement la mise à jour sur le serveur. C’est un peu moins propre.
Mais je fais face à quelques problèmes pour installer un serveur git sur ma machine. Pour l’instant, je dois donc encore me contenter d’un svn. Mais cela ne saurait tarder à changer.
).
