Download - Présentation du retour d'expérience sur Git
Open-REX - Git
8 juillet 2010Antoine Büsch
• 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.
Licence
Sommaire
• Introduction
• Concepts• Workflows• Outils
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...
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
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
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
La Philosophie de GitFaire l’inverse de CVS (ou SVN)
Concepts
Concepts
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
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
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 detravail
checkout
Commit add / rm
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
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
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
A B C D E
X Y
F
feature1
master HEAD
v1.0
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.
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
Merge (exemple)
• git merge feature1
A B C D E
X Y
F
feature1
master HEAD
A B C D E
X Y
F
feature1
master HEADM
Concepts avancés
Concepts Avancés
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...
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 !
Rebase (1)
• git rebase master feature1
A B C D E
X Y
F
feature1
master HEAD
Rebase (2)
• Après rebase : même état que si la branche feature1 avait été créée à partir du commit F
A B C D E
X Y
F
feature1
master HEAD
X' Y'
Workflows
Workflows
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 »
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• ...
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
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ôtpartagé
Dev A Dev B Dev C
Utilisation centraliséeavec intégrateur
• Variante du workflow précédent : une seul personne est responsable de commiter sur le dépôt central
intégrateur
Dev A Dev B Dev C
Dépôtpartagé
Dev A Dev B Dev C
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
Dev 1 Dev 2
Team A
Intégrateur
Dev 3 Dev 4
Team B
Dépôtpartagé
Workflows
• Git s'adapte à presque n'importe quel workflow• La principale difficulté de Git : trouver le bon workflow pour
votre organisation !
Outils
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
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
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
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
Questions ?
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