Open-REX - Git 8 juillet 2010 Antoine Büsch
Licence• Cette présentation vous est fournie sous licence Creative Commons  Attribution Share Alike• Vous êtes libres :   ...
Sommaire•   Introduction•   Concepts•   Workflows•   Outils
Présentation• Daprès le Merriam-Webster :   – a foolish or worthless person• Cest aussi un gestionnaire de versions :   – ...
Historique• Créé en avril 2005 par Linus Torvalds pour le  développement du noyau Linux :   – avant 2002 :    patches and ...
Historique• Démarrage du projet Git pour remplacer BitKeeper :   –   3 avril 2005      début du projet   –   6 avril 2005 ...
Caractéristiques• Principales caractéristiques de Git :   –   Supporte les historiques non-linéaires   –   Supporte les dé...
La Philosophie de GitFaire l’inverse de CVS (ou SVN)
ConceptsConcepts
Dépôt (Repository)• Git est un gestionnaire de version décentralisé   – Chaque dépôt est techniquement égal aux autres   –...
Anatomie dun dépôt Git• Le répertoire .git   – Uniquement à la racine du projet : ne pollue pas tous les     répertoires  ...
Structures de données• Git possède 3 structures de données principales :   1. La base de donnée : contient le graphe des c...
Commits• Git maintient un graphe orienté de commits.• Chaque commit représente l’état du contenu des fichiers à  un instan...
Références• Une référence est un simple pointeur vers un commit. Peut  être :   – un simple label (tag)   – une référence ...
Références• Il existe une référence particulière : HEAD   – Pointe toujours vers la référence de la branche courante   – L...
Branches• Créer une branche = créer une référence vers un commit   – Extrement léger   – Instantané   – Facile de changer ...
Merges• Contrairement à CVS/SVN, lhistorique dans Git nest pas  linéaire : les commits sont organisés en graphe orienté   ...
Merge (exemple)• git merge feature1             X   Y         feature1 A   B   C   D   E     F          master            ...
Concepts avancésConcepts Avancés
Réécriture dhistorique• Git vous donne un dépôt à part entière, mais également  les outils pour réécrire une partie de lhi...
Rebasing• Rebasing : prend tous les commits dune branche à partir  dun certain point, et réapplique les changements  intro...
Rebase (1)• git rebase master feature1             X   Y       feature1 A   B   C   D   E   F          master   HEAD
Rebase (2)• Après rebase : même état que si la branche feature1 avait  été créée à partir du commit F                  X  ...
WorkflowsWorkflows
Workflows• Git est un outil puissant, flexible, mais qui nimpose pas de  workflow particulier : sadapte à votre besoin   –...
Utilisation solitaire• Parfaitement adapté pour des projets personnels   – Création dun dépôt instantanée   – Pas besoin d...
Utilisation en environnement mixte• Des passerelles existent entre Git et dautres VCS (CVS,  SVN...)• Le premier « clone »...
Utilisation centralisée• Même si Git est un DVCS, il est possible de lutiliser de  manière centralisée• Utilisation couran...
Utilisation centralisée                            avec intégrateur• Variante du workflow précédent : une seul personne es...
Organisation par équipe• Chaque équipe travaille indépendement• Un intégrateur intègre les différentes fonctionnalités et ...
Workflows• Git sadapte à presque nimporte quel workflow• La principale difficulté de Git : trouver le bon workflow pour  v...
Outils
Outils• La ligne de commande !   – Reste le plus puissant (pemet le rebasing interactif) et souvent le     plus rapide• In...
Outils• Plugin maven   – Implémentation du plugin SCM pour Git• Serveurs de CI   – Plugins pour Hudson, Bamboo...• Interfa...
Outils• Gerrit : système de revue de code, initié par Google   – Utilisé pour le developpement dAndroid   – Fonctionne com...
Conclusion• Essayez Git !   – Pas si difficile que ça avec la bonne approche → ne pas se dire     que ça marche comme SVN ...
Questions ?
Références• http://git-scm.com/   – Site officiel• http://progit.org/book/   – Très bon livre gratuit en ligne• http://git...
Prochain SlideShare
Chargement dans…5
×

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

2 442 vues

Publié le

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

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 442
Sur SlideShare
0
Issues des intégrations
0
Intégrations
113
Actions
Partages
0
Téléchargements
52
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. Open-REX - Git 8 juillet 2010 Antoine Büsch
  2. 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 dune manière qui suggèrerait quils 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 lautorisation du titulaire des droits sur cette œuvre. – Rien dans ce contrat ne diminue ou ne restreint le droit moral de lauteur ou des auteurs.
  3. 3. Sommaire• Introduction• Concepts• Workflows• Outils
  4. 4. Présentation• Daprès le Merriam-Webster : – a foolish or worthless person• Cest aussi un gestionnaire de versions : – distribué – open-source – rapide• Même catégorie que Bazaar, Mercurial, Monotone, BitKeeper...
  5. 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. 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. 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. 8. La Philosophie de GitFaire l’inverse de CVS (ou SVN)
  9. 9. ConceptsConcepts
  10. 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 lintégralité de lhistorique du projet • On ne fait pas un checkout dun projet, on fait un clone – La plupart des opérations se font en local, sans accès réseau • Commit • Branches/merges • Consultation de lhistorique – Les dépôts peuvent communiquer entre eux et séchanger des commits
  11. 11. Anatomie dun 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 lespace de travail : les fichiers de lutilisateur dans une version donnée
  12. 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. Lindex : espace temporaire où sont préparés les commits 3. Lespace de travail : larbre des fichiers dans une version donnée BDD Index Espace de travail Commit add / rm checkout
  13. 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. 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 lutilisateur – Les références « remotes » : non modifiables directement par lutilisateur
  15. 15. Références• Il existe une référence particulière : HEAD – Pointe toujours vers la référence de la branche courante – Lorsquon commite, cest 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. 16. Branches• Créer une branche = créer une référence vers un commit – Extrement léger – Instantané – Facile de changer dune branche à une autre• Les branches sont faciles à merger• Git encourage lutilisation des branches – Une branche par feature / bug-fix / etc.
  17. 17. Merges• Contrairement à CVS/SVN, lhistorique dans Git nest 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 lancêtre commun, et sait donc quels commits considérer pour le merge, – Les commits des 2 branches font partie intégrante de lhistorique 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 dinformation dhistorique – Au final : merges plus faciles, moins de conflits
  18. 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. 19. Concepts avancésConcepts Avancés
  20. 20. Réécriture dhistorique• Git vous donne un dépôt à part entière, mais également les outils pour réécrire une partie de lhistorique – Possibilité de revenir en arrière (Undo), pour éliminer les n derniers commits – Possibilité de corriger le dernier commit : oubli dun fichier, commentaire incomplet... – Possibilité de faire un « rebase » dune 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. 21. Rebasing• Rebasing : prend tous les commits dune branche à partir dun certain point, et réapplique les changements introduits, dans lordre, à 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. 22. Rebase (1)• git rebase master feature1 X Y feature1 A B C D E F master HEAD
  23. 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. 24. WorkflowsWorkflows
  25. 25. Workflows• Git est un outil puissant, flexible, mais qui nimpose pas de workflow particulier : sadapte à 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. 26. Utilisation solitaire• Parfaitement adapté pour des projets personnels – Création dun dépôt instantanée – Pas besoin de serveur – Tous les avantages dune gestion de version : • Retours en arrière • Branches • ...
  27. 27. Utilisation en environnement mixte• Des passerelles existent entre Git et dautres VCS (CVS, SVN...)• Le premier « clone » récupère lintégralité de lhistorique : 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 denvoyer vers SVN des commits de merge – Utilisation fréquente du rebasing pour garder un historique plus linéaire
  28. 28. Utilisation centralisée• Même si Git est un DVCS, il est possible de lutiliser de manière centralisée• Utilisation courante en entreprise Dépôt partagé Dev A Dev B Dev C
  29. 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. 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. 31. Workflows• Git sadapte à presque nimporte quel workflow• La principale difficulté de Git : trouver le bon workflow pour votre organisation !
  32. 32. Outils
  33. 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. 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 dACL – Permet de définir les permissions pour chaque utilisateur au niveau dépôt ou branche
  35. 35. Outils• Gerrit : système de revue de code, initié par Google – Utilisé pour le developpement dAndroid – 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. 36. Conclusion• Essayez Git ! – Pas si difficile que ça avec la bonne approche → ne pas se dire que ça marche comme SVN ! – Ce nest quun 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. 37. Questions ?
  38. 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 dintegration continue sans serveur• http://www.kernel.org/pub/software/scm/git/docs/git-svn.html – Documentation de git-svn

×