Je profite de la sortie imminente de la version 2.0 de git pour rendre hommage à cet outil qui n’a plus rien à prouver tant il est devenu populaire chez les développeurs. C’est à mon sens une des plus grandes réussites de l’open source.
Git est un outil formidable. Par rapport aux outils de la génération précédente, il est franchement plus rapide. Faire un commit ou une branche est instantané. La notion de branche est un des piliers de sa conception, ce n’est pas une fonctionnalité qui y a été intégrée tant bien que mal comme c’était le cas dans Subversion. Son aspect distribué permet de travailler chez soi en mode hors ligne s’il le faut, de retravailler l’historique, de faire autant de branches que l’on veut et bien d’autres choses.
En plus du confort et de la puissance qu’il apporte, un tas d’outils sont venus se greffer autour de lui. Je pense principalement à GitHub qui a mis en place une très belle plate-forme intégralement basée sur git. GitHub a démocratisé le concept de Pull Request, qui s’appuie sur les concepts de git et qui est particulièrement adaptée aux projets open-source. GitHub est devenu en quelques années une sorte de The Place to Be pour les projets open-source.
Git est un ami sur lequel le développeur peut compter, mais il ne se laisse pas approcher facilement, son amitié se mérite. En effet, en dépit de toutes ses qualités, git n’est pas très facile à prendre en main et il a le défaut de nécessiter de savoir un petit peu comment il fonctionne pour pouvoir en tirer pleinement parti. Un certain nombre de concepts de git sont franchement différents de ceux de Subversion par exemple. Je pense notamment à des commandes comme checkout ou revert qui existent dans les deux outils mais ne font pas du tout la même chose. Même avec Mercurial, qui est pourtant aussi un système de gestion de version distribué, il y a de profondes différences conceptuelles (les commandes Mercurial sont très similaires à celles de Subversion).
Tous les utilisateurs de git se sont forcément retrouvés au moins une fois dans la git shit (par exemple un commit a disparu). Une fausse manipulation peut vite arriver quand on ne maîtrise pas bien ce qu’on fait. Mais git n’est pas un traître. Il ne perd jamais rien, il enregistre tous les états. Dans le pire des cas, la commande reflog permet de remonter dans le temps.
Une fois qu’on a compris comment il fonctionne, l’utiliser est un vrai plaisir et on ne peut rapidement plus s’en passer grâce au gain en productivité qu’il apporte. Dans le cadre d’un développement logiciel, je ne peux que le conseiller, même si je pense que la migration depuis un autre outil peut être coûteuse et ne doit pas être imposée à une équipe qui n’en a pas envie et qui n’est pas prête à y consacrer du temps. Il est préférable d’avoir un gourou git dans l’équipe qui soit à même de régler les problèmes que vont rencontrer les autres. En revanche, pour des gens qui utilisent un système de gestion de version comme simple outil de partage de fichiers et qui n’utiliseront jamais les branches ou même l’historique, git ne leur apportera que de la complexité superflue, et dans ce cas, je déconseille la migration à git.
Pour terminer, je crois qu’on peut remercier Linus Torvalds pour avoir fait et réussi ce qu’il ne faut en principe pas faire et qui est une mauvaise manie des développeurs : refaire tout soi-même en pensant qu’on peut le faire mieux que les autres. Ceci dit il ne s’est pas contenté de refaire ce qui existait déjà, il a réellement innové et y a mis les moyens qu’il fallait. Il est décidément un récidiviste en la matière.
L’image d’en-tête provient de Flickr.