Pourquoi faut-il migrer de SVN vers GIT

J’ai eu plusieurs fois des clients qui me demande pourquoi on s’acharnait à mettre en place le versioning utilisant le protocole GIT. Et à former les équipes à ce protocole (ensemble de nouvelles commandes et manipulations). GIT apporte de nouvelles approches et pratiques qui peuvent être difficile à digérer au début, mais permet un gain de souplesse et de productivité par rapport à SVN.

Cet article sera l’occasion d’expliquer d’une manière simple et succinte pourquoi faut-il migrer vers GIT.

Voici un tableau comparatif des deux outils, basé sur les 4 critères que je juge les plus importants  :

Critère SVN GIT
Système distribué Non Oui
Gestion des branches Pauvre Plus riche et souple
Révision globale Oui Non
Intégrité des données Faible Robuste

Système distribué

GIT et SVN reposent tous les deux sur un serveur centralisé.

Mais GIT est plus destiné à être utilisé en mode distribué, ce qui signifie que chaque développeur peut récupérer une copie de tout le dépôt cloné et installé sur sa machine. Même en l’absence de connexion internet, il sera toujours en mesure de faire des commits, consulter l’historique de révisions, créer des branches en local. Et d’envoyer au serveur ces modifications au moment voulu.

Gestion des branches

Les branches dans SVN ne sont rien d’autre qu’un autre dossier dans le repository. Si vous voulez vérifier si vous avez fusionné une branche, vous devez explicitement exécuter des commandes comme svn propget svn: mergeinfo pour vérifier si elle a été fusionnée ou non. Ainsi, le risque d’ajouter des branches orphelines est assez élevé.

Alors que travailler avec les branches GIT est beaucoup plus facile et souple. Vous pouvez basculer rapidement entre les branches du même répertoire de travail. Il aide à trouver des branches non fusionnées et aide également à fusionner des fichiers assez facilement et rapidement.

L’une des bonnes pratiques est de créer une nouvelle branche à chaque nouvelle fonctionnalité, de la tester en local par le développeur, d’y apporter les corrections nécessaires, et enfin la merger avec le tronc de développement (la branche principal de développement) quand ça lui semble convenable.

Révision globale

C’est l’une des plus grandes fonctionnalités qui existe sur SVN et manque sur GIT. En effet le numéro de révision sur SVN est une capture instantanée du code source à un moment donné.

GIT et SVN sont conceptuellement différents. Sur GIT on peut utiliser la clé de hachage SHA-1 qui identifie un commit,  pour identifier de façon unique le cliché de code, mais sur une branche donnée.

Intégrité des données

Les contenus GIT sont cryptographiquement hachés en utilisant l’algorithme de hachage SHA-1. Cela garantit la robustesse du contenu du code en le rendant moins sujet à la corruption du repository en raison d’échecs de stockage disque, de problèmes de réseau, etc. Voici une discussion intéressante sur l’intégrité du contenu de GIT: http://stackoverflow.com/questions/31400800/git-svn-clone-file-integrity

Conclusion

Les avantages qu’apporte GIT valent vraiment la peine de consacrer du temps et des ressources pour la migration et la mise en place d’une politique de versioning, de gestion des branches, de standardisation du poste de travail de développeur  et même par la suite d’intégration continue basée sur GIT.

Ils existent deux solutions d’hébergement de dépôts GIT sur le cloud : GitHub et Bitbucket. Le premier est très célèbre, surtout auprès des équipes de développement Open Source (hébergement gratuit de projets publics), et payant pour les projets privés (à partir de 7$ par utilisateur par moi). Le deuxième a une cible plus corporate, il est parfaitement intégré avec d’autres solutions connues de la société Attlassian (Jira, Confluence) et a surtout l’avantage d’être gratuit pour les projets privés avec des équipes de moins de 5 personnes.

Voilà, vous pouvez donc commencer à y créer un projet pour tester, voici un petit guide simple des commandes les plus utiles de GIT