Au fil de mes rencontres sur Internet, j’ai découvert une façon de gérer les version d’un logiciel différente de CVS ou SVN : GIT, un outil de gestion de version décentralisée.

Introduction

Venant du monde CVS/SVN où la base d’historique (repository) est centrale à tous les développeurs, un outil comme GIT a de quoi surprendre. En effet, ici point de base centrale, chaque développeur ayant sa propre copie de tout l’historique. En ce qui concerne la coopération, ces outils misent sur l’échange de patches : lorsque deux développeurs doivent coopérer, soit l’auteur d’un patch diffuse son patch sous forme d’un fichier (par mail par exemple), soit le développeur souhaitant récupérer des modifications peut aller les tirer (pull) chez l’auteur. Mais ces outils sont en général très flexibles et il est possible de revenir à un monde centralisé, moyennant quelques commandes supplémentaires.

Pourquoi GIT

Les logiciels de gestion de versions décentralisée sont nombreux. Mon choix s’est porté sur GIT car, bienque complexe (ouille ouille ouille, toutes ces commandes), il est très flexible. De plus, étant le logiciel utilisé par la communauté des développeurs Linux, il bénéficie d’un bon support et semble être un choix durable. Enfin, c’est l’outil qui paraît être le plus avancé en terme de communication avec d’autres outils de gestion de version (au moins CVS et SVN dans mon cas).

Pour quoi faire ?

“Oui, soit, mais pourquoi utiliser ce nouvel outil ?” me direz vous. La question est d’autant plus jutifiée qu’il ne fait pas suite à une quelconque participation à un projet utilisant GIT. En fait, c’est avant tout pour le fun et l’envie de découvrir un autre outil, un autre mode de pensée. Puis, après quelques jours de manipulation, je me suis rendu compte que c’est outil est vraiment très puissant.

Le premier cas d’utilisation dans lequel GIT prend tout son sens est celui où, en tant que développeur, vous n’avez pas d’accès en écriture sur le repository officiel du projet. Ici, GIT (couplé à StGit par exemple) vous permet de développer de nombreuses adaptations tout en attendant que vos propositions de patches soient acceptées dans le dépot officiel.

Mais, même lorsque vous disposez d’un accès en écriture sur le dépot officiel, GIT peut être très pratique. Dans ce cas de figure, GIT (couplé à cogito par exemple) vous permet d’expérimenter ou de développer plusieurs idées en même temps, sans polluer le dépot officiel.

Conclusion

Voila pour ce petit tour. J’espère vous avoir donné envie de creuser le sujet.