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.
SVN c’est « moins propre » que GIT mais un peu plus rapide et plus simple à comprendre je trouve. Et comme y’a plus de monde qui l’utilise, c’est tout de suite plus intéressant
C’est marrant ce matin dans le train j’ai fait un billet similaire mais je l’ai pas encore posté, je tape un peu trop sur la boite dans laquelle je suis en stage dedans
Héhé, bon article, et simple à comprendre. Je ne suis pas fan de l’argument « vous pourrez revenir en arrière en plus » que tu ne développes pas, et 100% d’accord avec toi sur le reste.
Par contre j’ai deux questions qui me taraudent : mon premier projet versionné est le passage d’un weblog de rails 1.2+mysql à 2.1.2+sqlite, il y a un peu de boulot. J’ai l’impression : 1/ de commiter trop fréquemment, rendant l’historique illisible, 2/ que mes commits ne sont pas cohérents (je fixe les choses au fur et à mesure sans me concentrer d’abord sur l’aspect bdd, après sur tel plugin, etc). As-tu des pistes pour faciliter ce genre de choix ? Quand commiter, et comment unifier un peu les modifs en gardant un trunk/tree-master où le serveur boote ?
Les commits trop fréquents, c’est tout l’avantage de Git justement. Ceux-ci sont groupés par push (sous github du moins). Du coup on est pas envahi par le nombre de ceux-ci
Après, non, je n’ai pas de truc pour conserver un trunk/tree-master ou le serveur boot tout le temps. Mais j’y travaille
Encore une fois, l’avantage de git est que comme tu ne push tes commits que quand tu le désire, tu le fait une fois en fin de session de développement.
Du coup tu t’arrange pour que ton serveur boot lorsque tu push et le problème est reglé
Très bon article qui vient de me convaincre de m’y mettre. Je n’ai jamais utilisé de système comme ça, mais je pense que ça peut être bien utile, en espérant toute fois qu’il soit dispo à mon taff (même si je pense rêver un peu).
Je vais donc tester GitHub, parce que la solution du « push quand je veux », me convient mieux, que le « push à chaque connexion », sachant que je fais pas tant de connexion que ça… Ca permettra, comme tu le précises, de faire des maj en fin de session de dev
En tous cas, merci pour l’article, je vais tester ça dans la foulée
Hum, tu m’as bien mis dedans quand même là^^
Je monte mon blog et je m’y mets. Merci pour l’article Damz.