Support de la présentation "Retour d'expérience sur Git"

1. Open-REX - Git
8 juillet 2010
Antoine Büsch

2. Licence
• Cette présentation vous est fournie sous licence Creative Commons
Attribution Share Alike
• Vous êtes libres :
– De reproduire, distribuer et communiquer cette création au public
• Selon les conditions suivantes :
– Paternité. Vous devez citer le nom des auteurs originaux mais pas d'une
manière qui suggèrerait qu'ils vous soutiennent ou approuvent votre
utilisation de l'œuvre.
– A chaque réutilisation ou distribution de cette création, vous devez faire
apparaître clairement au public les conditions contractuelles de sa mise à
disposition sous licence identique Creative Commons Share Alike.
– Chacune de ces conditions peut être levée si vous obtenez l'autorisation
du titulaire des droits sur cette œuvre.
– Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur
ou des auteurs.

3. Sommaire
• Introduction
• Concepts
• Workflows
• Outils

4. Présentation
• D'après le Merriam-Webster :
– a foolish or worthless person
• C'est aussi un gestionnaire de versions :
– distribué
– open-source
– rapide
• Même catégorie que Bazaar, Mercurial, Monotone,
BitKeeper...

5. Historique
• Créé en avril 2005 par Linus Torvalds pour le
développement du noyau Linux :
– avant 2002 : patches and tarballs
– 2002 à 2005 : utilisation de BitKeeper (propriétaire)
– avril 2005 : license de BitKeeper révoquée

6. Historique
• Démarrage du projet Git pour remplacer BitKeeper :
– 3 avril 2005 début du projet
– 6 avril 2005 annonce du projet
– 7 avril 2005 Git est ”self-hosting”
– 16 juin 2005 première release du noyau (2.6.12) faite avec Git
– 26 juillet 2005 Junio Hamano devient mainteneur du projet
– 21 déc. 2005 sortie de la version 1.0

7. Caractéristiques
• Principales caractéristiques de Git :
– Supporte les historiques non-linéaires
– Supporte les développements distribués
– Compatibilité avec les protocoles existants
– Support efficace des gros projets
– Intégrité de l’historique assurée cryptographiquement
– Architecture modulaire
– Archive des snapshots de contenu, pas des fichiers

8. La Philosophie de Git
Faire l’inverse de CVS (ou SVN)

9. Concepts
Concepts

10. Dépôt (Repository)
• Git est un gestionnaire de version décentralisé
– Chaque dépôt est techniquement égal aux autres
– Chaque dépôt contient l'intégralité de l'historique du projet
• On ne fait pas un checkout d'un projet, on fait un clone
– La plupart des opérations se font en local, sans accès réseau
• Commit
• Branches/merges
• Consultation de l'historique
– Les dépôts peuvent communiquer entre eux et s'échanger des
commits

11. Anatomie d'un dépôt Git
• Le répertoire .git
– Uniquement à la racine du projet : ne pollue pas tous les
répertoires
– Un commit ou un update affecte tout le projet : pas de possibilité
de mettre à jour un seul sous-répertoire
– Contient la configuration Git du projet
– Contient les références
– Contient la base de donnée des commits
• Le répertoire de travail
– Contient l'espace de travail : les fichiers de l'utilisateur dans une
version donnée

12. Structures de données
• Git possède 3 structures de données principales :
1. La base de donnée : contient le graphe des commits
2. L'index : espace temporaire où sont préparés les commits
3. L'espace de travail : l'arbre des fichiers dans une version donnée
BDD Index Espace de
travail
Commit add / rm
checkout

13. Commits
• Git maintient un graphe orienté de commits.
• Chaque commit représente l’état du contenu des fichiers à
un instant t
• Un commit est représenté par un code SHA-1, qui
dépend :
– du contenu de tous les fichiers
– du message du commit
– du SHA-1 du ou des commits parents
➔
Git peut-être vu comme une grosse hashmap dont les
valeurs sont le contenu de tous les fichiers, et les clés sont
des codes SHA-1

14. Références
• Une référence est un simple pointeur vers un commit. Peut
être :
– un simple label (tag)
– une référence de branche : pointe vers le commit le plus récent de
la branche
• On distingue :
– Les références locales : modifiables par l'utilisateur
– Les références « remotes » : non modifiables directement par
l'utilisateur

15. Références
• Il existe une référence particulière : HEAD
– Pointe toujours vers la référence de la branche courante
– Lorsqu'on commite, c'est la référence de branche pointée par
HEAD qui avance
X Y feature1
A B C D E F master HEAD
v1.0

16. Branches
• Créer une branche = créer une référence vers un commit
– Extrement léger
– Instantané
– Facile de changer d'une branche à une autre
• Les branches sont faciles à merger
• Git encourage l'utilisation des branches
– Une branche par feature / bug-fix / etc.

17. Merges
• Contrairement à CVS/SVN, l'historique dans Git n'est pas
linéaire : les commits sont organisés en graphe orienté
– Un commit normal a 1 parent
– Un commit de merge a 2 parents ou plus
• Quand on merge 2 branches :
– Git est capable de retrouver l'ancêtre commun, et sait donc quels
commits considérer pour le merge,
– Les commits des 2 branches font partie intégrante de l'historique
du commit de merge.
– Git ne tracke pas les fichiers en tant que tels : capable de détecter
les renommage a posteriori
• Git garde donc beaucoup plus d'information d'historique
– Au final : merges plus faciles, moins de conflits

18. Merge (exemple)
• git merge feature1
X Y feature1
A B C D E F master HEAD
X Y feature1
A B C D E F M master HEAD

19. Concepts avancés
Concepts Avancés

20. Réécriture d'historique
• Git vous donne un dépôt à part entière, mais également
les outils pour réécrire une partie de l'historique
– Possibilité de revenir en arrière (Undo), pour éliminer les n derniers
commits
– Possibilité de corriger le dernier commit : oubli d'un fichier,
commentaire incomplet...
– Possibilité de faire un « rebase » d'une branche
• Attention : ces opérations sont puissantes mais
potentiellement dangereuses
• À ne faire que sur des commits locaux : si
des commits qui ont été partagés (via git
push ou git pull) sont affectés, vous allez
vous faire des ennemis...

21. Rebasing
• Rebasing : prend tous les commits d'une branche à partir
d'un certain point, et réapplique les changements
introduits, dans l'ordre, à un autre endroit
• Permet de garder une branche synchronisée avec le tronc,
sans avoir à faire de merges successifs.
• Les commits de la branche après un rebase sont de
nouveaux commits
• À ne faire que sur une branche locale !

22. Rebase (1)
• git rebase master feature1
X Y feature1
A B C D E F master HEAD

23. Rebase (2)
• Après rebase : même état que si la branche feature1 avait
été créée à partir du commit F
X Y X' Y' feature1
A B C D E F master HEAD

24. Workflows
Workflows

25. Workflows
• Git est un outil puissant, flexible, mais qui n'impose pas de
workflow particulier : s'adapte à votre besoin
– Utilisation en solitaire
– Utilisation en environnement mixte (CVS/SVN)
– Utilisation de type centralisée
– Utilisation centralisée avec intégrateur
– Utilisation de type « dictateur / lieutenant »

26. Utilisation solitaire
• Parfaitement adapté pour des projets personnels
– Création d'un dépôt instantanée
– Pas besoin de serveur
– Tous les avantages d'une gestion de version :
• Retours en arrière
• Branches
• ...

27. Utilisation en environnement mixte
• Des passerelles existent entre Git et d'autres VCS (CVS,
SVN...)
• Le premier « clone » récupère l'intégralité de l'historique :
opération potentiellement lente
• Ensuite, possibilité de synchroniser dans les 2 sens entre
Git et CVS ou SVN
• Avantages de Git pour son travail personnel (branches,
rapidité, historique local, …)
• Passage par CVS ou SVN pour la collaboration
• Attention : CVS ou SVN imposent des limitations
– Pas possible d'envoyer vers SVN des commits de merge
– Utilisation fréquente du rebasing pour garder un historique plus
linéaire

28. Utilisation centralisée
• Même si Git est un DVCS, il est possible de l'utiliser de
manière centralisée
• Utilisation courante en entreprise
Dépôt
partagé
Dev A Dev B Dev C

29. Utilisation centralisée
avec intégrateur
• Variante du workflow précédent : une seul personne est
responsable de commiter sur le dépôt central
Dépôt
intégrateur
partagé
Dev A Dev B Dev C

30. Organisation par équipe
• Chaque équipe travaille indépendement
• Un intégrateur intègre les différentes fonctionnalités et
commite sur le dépôt central
Dépôt
Intégrateur
partagé
Team A Team B
Dev 1 Dev 2 Dev 3 Dev 4

31. Workflows
• Git s'adapte à presque n'importe quel workflow
• La principale difficulté de Git : trouver le bon workflow pour
votre organisation !

32. Outils

33. Outils
• La ligne de commande !
– Reste le plus puissant (pemet le rebasing interactif) et souvent le
plus rapide
• Interfaces graphiques
– Gitk : outil graphique fourni en standard. Basé sur des technos
vieillissantes (Tcl/Tk)
– GitX sous MacOs
– gitg sous Gnome...
– En mode texte : tig
– TortoiseGit sous Windows
• Intégration IDE : facilite les opérations de base, mais
souvent incomplet pour les opérations complexes
– Eclipse : plugin Egit, basé sur Jgit
– Netbeans : module nbgit, basé sur Jgit
– IDEA : en standard dans v9

34. Outils
• Plugin maven
– Implémentation du plugin SCM pour Git
• Serveurs de CI
– Plugins pour Hudson, Bamboo...
• Interfaces web
– Gitweb fourni en standard : affichage basique des
commits/branches/tags
– Gitorious : permet les créations de dépôts, les clones, les demande
de merge, etc...
• Gitosis / Gitolite : gestion d'ACL
– Permet de définir les permissions pour chaque utilisateur au
niveau dépôt ou branche

35. Outils
• Gerrit : système de revue de code, initié par Google
– Utilisé pour le developpement d'Android
– Fonctionne comme un « faux » dépôt Git sur lequel on pousse des
commits
– Les utilisateurs peuvent alors revoir / commenter les patches
– Lorsque le patch est approuvé, il est poussé vers le vrai dépôt
central

36. Conclusion
• Essayez Git !
– Pas si difficile que ça avec la bonne approche → ne pas se dire
que ça marche comme SVN !
– Ce n'est qu'un outil
• De plus en plus difficile à ignorer
– Bien implanté dans le monde open-source (Noyau Linux, X.org,
VLC, Gnome, Wine…)
– Commence à être populaire dans le monde Java : projet Maven,
projet Eclipse, Android, …
• Flexibilité, adapation à différents workflow
• Se prête bien aux méthodologies Agiles :
– Plus de puissance dans les mains des developpeurs
– Responsabilisation

37. Questions ?

38. Références
• http://git-scm.com/
– Site officiel
• http://progit.org/book/
– Très bon livre gratuit en ligne
• http://gitref.org/
– Référence
• http://nvie.com/git-model
– Excellent post expliquant un modèle de branches
• http://blog.javabien.net/2009/12/01/serverless-ci-with-git/
– Exemple d'integration continue sans serveur
• http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
– Documentation de git-svn