Les outils collaboratifs dédiés à la gestion du code source font partie du quotidien des développeurs depuis une quarantaine d’années déjà. Le besoin de ce type d’outil se manifeste aussi de plus en plus pour des infrastructures matérialisées sur base de code (IaC, Infrastructure as Code), dans un souci croissant d’automatisation et de reproductibilité, particulièrement à l’ère de la virtualisation et du cloud. Un gestionnaire de code, tel que GIT, répond à des besoins essentiels de coordination pour des équipes IT qui doivent partager, synchroniser et versionner leur travail. – Analyse par Jean-Pol Landrain – IT Architect chez Agile Partner

Carte d’identité

Nom	GIT
Genre	Source Code Management (SCM) ou Version Control System (VCS) – Gestionnaire de versions ou de révisions
Fondateur	Linus Torvalds, auteur et développeur principal du noyau Linux
Dates clés	3 Avril 2005 : des conflits entre l’éditeur de BitKeeper et la communauté des développeurs du noyau Linux incitent Linus Torvalds à proposer son propre gestionnaire de code source décentralisé et distribué sous licence libre 16 Juin 2005 : GIT est mis en place pour gérer le code source du kernel Linux qui compte actuellement plus de 18 millions de lignes de code pour plus de 600.000 révisions 2016 : 12 millions d’utilisateurs et 31 millions de projets open-source en ligne sur GitHub
Particularités	Open-source, décentralisé, collaboratif, performant, fiable

 

L’évolution des gestionnaires de code

 

On distingue principalement trois générations de gestionnaires de code. Tout d’abord, il y a eu les outils issus du monde Unix tels que RCS ou SCCS. Nés dans les années 70 et début des années 80, ils permettaient de gérer la synchronisation via des mécanismes de verrous, autorisant une seule personne à effectuer des modifications sur un fichier préalablement verrouillé. La seconde génération a permis, via un serveur centralisé, des modifications multiples d’un ensemble de fichiers par des utilisateurs concurrents. Dans cette approche, une synchronisation préalable doit être effectuée avant d’enregistrer des changements lorsque d’autres utilisateurs ont modifié des fichiers identiques (opération dénommée « merge », semi-automatisée avec nécessité de résoudre manuellement les conflits lorsque des modifications se superposent). Parmi cette seconde génération, très populaire dans les années 90 et début 2000, on retrouve des outils tels que Subversion (SVN), CVS, Visual SourceSafe, Team Foundation Version Control (TFS), Perforce ou PVCS. La troisième et dernière génération de gestionnaires de code source est celle des outils distribués (DVCS) qui proposent des opérations de sauvegarde et de synchronisation non-corrélées, ainsi que des synchronisations qui peuvent désormais se faire entre utilisateurs sans nécessairement passer par un serveur centralisé. Ce dernier reste toutefois utile afin d’assurer la disponibilité d’un référentiel de code ; il est souvent souhaitable, mais n’est absolument pas obligatoire. Les DVCS les plus populaires sont par ordre décroissant GIT, Mercurial (Hg) et Bazaar (Bzr).

 

En quoi un DVCS est-il différent ? Quels en sont ses avantages ?

 

Lorsqu’on travaille avec un gestionnaire de code centralisé, donc de seconde génération, on est très rapidement confronté à certaines limites de l’outil.

 

En tout premier, la nécessité de disponibilité du serveur pour chaque opération. Que ce soit récupérer le code localement, parcourir l’historique des changements, réconcilier du code issu de modifications distinctes, le versionner ; chacune de ces opérations requière un ou plusieurs accès réseau au serveur qui se trouve, dans le meilleur des cas, sur un réseau local. Selon la complexité des opérations, les accès réseau peuvent plus ou moins rapidement devenir un frein sérieux à la productivité (sans même parler des indisponibilités éventuelles pour pannes ou pour des opérations de maintenance). A contrario, lorsque l’on utilise un DVCS, on obtient au moment de la récupération du code une copie complète de la base de données du référentiel. Cette première opération est parfois un peu plus longue qu’avec un système centralisé (bien que largement optimisée par des algorithmes de compression). Toutes les opérations suivantes, mis à part celles de resynchronisation sur le référentiel, se font ensuite sur le poste local. Le gain de productivité pour les utilisateurs est immédiat.

 

Un avantage accessoire de cette topologie est la limite du risque de perte de données, puisque chaque développeur en possède une copie intégrale, relativement à jour. Le seul désavantage potentiellement visible est l’augmentation de l’espace de stockage requis sur le poste local. GIT utilise toutefois des algorithmes de compression afin de limiter cette conséquence. Il est aussi possible d’archiver et de nettoyer l’historique plus ancien lorsque la base de données du code devient trop importante.

 

Cela entraîne une seconde conséquence : il est tout à fait possible de travailler sans accès réseau, ou bien avec un accès très limité ou occasionnel en déplacement. Ceci même en synchronisant le travail entre plusieurs personnes, via un réseau point-à-point, un échange par média de stockage (disque externe, clé usb, …) ou même par envoi de modifications via e-mail. On pourra ensuite, lorsqu’on aura de nouveau accès au réseau, resynchroniser son travail sur le référentiel.

 

[Anecdotiquement, les développeurs du noyau Linux travaillent par échange de modifications formatées, que l’on dénomme « patches », envoyées dans des e-mails. Ceci pour des raisons de performance et de flexibilité, et pour la facilité d’automatisation de certaines tâches répétitives]

 

Un autre aspect des DVCS, et de GIT en particulier, est sa flexibilité : il permet de travailler de différentes façons et n’en impose aucune. Il existe de multiples stratégies d’organisation du travail dans les équipes de développement et GIT peut s’adapter à l’ensemble des situations (dans le jargon, on parle de workflows de développement). Toutefois, le choix de la bonne stratégie à adopter vis-à-vis de l’outil nécessite un peu de réflexion préalable, accompagnée parfois de l’établissement de quelques règles d’utilisation relativement simples.

 

Contrairement à des VCS centralisés, les DVCS encouragent fortement la création de branches. Il s’agit dans ce cas d’opérations locales et peu coûteuses, qui pourront toutefois se partager facilement entre un ensemble restreint d’utilisateurs collaborant sur une tâche commune. Ainsi, un workflow typique de travail consiste à créer une branche par tâche à réaliser ; ceci tout en permettant de passer très rapidement d’une branche à une autre lorsque l’on travaille sur plusieurs changements en parallèle. La réconciliation du travail dans la base commune (opération « merge ») se voit également facilitée par des algorithmes performants (et exécutés localement), rendant cette tâche bien plus aisée qu’avec des gestionnaires centralisés. Il est également possible de spécifier des droits d’accès sur certaines branches, ce qui aura pour effet de définir des workflows où, par exemple, seul des développeurs plus expérimentés pourront agréger des modifications dans la base commune, assurant ainsi un mécanisme de révision manuelle du code. Dans ce scénario, les branches servent généralement de vecteur de communication et d’échange des modifications.

 

Pourquoi GIT par rapport aux autres DVCS ?

 

Tout d’abord GIT est très rapide, même comparé à d’autres DVCS. La façon dont il structure sa base de données est hautement performante. Pour son organisation interne, il utilise un algorithme dénommé « arbre de Merkle », qui construit un arbre basé sur des chaînes de hachage, ce qui rend les opérations très performantes : toute opération est proportionnelle au logarithme du nombre total d’éléments dans l’arbre. Les crypto-monnaies, comme le BitCoin par exemple, utilisent également cette forme de structure des données.

 

De par son utilisation de chaînes de hachage, GIT est également à même de comprendre une grande partie des modifications effectuées sur vos fichiers. Ainsi, lorsque vous renommez un fichier ou que vous le déplacez dans l’arborescence de code, GIT est généralement capable de comprendre l’opération sans que vous n’ayez à la lui spécifier explicitement par l’utilisation d’une commande particulière de l’outil.

 

Ensuite, il existe de nombreux gestionnaires de repositories pour GIT qui correspondent à différentes situations d’utilisation. Pour des équipes réduites, on peut commencer à l’utiliser totalement gratuitement en ligne en hébergeant son code source dans des repositories publiques ou privés. Cette solution en ligne devient souvent payante lorsque l’on veut partager des repositories privés entre un plus grand nombre d’utilisateurs. Des produits tels que GitHub, GitLab ou Atlassian BitBucket Hosted offrent ce genre de solution en ligne. On peut également choisir de conserver son code source au sein de l’entreprise en se basant sur des solutions relativement identiques à celles que l’on retrouve en ligne, mais parfois un plus coûteuses : par exemple, les produits GitHub Enterprise, GitLab Enterprise ou Atlassian BitBucket Server offrent ce type de solution. Gitea, GitBucket et Gitolite en sont des alternatives open-source.

 

L’apprentissage de GIT peut toutefois être un peu fastidieux. Il y a beaucoup d’opérations différentes, avec un certain nombre d’options, pas toujours très intuitives, surtout pour les personnes qui ont utilisé d’autres VCS dans le passé. Par exemple, dans GIT la commande « checkout » ne récupère pas le code source depuis un référentiel distant, contrairement à cette même commande dans CVS ou SVN. Son effet est de récupérer le contenu d’une branche dans l’espace de travail local. Par ailleurs, la commande « commit » n’effectue qu’une sauvegarde locale des changements, contrairement aux outils centralisés qui sauvegardent les modifications sur le référentiel distant avec la commande « commit ». On constate que la multiplicité des commandes de GIT force tôt ou tard les utilisateurs à avoir une connaissance au moins partielle du fonctionnement interne de l’outil, afin d’en comprendre ses subtilités.

 

Par ailleurs, GIT est peu apte à stocker des fichiers binaires. Ceci en fait bien souvent un mauvais choix pour d’autres types d’utilisations que pour du code.

 

On vous le dit !

Si vous n’êtes pas encore passé à GIT, il est sans doute temps de vous y mettre. Le gain de productivité apporté par cette solution suffit largement à justifier le temps passé à se former. Si même vous travaillez seul sans partager pas votre code avec d’autres personnes, il est utile de pouvoir versionner vos modifications. Par ailleurs, les statistiques d’utilisation indiquent que GIT est désormais l’outil de premier choix pour la gestion du code source. Il est disponible sur tous les systèmes d’exploitation et continue à s’améliorer à chaque nouvelle version, tant au niveau des possibilités de l’outil que des outils proposés autour de la solution. Il s’intègre parfaitement avec les environnements de développement et les outils d’intégration continue (Jenkins, SonarQube, TFS, Bamboo, TeamCity, etc). Il est même souvent devenu la solution de premier choix au sein de ces divers outils.

 

Si vous souhaitez l’essayer, sans forcément passer par la ligne de commande et sans recourir à un environnement de développement, il existe de nombreux clients disponibles. Nous vous suggérons en particulier l’excellent Atlassian SourceTree, disponible gratuitement sous Mac et Windows (nécessite un compte enregistré gratuitement chez Atlassian pour obtenir la licence d’utilisation). Pour une utilisation en ligne, GitKraken est vraiment simple à utiliser sur tous les systèmes d’exploitation. Il s’intègre avec les repositories en ligne de GitHub, GitLab et Atlassian Bitbucket. Sa licence est gratuite pour une utilisation non-commerciale. Sous Linux, nous vous conseillons le couple git-gui et gitk, qui sont les clients standards fournis à l’installation de GIT. Ce ne sont sans doute pas les clients les plus intuitifs, mais leurs fonctionnalités sont extrêmement complètes. Par ailleurs, gitk fournit des possibilités de recherche dans l’historique très avancées, que l’on ne retrouve pas forcément au sein d’autres clients.

 

Bien entendu, si vous aussi avez fait l’expérience de GIT, n’hésitez pas à venir échanger avec nous sur notre blog !