38
Open-REX - Git 8 juillet 2010 Antoine Büsch

Présentation du retour d'expérience sur Git

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Présentation du retour d'expérience sur Git

Open-REX - Git

8 juillet 2010Antoine Büsch

Page 2: Présentation du retour d'expérience sur Git

• 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

Page 3: Présentation du retour d'expérience sur Git

Sommaire

• Introduction

• Concepts• Workflows• Outils

Page 4: Présentation du retour d'expérience sur Git

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...

Page 5: Présentation du retour d'expérience sur Git

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

Page 6: Présentation du retour d'expérience sur Git

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

Page 7: Présentation du retour d'expérience sur Git

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

Page 8: Présentation du retour d'expérience sur Git

La Philosophie de GitFaire l’inverse de CVS (ou SVN)

Page 9: Présentation du retour d'expérience sur Git

Concepts

Concepts

Page 10: Présentation du retour d'expérience sur Git

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

Page 11: Présentation du retour d'expérience sur Git

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

Page 12: Présentation du retour d'expérience sur Git

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

Page 13: Présentation du retour d'expérience sur Git

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

Page 14: Présentation du retour d'expérience sur Git

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

Page 15: Présentation du retour d'expérience sur Git

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

Page 16: Présentation du retour d'expérience sur Git

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.

Page 17: Présentation du retour d'expérience sur Git

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

Page 18: Présentation du retour d'expérience sur Git

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

Page 19: Présentation du retour d'expérience sur Git

Concepts avancés

Concepts Avancés

Page 20: Présentation du retour d'expérience sur Git

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...

Page 21: Présentation du retour d'expérience sur Git

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 !

Page 22: Présentation du retour d'expérience sur Git

Rebase (1)

• git rebase master feature1

A B C D E

X Y

F

feature1

master HEAD

Page 23: Présentation du retour d'expérience sur Git

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'

Page 24: Présentation du retour d'expérience sur Git

Workflows

Workflows

Page 25: Présentation du retour d'expérience sur Git

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 »

Page 26: Présentation du retour d'expérience sur Git

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• ...

Page 27: Présentation du retour d'expérience sur Git

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

Page 28: Présentation du retour d'expérience sur Git

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

Page 29: Présentation du retour d'expérience sur Git

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

Page 30: Présentation du retour d'expérience sur Git

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é

Page 31: Présentation du retour d'expérience sur Git

Workflows

• Git s'adapte à presque n'importe quel workflow• La principale difficulté de Git : trouver le bon workflow pour

votre organisation !

Page 32: Présentation du retour d'expérience sur Git

Outils

Page 33: Présentation du retour d'expérience sur Git

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

Page 34: Présentation du retour d'expérience sur Git

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

Page 35: Présentation du retour d'expérience sur Git

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

Page 36: Présentation du retour d'expérience sur Git

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

Page 37: Présentation du retour d'expérience sur Git

Questions ?

Page 38: Présentation du retour d'expérience sur Git

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