Devriez-vous utiliser une alternative Git?

Git est incroyablement populaire et pris en charge presque partout. Comme il s'agit pratiquement du système de contrôle de version par défaut, la question se pose: quelles sont vos alternatives? Vaut-il la peine de les considérer et en quoi sont-ils différents?

Notez que cet article présente des alternatives à git comme logiciel de contrôle de source. Si vous cherchez simplement des alternatives à un service hébergé comme Github, vous pouvez plutôt lire notre guide des solutions Git hébergées.

Les inconvénients de Git

Pour mieux comprendre les limites de Git, nous devons d'abord commencer par ce qu'il fait de bien.

Git utilise un modèle de contrôle de source distribué; le référentiel local de chaque utilisateur n'est pas vraiment connecté à n'importe quel serveur central. Cet utilisateur peut se déconnecter, apporter un tas de changements, et personne d'autre ne verra ces changements jusqu'à ce qu'ils soient poussés vers la télécommande. Cela fonctionne extrêmement bien pour le développement de logiciels open source; Git est beaucoup plus rapide pour la plupart des actions, car les utilisateurs individuels peuvent tous cloner un référentiel et apporter leurs propres petites modifications sans avoir à se soucier de ce que font les autres.

Ces modifications peuvent être intégrées dans le référentiel maître à l'aide de demandes d'extraction (l'utilisateur effectuant les demandes de modification pour que le référentiel maître tire les validations de leur version privée du référentiel) et des mises à jour transmises par des utilisateurs authentifiés, à condition que tous les conflits de fusion soient correctement résolus.

Ce modèle a beaucoup de sens pour cet environnement de développement distribué, mais le problème avec Git survient lorsque vous essayez de l'adapter pour une utilisation dans un environnement d'entreprise, où vous aurez souvent beaucoup de gens travaillant sur les mêmes bits de code, et appropriés la coordination est la clé.

Ne vous méprenez pas ici, c'est toujours fantastique, surtout lorsqu'il est associé à un logiciel de suivi des problèmes externes et à des pipelines CI / CD, ce que font des services comme GitLab et BitBucket. Mais Git n'était pas exactement conçu pour être un contrôle de source d'entreprise, où vous allez presque toujours avoir un serveur central agissant comme référentiel maître. Il nécessite une utilisation très appropriée (et souvent des outils externes) pour être efficace pour les équipes agiles poussant de nombreux changements de code.

Avec Git, chaque client stocke une copie complète du journal des modifications du projet. Chaque fois que vous effectuez une validation dans Git, il stocke les modifications effectuées en local sur votre système. Cela rend le travail avec Git très rapide, car il suffit d'interroger un disque dur et non un serveur central. Il vous permet également de travailler beaucoup plus facilement hors ligne. Mais avec de grands projets avec une longue histoire de changement, cela peut aussi conduire à la .git dossier occupant un espace déraisonnable.

De plus, si vous avez plusieurs projets, vous ne voudrez probablement pas que le code source de tout soit visible par chaque développeur. Dans Git, ce problème est généralement résolu en ayant des référentiels séparés pour chaque projet, ce qui fonctionne plutôt bien, mais n'est pas idéal si vous devez les intégrer ensemble dans une pièce cohérente. Avec le contrôle de version centralisé, vous ne pouvez donner accès qu'à des dossiers spécifiques.

Donc, alors que Git n'est probablement pas le faux choix pour votre entreprise, en particulier si elle est correctement mise en œuvre, il existe d'autres options de contrôle des sources conçues spécifiquement pour les flux de travail d'entreprise, et il peut être utile de regarder la concurrence.

L'alternative principale: le contrôle de version centralisé

La différence la plus courante entre Git et les alternatives est la rupture du contrôle de version décentralisé au profit d'un serveur central faisant autorité. Apache Subversion et Team Foundation Version Control sont les principaux systèmes de contrôle de version qui suivent ce format.

À titre de comparaison, dans un système DVC, chaque utilisateur dispose d'un référentiel local dans lequel il valide ses propres modifications. Lorsqu'ils sont prêts à envoyer des mises à jour au serveur maître, il est possible que d'autres utilisateurs aient différentes versions du même fichier sur lequel vous travaillez. Ceci est connu comme un conflit de fusion, et c'est un problème très courant (bien que facilement résolu) avec Git.

Dans le contrôle de version centralisé (CVC) comme Apache Subversion, il existe un référentiel de serveur unique et de nombreux clients y sont directement connectés. Si vous apportez une modification à un fichier, ce fichier est mis à jour sur les ordinateurs des autres utilisateurs à chaque mise à jour. Les validations sont effectuées directement sur le serveur maître.

Pour éviter les conflits de fusion, la plupart des systèmes CVC utilisent des verrous. Si l'utilisateur A souhaite travailler sur un fichier et ne veut pas que quelqu'un d'autre s'en occupe, il peut verrouiller le fichier jusqu'à ce qu'il ait terminé, empêchant les autres utilisateurs de faire de même. Ce n'est pas obligatoire dans Subversion, et les conflits de fusion peuvent toujours se produire, mais ils sont moins un accident.

Le problème est principalement atténué par les branchements et les copies locales, qui permettent à plusieurs utilisateurs de travailler sur leurs propres versions pendant de longues périodes avant de fusionner les modifications.

Une autre grande fonctionnalité du contrôle de version centralisé est la gestion des autorisations; plutôt que de donner accès à l'ensemble du référentiel, CVC facilite la section de l'accès à des dossiers spécifiques. Team Foundation Version Control fonctionne de la même manière que Subversion, permettant une délégation granulaire des autorisations jusqu'au niveau du fichier.

Toutes ces fonctionnalités font du contrôle de version centralisé une alternative viable au DVC. Après tout, Google héberge tout son code dans un système massif et centralisé, beaucoup plus gros que n'importe quel système distribué pourrait gérer. Certes, la base de code Windows est un dépôt Git de 300 Go, mais qui utilise le plug-in Git Virtual File System, qui permet aux utilisateurs de télécharger uniquement les fichiers dont ils ont besoin, et rien de plus.

Un inconvénient de Subversion est qu'il a souvent beaucoup de copies et de téléchargements à faire, ce qui peut le rendre beaucoup plus lent que le modèle local uniquement de Git.

Autres alternatives

Bien que nous nous soyons concentrés sur les systèmes de contrôle de version centralisés qui peuvent remplacer Git, il existe d'autres systèmes de contrôle de version distribués que vous pouvez utiliser, notamment Mercurial.

Mercurial est un peu plus facile à utiliser que Git, et ils sont tous les deux à peu près les mêmes en termes de performances, mais dans l'ensemble, ils sont très similaires. Vraiment, il n'y a pas beaucoup de raisons de choisir Mercurial plutôt que Git, à part les préférences personnelles, qui ne devraient probablement pas dicter les décisions de l'entreprise.

Mercurial était une option dans BitBucket, mais ils l'ont récemment abandonné, la principale raison étant que Git est juste façon plus populaire et largement pris en charge. C'est pratiquement le système de contrôle de version par défaut, et à moins qu'une alternative ne change radicalement le modèle (comme CVC), cela ne vaut pas la peine d'être considéré.