Mardi soir se tenait une session consacrée entièrement à Git au Paris JUG qui a été sponsorisée par In Fine. Elle a rencontré un énorme succès, les places ont été prises d’assaut en moins de 4h. Néanmoins beaucoup de gens se sont fait recaler à l’entrée.
La polémique des inscriptions
Certains ont accusé JUG Events pour ce désastre au niveau des inscriptions. Quoi qu’il en soit, ce site semble de plus en plus inadapté au succès que rencontre le Paris JUG. Il y a quelques mois Nicolas Martignole avait indiqué que JUG Events était open source, et que toute contribution était la bienvenue pour améliorer le site (Google Code de JUG Events). Si vous avez quelques heures pour le faire, n’hésitez pas, toute la communauté des JUG vous en saura gré.
Quiz et Mac Book
In Fine, sponsor du JUG a voulu pour cette soirée créer une animation différente : des boîtiers ont été distribués à chaque participant afin de participer à un quiz portant sur Git et Java principalement, présenté par Antoine Ramponi. Le gagnant du quiz s’est vu remettre un Mac Book Air ! Il s’agit de Guillaume Darmont (@gdarmont) qui a fait un sans faute en répondant correctement aux 18 questions. Bravo à lui ! Les photos sont à la fin de l’article.
Sébastien Douche, l’unique speaker
Sébastien Douche, en habitué, est venu présenté Git en 2 parties : la première théorique est la deuxième avec des cas plus pratiques. Contrairement à sa présentation de l’année dernière sur les DVCS en général, cette soirée est entièrement dédiée à Git.
Mais avant d’attaquer le vif du sujet, rappelons qui est Sébastien Douche. Il se présente comme une personne multi-casquettes. Il est directeur technique, responsable R&D, coach et release manager. Cette dernière a fait qu’il s’est intéressé aux DVCS en général, puisqu’il a également pratiqué Mercurial pendant 2 ans avant de passer à Git. Il a créé un blog sur Git (appelé gitfr) qui lui sert surtout de support pour ses présentations. On y trouvera également de nombreux articles intéressants, ainsi gitfr est devenue une ressource francophone de qualité sur Git.
Son espoir : que le gens travaillent ensemble de manière efficace.
Par ailleurs, il fait de l’agilité, du python, aime la bière.
A suivre sur twitter @sdouche
1ère partie : le backend de Git
A première vue, Git peut sembler complexe, pourtant il est fait de concepts simples. Mis ensemble, ils font la puissance de Git. En passant à Git, Sébastien suggère de tout oublier (en visant SVN notamment). Les habitudes que nous av(i)ons avec Subversion ne sont pas transposables avec Git.
Git est très apprécié par ceux qui l’utilisent. Par exemple dans le Git Survey 2010, 95% des utilisateurs sont heureux ou en extase avec Git. Pas sûr que le résultat soit le même avec un outil comme Subversion.
Sébastien résume Git en 3 points :
- Gestionnaire de contenu
- Stocké sous la forme d’un graphe acyclique d’objets
- Accessible avec des références
Git peut être vu de 2 points de vue : backend et frontend. Le backend est composé de commandes dites “plumbing” et le frontend de commandes dites “porcelain”. Le frontend correspond aux commandes utilisées quotidiennement. Ces commandes font appel aux commandes bas niveau (plumbing) du backend.
Sébastien est convaincu qu’il vaut mieux connaître les concepts clés du backend sur lesquels s’appuie Git afin de mieux l’utiliser et de mieux le maîtriser.
Concept 1 : Git est un gestionnaire de contenu
Git est orienté contenu (contrairement à SVN qui est orienté fichier), cela signifie qu’il stocke les fichiers en entier pour chaque commit, alors qu’un gestionnaire orienté fichier stocke seulement les deltas entre 2 commits.
Les objets sont stockés dans une base de données de type clé/valeur. Les clés sont de type SHA-1. Ce qui assure leur unicité dans le monde entier. Tout objet dans Git peut être identifié à l’aide de son SHA-1.
Exemple de SHA-1 :
da39a3ee5e6b4b0d3255bfef95601890afd80709qui peut être raccourci enda39a3
Git possède 3 types d’objets principaux :
- Blob : contenu des fichiers
- Tree : correspondance entre Blog et nom de fichier
- Commit : ensemble de Tree regroupés lors d’un commit
Concept 2 : La relation entre commits est un graphe acyclique (DAG)
Un graphe acyclique est un graphe sans boucle.
Dans Git, chaque commit connait son ou ses parents, c’est-à-dire quels sont les précédents commits sur le fichier.
Git contient 6 opérations qui permettent d’ajouter du contenu dans le graphe (donc dans la base de données) :
- commit : ajout de contenu dans le graphe
- merge : fusion de 2 branches
- rebase : simplification du graphe en transformant 2 branches en une seule
- squash : nettoyage du graphe
- cherry : copie sans conservation de l’historique
- revert : annulation de l’ajout d’un contenu
Sébastien insiste pour nous dire que sur Git, seule la vision topologique a un sens, contrairement à la vision chronologique d’autres VCS (i.e. SVN). Ainsi Git offre plusieurs commandes permettant d’avoir cette vision en réarrangeant l’historique.
Dans Git, les objets sont immuables. De plus un historique de toutes les actions est conservé, nommé le reflog. Il permet de défaire toute opération qui aurait mal tourné, tel qu’un rebase qui aurait complètement pourri le projet par exemple.
Concept 3 : Les objets sont accessibles sous forme de référence
Deux types de référence existent dans Git :
- Déplacées par Git : par exemple master qui est l’équivalent de head pour Subversion
- Déplacées par l’utilisateur : par exemple un tag léger posé par l’utilisateur
Une branche n’est qu’une référence vers un noeud du graphe déplacée par Git. C’est pourquoi une branche est si rapide à créer. Concrètement, une référence n’est qu’un fichier de 40 octets.
Résumé des concepts
Git peut être vu comme un empilement de couches (de bas en haut) :
- Base de données (objets de type blob)
- Mini système de fichiers (objets de type tree)
- Relation entre objets (objets de type commit)
- Objets facilement mémorisables (références)
La première partie termine comme elle a commencé, en rappelant que Git n’est pas si compliqué. Git n’est pas magique, il est basé sur des concepts simples et bien implémentés. Git est au niveau de ce qu’on attend d’un VCS aujourd’hui, alors que SVN est basé sur CVS qui date des années 80.
2ème partie : Git en pratique
Bien commencer
Dans cette partie, Sébastien a voulu démontrer la puissance de Git en présentant des bonnes pratiques et des fonctionnalités qui lui sont liées.
Il commence avec de quelques conseils pour démarrer avec Git :
- Tout d’abord configurer son identité dans Git : mettre son nom et son adresse mail qui apparaîtront dans les commits
git config --global user.name "Florian Boulay" git config --global user.email "florian.b@mail.com"
git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status
La complexité de Git n’est qu’apparente. Git possède 145 commandes, dont 37 porcelain. Au quotidien, Sébastien en utilise 18. Cela réduit considérablement l’image de la difficulté supposée de Git.
Git est en moyenne plus rapide que Subversion, et ce même sur des commandes distantes. Par exemple un git clone est en moyenne plus rapide qu’un svn checkout.
En parlant de la commande checkout, elle permet pour Git de se déplacer sur le graphe. On peut donc potentiellement faire un commit sur n’importe quelle version d’un fichier. Cependant Git va considérer qu’un commit qui n’est pas fait sur une référence de type branche sera perdu. Cela signifie que le gc pourra supprimer ces références. Cela s’appelle un detached head.
L’index
Git fournit un espace dans lequel l’utilisateur peut mettre les fichiers qu’il souhaite ajouter au commit qui interviendra plus tard. Cet espace se nomme l’index (ou staging area). Ce concept paraît inutile au premier abord, mais Sébastien nous certifie qu’une fois que nous avons pris l’habitude d’utiliser l’index, il est presque impossible de réutiliser un VCS n’en possédant pas. L’index permet de préparer le commit que nous souhaitons faire en y ajoutant les fichiers progressivement une fois le travail effectué sur chacun.
git stash
Si un utilisateur doit interrompre son travail de manière inopinée, plutôt que de devoir faire un commit d’un travail à moitié fini, Git met à disposition une commande permettant de mettre le travail en cours de côté afin de pouvoir le reprendre plus tard : il s’agit de la commande git stash.
Les git stash sont empilables. De plus, on peut reprendre le travail en le mettant sur une nouvelle branche en faisant git stash branch nouvelleBranche.
Récupération des boulettes
git commit –amend permet de modifier le dernier commit effectué.
git reflog permet de revenir en arrière suite à une grosse bêtise tel qu’un rebase ou squash qui n’aurait pas réussi.
git reset permet de revenir en arrière dans le graphe.
Utilisation avancée de certains concepts
tags
Git possède plusieurs types de tags. Sébastien nous conseille d’utiliser à chaque fois le tag annoté au lieu du tag léger, car il permet d’ajouter un message pour lui donner un sens.
rebase
La commande git rebase possède de nombreuses fonctionnalités très puissantes. La documentation à ce sujet est très complète. Quelques unes des puissantes options de rebase sont :
- –onto : permet de faire un rebase d’une branche 3 vers une branche 1 sans tenir compte des modifications de la branche 2
- -i : permet de faire un rebase interactif. Cela donne accès aux options suivantes : édition d’un commit, squash d’un commit, changement de l’ordre des commits
filter-branch
Cette commande possède plusieurs fonctionnalités et notamment celle de modifier l’historique d’une partie du graphe. Par exemple, si des fichiers binaires ont été mis en contrôle de source, git filter-branch permet d’effacer ces fichiers binaires sur un ensemble de commits.
Github
Github est le sourceforge des années 2010. En plus de gérer des repository Git, il permet de mettre en avant le développeur au lieu du projet. Cette dimension sociale se retrouve partout dans l’interface de Git. Plus d’informations sur gitfr.
On finit par…
« Git a-t-il amélioré la vie sexuelle de ses utilisateurs ? », certainement oui.
Git redonne le sourire aux développeurs après tant d’années à batailler avec des VCS non adaptés à leur besoin. Git propose de nombreuses autres fonctionnalités à découvrir : le manuel est complet et intelligible, les ressources sont abondantes sur le net, il ne reste plus aux sceptiques qu’à essayer.
Photos
