Pourquoi Git est Meilleur Que X

La fonctionnalité majeure qui met Git à part de tous les autres SCM est le modèle de gestion des branches. Il est complétement différent de tous les modèles comparés ici, la plupart recommandant que la meilleure façon de créer une branche est de cloner le dépôt dans un nouveau répertoire.

Git ne fonctionne pas comme ça. Git vous permettra d'avoir de multiples branches locales qui peuvent être totalement indépendante les unes des autres, et dont la création, la fusion (merge) ou la suppression ne prennent que quelques secondes.

Cela veut dire que vous pouvez faire ce genre de choses:

• Créer une branche pour essayer une nouvelle idée, committer quelques fois, revenir à l'endroit où vous avez créé cette branche, appliquer un patch, retourner là où vous expérimentez et fusionnez le avec votre branche principale.
• Avoir une branche qui contient toujours ce qui va en production, une autre que vous fusionnez votre travail pour faire des test, et quelques autres plus petites pour le travail au jour le jour.
• Créer une nouvelle branche pour toutes les fonctionnalités que vous développez, comme ça vous pourrez aller et revenir facilement entre-elles, et effacer chaque branche une fois que la fonctionnalité est incluse dans la branche principale.
• Créer une branche pour vos expérimentations, et si vous réalisez que ça ne fonctionne pas, il vous suffit de la supprimer pour abandonner le travail, sans personne pour le voir (même si vous poussez d'autres branches entre temps)

Important: quand vous poussez les modifications sur un dépôt distant, vous n´êtes pas obligés de poussez toutes vos branches. Vous pouvez partager les branches que vous désirez. Cela libère les gens pour expérimenter avec des nouvelles idées sans se soucier de savoir quand et comment ils devront combiner cette idée ou la partager avec les autres.

Vous pouvez repliquer certaines de ces pratiques avec les autres systèmes, mais l'effort nécessaire est bien plus grand et peut amener à se tromper. Git rend ces processus incroyablement simples et ça change la manière de travailler pour la plupart des développeurs qui les apprennent.

Cela est par défaut vrai pour tous les SCM distribués, mais d'expérience encore plus avec Git. En dehors de 'fetch', 'pull' et 'push', peu d'autres commandes communiquent avec autre chose que votre disque dur.

Cela ne permet pas seulement de rendre chaque opération plus rapide que d'habitude, mais ça vous permet aussi de travailler quand vous n'êtes pas connecté à internet. Ca n'a pas l'air important, mais je me surprend toujours du nombre de fois où je travaille déconnecté. Avoir la possibilité de créer des branches, de combiner, de faire des commit et de parcourir l'historique de votre projet dans l'avion ou le train est très productif.

Même dans Mercurial, les commandes commune comme 'incoming' ou 'outgoing' font une requête au serveur, alors qu'avec Git vous pouvez 'fetch' toutes les données du serveur avant de vous déconnecter et faire des comparaisons, combinaisons et des logs de données qui sont sur les serveurs mais pas encore dans vos branches locales.

Cela signifie qu'il est très simple d'avoir une copie, non seulement de vos branches, mais aussi des branches de tous ceux qui travaillent avec vous sur votre dépôt Git sans avoir à gâcher vos propres affaires.

Git est rapide. Tout le monde, même les utilisateurs les plus hardcore des autres systèmes, donnent à Git ce titre. Comparé à SVN et Preforce, cela vient du fait que toutes les opérations se font localement. Cependant, même comparé aux autres DSCM, Git est vraiment rapide.

Une partie de l'origine de cette vitesse vient du fait que Git a été construit pour travailler le source du noyau Linux, ce qui veut dire qu'il devait gérer efficacement un large nombre de dépôt dès le premier jour. Un autre raison est que Git est écrit en C, et encore une autre raison est que les développeurs à l'origine de git sont, à mon expérience, très très soucieux de la rapidité de leurs applications.

Voici quelques benchmarks que j'ai effectués sur 3 copies du dépôt des sources de Django avec 3 SCM différents: Git, Mercurial et Bazaar. J'ai aussi testé quelques parties sur SVN, mais croyez moi, c'est plus lent - en gros prenez les chiffres de Bazaar et ajoutez le temps de latence du réseau...

Le résultat final est que pour toutes les commandes, à part l'ajout d'un fichier, Git est le plus rapide. (Aussi pour les commit très larges, dans lequel Hg a des résultat similaires, mais le commit que j'ai testé était tellement grand qu'il est vraisemblable que vous tombiez sur ce genre de cas - les commit normaux sont plus rapides avec Git)

Les chiffres des branches à froid et à chaud sont les chiffres de la création d'une première puis d'une seconde branche sur le dépôt - le second chiffre étant une branche avec un cache disque déjà prêt.

Bien que les chiffres 'add' sont bien plus petit, c'était une opération d'ajout massif - plus de 2000 fichiers. Pour la majorité des cas que les gens rencontrent chaque jour, les opérations d'ajout ne prennent qu'une fraction de seconde. Toutes les autres opérations testées ici (à part peut-être le l'énorme commit) sont plus indicatifs des choses que vous serez amenés à faire au jour le jour.

Ces chiffres ne sont pas difficiles à reproduire, il vous suffit de cloner le projet Django avec chaque système et d'essayer la même commande dans chacun.

• git clone git://GitHub.com/brosner/django.git dj-git
• hg clone http://hg.dpaste.com/django/trunk dj-hg
• bzr branch lp:django dj-bzr
• svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn

Git est très efficace pour minimiser sa taille. Votre répertoire Git sera (en général) à peine plus lourd qu'un checkout SVN - et voir dans certains cas plus léger (apparemment beaucoup de choses vont dans ces répertoires .svn).

Les chiffres suivants viennent du clonage du projet Django, dans chacun de ses mirroirs Git semi-officiels à un certain moment du projet.

A la différence des autres systèmes, Git propose ce qu'il appelle une "Aire d'Assemblage" ou "index". C'est une zone intermédiaire où vous pouvez configurer votre commit avant de l'effectuer.

La chose la plus cool grâce à cette zone, et ce qui fait que Git est à part des autres outils, est que vous pouvez facilement assembler certains de vos fichiers en les terminant et puis les commiter sans toucher aux autres fichiers modifiés de votre répertoire de travail, ni les lister dans la ligne de commande durant le commit.

Cela permet aussi d'assembler certaines parties des fichiers modifiés, par exemple en assemblant seulement les changements au début du fichier que vous êtes en train de coder, mais sans les changements en bas de ce fichier.

Bien sûr, Git permet aussi d'ignorer assez facilement cette fonctionnalité si vous ne voulez pas de ce genre de contrôle - ajoutez juste un '-a' à votre commande de commit.

Une des fonctions les plus cool de n'importe quel SCM distribué, Git inclus, est qu'il est distribué. Cela veut dire qu'au lieu de faire un "checkout" sur la dernière version du code, vous pouvez cloner l'intégralité du dépôt.

Cela veut dire que même si vous utilisez un workflow centralisé, chaque utilisateur est essentiellement une sauvegarde complète du serveur central, chacun pouvant servir à remplacer ce serveur central en cas de crash ou de corruption. En simplifiant, il n'y a fondamentalement pas de point de défaillance unique avec Git, à moins que vous n'ayez qu'une copie de votre dépôt.

Cela n'affecte en rien les performances. En moyenne, un checkout SVN est plus rapide que n'importe quel DSCM, mas sans grande différence. De plus, concernant les DSCM, Git était le plus rapide durant mes tests.

Une des choses incroyables avec Git, grâce à sa nature distribuée et à sa superbe gestion des branches, est que vous pouvez facilement utiliser le type de workflow qui vous semble le plus naturel.

Il est très commun d'utiliser un workflow centralisé avec Git, surtout pour les personnes venant juste de migrer depuis un système centralisé. Git ne vous permettra pas de pousser un commit si quelqu'un a modifié quelque chose depuis votre dernière mise à jour, ce modèle centralisé où tous les développeurs poussent sur le même serveur fonctionne très bien.

Un autre workflow commun pour Git consiste à désigner un manager d'intégration - une seule personne peut faire les commits sur le 'Saint-dépôt'. Le reste des développeurs clone ce dépôt pour créer des dépôts indépendants sur lesquels ils pourront faire leurs commits, pour ensuite demander au manager de récupérer leurs changements. C'est le modèle de développement que vous verrez souvent avec les dépôts open source ou sur GitHub.

Pour les projets de grande taille, vous pouvez organisez vos développeurs à la façon du noyau Linux, où certaines personnes sont en charge d'un sous-système spécifique du projet ('lieutenant') et elles combinent tous les changements de leur sous-système. Puis, un autre intégrateur ('dictateur') peut récupérer seulement les changements de ses lieutenants, et pousser ces modifications sur le 'Saint-dépôt', que tout le monde peut cloner à nouveau.

Une fois encore, Git est entièrement flexible avec les workflow, vous pouvez donc mélanger, reproduire et choisir le workflow qui vous convient.

GitHub est à l'origine du choix de Git pour beaucoup de gens car c'est plus un "réseau social pour code source" qu'un simple hébergeur. Le site permet de trouver d'autres développeurs ou des projets qui sont similaires aux choses que vous faites, et auxquels vous pouvez facilement forker ou contribuer, en créant une communauté vibrante autour de Git et des projets utilisés avec Git.

Il y a d'autres services, pour Git ou d'autres SCM, mais peu sont tournés vers l'utilisateur ou l'usage des réseaux sociaux, et aucun n'arrive à regrouper autant de monde. L'aspect social de GitHub est fantastique, et cela, en plus de toutes les autres fonctionnalités précédentes, fait de Git et GitHub une superbe combinaison pour rapidement développer des projets open source.

Ce type de communauté n'existe simplement pas avec les autres SCM.

Cela n'a pas toujours été le cas - dans les premières versions de Git, ce n'était pas vraiment un SCM, sinon un groupe d'outils qui vous permettaient de travailler avec des versions sur un système de fichier, de manière décentralisée. Cependant, aujourd'hui, la liste des commandes et la vitesse d'apprentissage de Git sont assez similaires aux autres SCM, et même meilleures.

Il est difficile de prouver objectivement cela sans une étude de quelque sorte; je vais vous montrer la différence entre le menu 'help' par défaut pour les commandes Git et Mercurial. J'ai surligné les commandes qui sont identiques (ou presque) entre les 2 systèmes. (avec Hg, si vous tapez 'hg help', vous obtiendrez un liste d'une quarantaine de commandes).

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...

Avant Git 1.6, toutes les commandes Git étaient des chemins vers des fichiers exécutables, cela était très déroutant pour beaucoup de monde. Bien que Git reconnaisse toujours toutes ces commandes, 'git' est maintenant la seule commande dans le path. Donc, si vous regardez Mercurial et Git, Git a maintenant une liste de commandes, et un système d'aide, presque identique - il y a très peu de différence au niveau de l'interface actuellement.

Ces jours-ci, il est plutôt difficile de dire que Mercurial ou Bazaar sont plus simples à apprendre que Git.