Il y a quelques mois je découvrai Git, un gestionnaire de sources distribué dont la réputation croît en ce moment. Ayant déjà vécu la montée en puissance de Subversion au détriment de CVS, je voulais me rendre compte des qualités/défauts du nouveau challenger.
Une nouvelle philosophie
Git fait partie de la famille des contrôleurs de sources distribués. Cela se traduit principalement par le fait que chaque membre d'une équipe collaborant à un même projet est en possession d'un dépôt contenant l'ensemble de l'historique du projet. Les publications se font ainsi en local, ne nécessitant alors aucune connectivité réseau. Seul les échanges entre dépôts se font via le réseau.
Une première question vient alors à l'esprit : Si tout le monde est un dépôt, d'où provient la version de l'application à livrer ? Plusieurs organisation sont possibles à ce sujet:
- Une organisation par cercle de confiance, comme par exemple pour le développement du noyau Linux, où un membre de l'équipe représente le dépôt de référence que tout le monde utilise pour compiler sa version du noyau, alimenté par les dépôts de plusieurs lieutenant possédant chacun un dépôt alimenté par des dépôts considérés par ses derniers comme étant de confiance.
- L'outil est suffisament souple pour reproduire les mécanismes des dépôts centralisés. Un dépôt sur un serveur sert de référence, utilisé par exemple par un automate de compilation permettant d'assurer une intégration continue des sources du projet, les développeurs de l'équipe déposent alors des lots de publication sur ce dépôts lors de chaque instruction git push
- et bien d'autres ...
Une autre question suvient : Comment se joindre à un projet ? Il suffit tout simplement de
cloner un dépôt avec la commande
git clone /jango/fet.git et vous voilà avec un clone tout neuf, puis de commencer les développement. C'est un peu comme si chaque développeur avait
forker le projet afin de produire une version. L'ensemble des développements publiés dans un dépôt représente alors un patch à appliquer aux autres dépôts pour contribuer au développement.
Une migration en douceur
Lors de la migration de CVS vers Svn, un utilitaire fournit (cvs2svn) permettait de migrer un dépôt CVS en dépôt Subversion tout en conservant l'historique. Une action
one shot qui implique de synchroniser l'ensemble des membres de l'équipe utilisant le dit dépôt vers le nouvel outil.
Permier avantage de Git sur Svn : git-svn. Cet utilitaire fait la même chose que le précédent, c'est-à-dire de constituer un dépôt Git à partir d'un dépôt Subverion tout en conservant l'historique via la commande
git svn clone. Mais il va plus loin en conservant une connectivité avec le dépôt Subversion lui servant d'origine. Ainsi le dépôt git et maintenu à jour en continu avec la commande
git svn rebase.
Cela va encore plus loin en permettant de publier les commit effectués dans le dépôt Git vers le dépôt Subverion via la commande
git svn dcommit. De cette manière, un développeur peut se mettre à utiliser Git tout en continuant de collaborer à un projet dont le référentiel de source est Subversion (ce que je fit pendant plusieurs mois).
Un bénéfice au quotidien
«Git est un nouvel outil!
- d'accord
-Il est plus
fashion!
- OK, mais encors?»
«Wiiiilsooooon !!!!»
On peut aussi tout simplement utilser Git en mode
seul au monde pour historiser tout ce qui se trouve sur un ordinateur. La création d'un dépôt se fait avec la commande
git init, puis ont ajoute les fichiers à historiser via la commande
git add monprecieux.fic puis on plublie les modification via la commande
git commit. Pas besoin d'un serveur où d'un dépôt à créer et/ou administrer. C'est simple et efficace et l'on peut s'en servir pour maintenir l'historique des fichiers de configuration sur un serveur (<troll>bein oui un serveur Linux/UNIX, comment on ferait pour historiser les clics droits sous Windows®</troll>) et tout projet
sandbox commencé mais jamais terminé. Je m'en sert également pour réaliser des kit de démarrage afin de savoir toutes les étapes que j'ai franchies et ainsi produire une documentation exhaustives.
«Release Early, Release Often»
Ce principe de livraison fréquente peut être appliquer au niveau du développeur qui va pouvoir publier fréquement ces modifications induisant ainsi une meilleur qualité de ces publications (fini le fichiers qui manquent, les modifications oubliées dans un coin ne sachant pas si elles concernaient la tâhes en cours, ...). Chaque modification faisant progresser le code d'un état stable à un autre (bien qu'intermédiaire)
doit faire peut faire l'objet d'un commit ce qui n'est pas envisageable sur un projet centralisé.
Un build incassable
Cette capacité à pouvoir publier sans retenue permet la mise en oeuvre du
build incassable. Dans la mesure où seul le dépôt local est touché par ces modifications une sécurité m'est offerte en clonant mon propre dépôt dans un endroit de mon ordinateur et en construisant mon projet à partir de ce clone afin de constater la fiabilité des mes développements avant le partage de mes travaux.
«cou roucoucou roucoucou stach stach»
Il y a des moments où le travail suit son cours, le soleil est radieux, la journée a bien commencé, quand tout à coup le ciel s'obscurci, un bug en prod doit être fixé de toute urgence sinon c'est la fin du monde. Avec SVN il me fallait alors créer une nouvelle copie de travail (ce qui peut être long sur de très gros projet) puis la supprimer une fois l'urgence traitée. Où alors de créer un patch, annuler toutes mes modifications en cours puis appliquer le patch après la tempête.
La commande
git stash permet ainsi de mettre de côté (to stash = planquer) les modifications en cours pour repartir d'une version clean de la copie de travail puis de reprendre les travaux au moyen de la commande
git stash pop, tout ceci avec une efficacité sans précédent pour moi.
Conclusion
En conclusion, je n'ai pas listé beaucoup de défauts (aucun pour être précis) mais je noterai tout de même l'effort à produire pour changer d'habitude et notamment le changement de philosophie induit par la distribution des dépôts.
Je m'y met de plus en plus serieusement ce qui implque d'autres publications à l'avenir sur cet outil qui fait maintenant parti de mes meilleurs amis en tant que développeur.
