Eh bien, c'est distribué. Les benchmarks indiquent qu'il est considérablement plus rapide (étant donné sa nature distribuée, les opérations telles que les diffs et les journaux sont toutes locales, donc bien sûr c'est incroyablement plus rapide dans ce cas), et les dossiers de travail sont plus petits (ce qui m'épate toujours).

Lorsque vous travaillez sur subversion ou sur tout autre système de contrôle de révision client/serveur, vous créez essentiellement des copies de travail sur votre machine en extrayant les révisions. Cela représente un instantané dans le temps de ce à quoi ressemble le référentiel. Vous mettez à jour votre copie de travail via des mises à jour et vous mettez à jour le référentiel via des commits.

Avec un contrôle de version distribué, vous n'avez pas d'instantané, mais plutôt l'intégralité de la base de code. Tu veux faire un diff avec une version de 3 mois ? Pas de problème, la version de 3 mois est toujours sur votre ordinateur. Cela ne signifie pas seulement que les choses sont beaucoup plus rapides, mais si vous êtes déconnecté de votre serveur central, vous pouvez toujours effectuer de nombreuses opérations auxquelles vous êtes habitué. En d'autres termes, vous n'avez pas seulement un instantané d'une révision donnée, mais l'intégralité de la base de code.

On pourrait penser que Git occuperait beaucoup d'espace sur votre disque dur, mais d'après quelques benchmarks que j'ai vus, cela prend en fait moins. Ne me demandez pas comment. Je veux dire, il a été construit par Linus, il connaît une chose ou deux sur les systèmes de fichiers, je suppose.

Git et DVCS en général sont parfaits pour les développeurs qui font beaucoup de codage indépendamment les uns des autres, car chacun a sa propre branche. Si vous avez besoin d'un changement de la part de quelqu'un d'autre, cependant, elle doit s'engager dans son référentiel local, puis elle doit vous transmettre cet ensemble de modifications ou vous devez le lui retirer.

Mon propre raisonnement me fait également penser que DVCS rend les choses plus difficiles pour l'assurance qualité et la gestion des versions si vous faites des choses comme des versions centralisées. Quelqu'un doit être responsable de faire ce push/pull depuis le référentiel de tout le monde, de résoudre tous les conflits qui auraient été résolus au moment de la validation initiale, puis de faire la construction, puis de demander à tous les autres développeurs de resynchroniser leurs référentiels.

Tout cela peut être résolu avec des processus humains, bien sûr ; DVCS vient de casser quelque chose qui a été corrigé par le contrôle de version centralisé afin de fournir de nouvelles commodités.

Git facilite également la création de branches et la fusion. Subversion 1.5 vient d'ajouter le suivi des fusions, mais Git est toujours meilleur. Avec Git, la création de branches est très rapide et bon marché. Cela facilite la création d'une branche pour chaque nouvelle fonctionnalité. Les dépôts Oh et Git sont très efficaces avec de l'espace de stockage par rapport à Subversion.

Une des choses à propos de SubVersion qui m'irrite est qu'il met son propre dossier dans chaque répertoire d'un projet, alors que git n'en met qu'un seul dans le répertoire racine. Ce n'est pas si un gros problème, mais de petites choses comme ça s'additionnent.

Bien sûr, SubVersion a Tortoise, qui est [généralement] très agréable.

Grâce au fait qu'il n'a pas besoin de communiquer constamment avec un serveur central, presque toutes les commandes s'exécutent en moins d'une seconde (évidemment, git push/pull/fetch sont plus lents simplement parce qu'ils doivent initialiser les connexions SSH). La création de branches est beaucoup plus facile (une simple commande pour créer une branche, une simple commande pour fusionner)