Les bases de git

2 688 vues

Publié le

Découvrez les principes et fonctionnalités essentielles de git. Soyez prêts à travailler en 3 heures.
La dernière version est disponible en téléchargement direct à cette adresse : http://giant-teapot.org/uploads/tutorials/git_tutorial.pdf

Diaporama pour la formation git réalisée pour l'association Atilla, septembre 2012.

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

Aucun téléchargement
Vues
Nombre de vues
2 688
Sur SlideShare
0
Issues des intégrations
0
Intégrations
30
Actions
Partages
0
Téléchargements
120
Commentaires
0
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Les bases de git

  1. 1. git pour les novices Pierre Sudron Association Atilla 10 aoˆut 2013
  2. 2. git est un syst`eme de gestion de sources • g´erer l’´evolution d’un code • partager efficacement son travail en ´equipe • garder un historique de l’´evolution d’un projet • travailler en parall`ele 2 / 96
  3. 3. Autres syst`emes existants • Subversion (svn) • Mercurial (Hg) • Bazaar (bzr) • autres syst`emes propri´etaires 3 / 96
  4. 4. Plus particuli`erement sur git • cr´e´e pour le noyau Linux • d´evelopp´e par Junio Hamano • distribu´e et tr`es flexible • adoption rapide et massive depuis 2005 4 / 96
  5. 5. Qu’est-ce que git peut m’apporter ? • suivi pr´ecis de l’avancement d’un projet • souplesse dans l’´evolution • facilit´e de mise en commun 5 / 96
  6. 6. Int´egration douloureuse : un projet qui fait plouf Bob et Bob travaillent sur un projet et se r´epartissent les tˆaches 6 / 96
  7. 7. `A deux jours du livrable... Bob a bien avanc´e sur sa partie 7 / 96
  8. 8. Bob pas tellement mais il a fait quelque chose au moins 8 / 96
  9. 9. C’est l’heure de mettre en commun ! Et quelle surprise, ¸ca marche pas ! 9 / 96
  10. 10. Et `a 24 heures du rendu, c’est un peu cuit... 10 / 96
  11. 11. L’int´egration progressive • git incite `a mettre en commun tr`es r´eguli`erement • en cas d’ennui, il est possible de revenir `a la derni`ere version fonctionnelle • de l`a, il est facile de voir les modifications ult´erieures et isoler le code en cause 11 / 96
  12. 12. De quoi ai-je besoin ? Ouvrir un terminal (mais sous Linux, hein...) 12 / 96
  13. 13. Principes de fonctionnement En local, on travaille avec 3 ´el´ements : dossier de travail fichiers index´es d´epˆot local 13 / 96
  14. 14. Contenu d’un d´epˆot git Succession de commits Un commit est un jeu de modifications, c’est l’atome de git. 14 / 96
  15. 15. Mise en commun Synchronisation entre le d´epˆot local et un d´epˆot distant 15 / 96
  16. 16. Partie 1 : C’est un voyage qu’il faut commencer seul versionnage d’un simple fichier texte 16 / 96
  17. 17. Configuration de git : qui suis-je ? git retrace l’´evolution du projet ainsi : qui a fait quoi, et quand Pour d´efinir qui est l’utilisateur : g i t c o n f i g −−g l o b a l user . name ” Votre nom” g i t c o n f i g −−g l o b a l user . email ” r o o t @ a t i l l a . org ” Pour activer la couleur dans le terminal : g i t c o n f i g −−g l o b a l c o l o r . ui auto 17 / 96
  18. 18. Pr´eparer le projet Se placer dans le dossier de travail (le cr´eer si besoin) : mkdir ˜/ f o r m a t i o n g i t cd ˜/ f o r m a t i o n g i t / Initialiser git dans ce r´epertoire : g i t i n i t 18 / 96
  19. 19. Comment ¸ca se pr´esente r´epertoire de travail : vide fichiers index´es : vide d´epˆot local : initialis´e et vide 19 / 96
  20. 20. Cr´eer un fichier Sans changer de dossier, cr´eer un fichier README avec le contenu suivant : Formation g i t Enregistrer le fichier 20 / 96
  21. 21. Comment ¸ca se pr´esente r´epertoire de travail : README fichiers index´es : vide d´epˆot local : initialis´e et vide 21 / 96
  22. 22. Constater les changements avec git status g i t s t a t u s README n’est pas index´e, on nous propose d’utiliser git add 22 / 96
  23. 23. Indexer un fichier avec git add g i t add README 23 / 96
  24. 24. Comment ¸ca se pr´esente r´epertoire de travail : README fichiers index´es : README (nouveau fichier) d´epˆot local : initialis´e et vide 24 / 96
  25. 25. Constater les changements avec git status g i t s t a t u s README est dans l’index en tant que nouveau fichier 25 / 96
  26. 26. Notre premier git commit On va mettre `a jour le d´epˆot local et laisser une trace de la cr´eation du fichier README g i t commit −m ” Ajout du f i c h i e r README” Tout commit est d´ecrit par un message, il doit ˆetre : • pr´ecis • concis 26 / 96
  27. 27. Comment ¸ca se pr´esente r´epertoire de travail : README fichiers index´es : vide d´epˆot local : commit #1 (v´erifier avec git status) 27 / 96
  28. 28. Historique des commits 28 / 96
  29. 29. Poursuivons le travail... Ajouter une ligne `a la fin du fichier README : Formation g i t Avec l ’ a s s o c i a t i o n A t i l l a Enregistrer le fichier 29 / 96
  30. 30. Comment ¸ca se pr´esente r´epertoire de travail : README (modifi´e) fichiers index´es : vide d´epˆot local : commit #1 30 / 96
  31. 31. Constater les changements avec git status g i t s t a t u s Les fichiers modifi´es sont d´etect´es ; on propose de les indexer avec git add 31 / 96
  32. 32. Indexation du fichier modifi´e g i t add README r´epertoire de travail : README (modifi´e) fichiers index´es : README (modifi´e) d´epˆot local : commit #1 (v´erifier avec git status) 32 / 96
  33. 33. Validation des changements g i t commit −m ” M o d i f i c a t i o n du f i c h i e r README” r´epertoire de travail : README (modifi´e) fichiers index´es : vide d´epˆot local : commit #1, commit #2 (v´erifier avec git status) 33 / 96
  34. 34. Historique des commits 34 / 96
  35. 35. Historique des commits g i t log 35 / 96
  36. 36. Export vers un d´epˆot git en ligne Nous utiliserons une instance GitLab disponible `a l’adresse : http://gitlab.etude.eisti.fr/ Il existe de nombreux sites permettant d’h´eberger vos projets git, dont : • GitHub • Gitorious 36 / 96
  37. 37. Se connecter et ajuster son profil sur GitLab 37 / 96
  38. 38. Cr´eer un projet sur GitLab 38 / 96
  39. 39. Cr´eer une cl´e SSH Ouvrez un nouveau terminal : ssh−keygen −t rsa −C ” e m a i l @ t r o l l . com” La cl´e SSH permet : • de vous identifier formellement • de crypter de transfert de code entre vous et le serveur 39 / 96
  40. 40. Indiquer la cl´e publique `a GitLab Le RSA est un cryptage asym´etrique, et cr´e´e un jeu de deux cl´es • une cl´e priv´ee • une cl´e publique Pour afficher la cl´e publique : cat . ssh / i d r s a . pub • ajouter la cl´e publique au trousseau GitLab (vous pouvez fermer le second terminal et revenir au pr´ec´edent) 40 / 96
  41. 41. Ajouter le d´epˆot dans votre projet g i t remote add o r i g i n [ ad r e ss e du depot ] • origin : nom donn´e au serveur distant par convention Vous trouverez l’adresse de votre d´epˆot sur sa page d’accueil. 41 / 96
  42. 42. Mettre le projet en ligne ! g i t push −u o r i g i n master • origin : nom donn´e au serveur distant par convention • master : nom donn´e au d´epˆot local par d´efaut master origin 42 / 96
  43. 43. Voir le r´esultat sur GitLab Il ne reste plus qu’`a constater le r´esultat avec satisfaction ! 43 / 96
  44. 44. avant de continuer... la Pause ! 44 / 96
  45. 45. Partie 2 : Travailler `a plusieurs d´ecouverte des fonctionnalit´es de partage 45 / 96
  46. 46. De quoi ai-je besoin ? logiciel Meld prenez un moment pour l’installer avant de continuer... 46 / 96
  47. 47. Acc`es aux projets Un projet n’est visible que pour les membres de l’´equipe en charge. Les ´equipes comportent diff´erents niveaux de responsabilit´e : • Master • Developer • Reporter • Guest 47 / 96
  48. 48. Cloner un d´epˆot existant • r´ecup´erer l’adresse du d´epˆot • cloner le d´epˆot (cette op´eration cr´e´e le r´epertoire du projet) g i t clone [ a d re s s e ] 48 / 96
  49. 49. Cloner un d´epˆot existant Le projet Participants formation contient un seul fichier dans lequel chacun va ajouter son nom. • assurez-vous que vous ˆetes inscrit au projet comme d´eveloppeur • clonez le d´epˆot sur votre machine • tout le monde doit ˆetre `a la mˆeme version 49 / 96
  50. 50. Allons y... • ajoutez votre nom `a la fin du fichier • faites un commit • essayer de push... oui, ¸ca veut dire PA - TA - TRAS ! 50 / 96
  51. 51. Qu’est-ce que j’ai fait pour m´eriter ¸ca ? Si il y a un mot `a retenir dans le message d’erreur : non-fast-forward signifie que vous ´ecraseriez les commits d’autres si git vous laissait push. 51 / 96
  52. 52. Qu’est-ce qui s’est pass´e ? Un fichier a ´et´e modifi´e et mis en ligne depuis votre dernier pull. 52 / 96
  53. 53. Comment s’en sortir ? On souhaiterait appliquer nos commits `a la suite de ceux des autres. C’est une op´eration de rebase. 53 / 96
  54. 54. Chacun son tour • r´ecup´erer les derniers commits en ligne et rebaser nos commits `a partir de l`a g i t p u l l −−rebase • cette op´eration peut soulever un conflit bloquant car plusieurs personnes ont modifi´e le mˆeme fichier 54 / 96
  55. 55. Les conflits Un conflit a lieu quand on cherche `a mettre en commun deux fichiers dont les mˆemes sections ont ´et´e modifi´ees par deux personnes. 55 / 96
  56. 56. R´esoudre un conflit bloquant un rebase Le message d’erreur du "pull –rebase nous indique les deux ´etapes `a suivre : • corriger les conflits dans les fichiers continus • achever et valider le rebase avec g i t rebase −−continue 56 / 96
  57. 57. G´erer les conflits avec une interface Pour r´esoudre le conflit nous allons utiliser l’ONU Meld. Notez qu’il existe ´enorm´ement de logiciels ´equivalents. • d´efinir Meld comme outil de gestion de conflit g i t c o n f i g −−g l o b a l merge . t o o l meld • commencer `a g´erer le conflit g i t mergetool 57 / 96
  58. 58. G´erer des conflits avec une interface Meld (comme ses ´equivalents) pr´esente sur trois colonnes, trois version du fichier : • locale `a gauche : votre derni`ere version de la branche r´eceptrice • remote `a droite : la derni`ere version de la branche `a fusionner • origin au centre : la derni`ere version commune aux deux branches Dans la pratique, on enregistrera le r´esultat voulu dans la colonne centrale, c’est `a dire sur origin. 58 / 96
  59. 59. Finaliser la r´esolution de conflits mergetool cr´e´e un fichier de sauvegarde <fichier>.orig, on peut les supprimer une fois la session mergetool termin´ee Il reste `a teminer l’op´eration de rebase g i t rebase −−continue 59 / 96
  60. 60. Partager son travail Il n’y a plus de probl`eme de fast forward : on peut d´esormais push. 60 / 96
  61. 61. Partie 3 : Comment ¸ca va vieille branche ? d´evelopper en parall`ele 61 / 96
  62. 62. De quoi ai-je besoin ? logiciel Meld 62 / 96
  63. 63. C’est l’histoire d’un prof... Jean-Paul a fini de r´ediger le poly du cours de cette ann´ee, en LATEX bien entendu ! Il souhaite continuer `a rajouter des parties pour l’ann´ee suivante tout en gardant une version de cette ann´ee afin de corriger les coquilles que ses ´el`eves lui signalent. Mais comme Jean Paul n’est pas tr`es organis´e, nous allons l’aider `a mieux g´erer son texte de cours avec git et les branches ! 63 / 96
  64. 64. Le principe des branches Fourche dans le processus de d´eveloppement du projet. Une branche d´emarre `a partir d’un commit donn´e. 64 / 96
  65. 65. Le principe des branches Nous allons cr´eer une branche d´edi´ee aux corrections des fautes d’orthographe sur une branche partant de la version distribu´ee du poly. 65 / 96
  66. 66. Pr´eparation du projet • cr´eer un dossier formation git branches • d´eplacer le fichier cours.tex fourni dans ce dossier cd f o r m a t i o n g i t b r a n c h e s g i t i n i t g i t g i t add cours . tex g i t commit −m ” Version r e n t r e e ” 66 / 96
  67. 67. Cr´eer une branche La branche est cr´e´ee `a partir du dernier commit local (HEAD). g i t branch r e n t r e e s u i v a n t e Pour lister les branches existantes : g i t branch 67 / 96
  68. 68. Sauter de branche en branche g i t checkout r e n t r e e s u i v a n t e La commande git branch donne le r´esultat suivant : 68 / 96
  69. 69. Ajouter un nouveau paragraphe pour la rentr´ee prochaine Jean-Paul, studieux comme toujours, ne tarde pas `a rajouter du contenu pour l’ann´ee prochaine. ´Editer le fichier cours.tex en ajoutant une ligne `a la fin. Sauvegarder, fermer l’´editeur de texte et commiter. g i t add cours . tex g i t commit −m ”Nouveau paragraphe ” 69 / 96
  70. 70. Revenir sur la branche principale pour une correction Mince ! On a signal´e la pr´esence de fautes d’orthographe dans le poly de cette ann´ee. Retourner sur la branche principale g i t checkout master Ouvrir le fichier cours.tex avec un ´editeur. V´erifier qu’il s’agit bien de la version de cette rentr´ee. Corriger les fautes, enregistrer, commiter. 70 / 96
  71. 71. Visualiser les commits selon leur branche g i t log −−o n e l i n e −−graph −−a l l le log se lit de bas en haut 71 / 96
  72. 72. Fusionner deux branches La rentr´ee suivante est arriv´ee (¸ca passe vite), et Jean-Paul voudrait int´egrer ses nouvelles parties tout en conservant les corrections faites en cours d’ann´ee. 72 / 96
  73. 73. Fusionner deux branches Se placer dans la branche qui va ”int´egrer” les commits de l’autre g i t checkout master R´ealiser la fusion g i t merge r e n t r e e s u i v a n t e ... et l`a : Merge conflict ! Certains paragraphes ont un contenu diff´erent, il va falloir g´erer ¸ca `a la main. 73 / 96
  74. 74. G´erer un merge conflict Ouvrir le fichier cours.tex. git a modifi´e son contenu pour mettre en ´evidence le conflit. <<<<<<< HEAD ancien contenu ======= nouveau contenu >>>>>>> r e n t r e e s u i v a n t e git status permet de voir sur quels fichiers il existe des conflits : 74 / 96
  75. 75. G´erer un merge conflict La d´emarche `a suivre pour r´esoudre le conflit : • corriger les conflits dans chaque fichier concern´e • v´erifier que tous les conflits sont corrig´es avec git status • indexer (git add) tous les fichiers modifi´es dans la manipulation • commiter (git commit), on appelle ¸ca un ’merge commit’ 75 / 96
  76. 76. Corriger des conflits dans un fichier plus facilement Il est assez compliqu´e de s’en sortir avec ¸ca : <<<<<<< HEAD ancien contenu ======= nouveau contenu >>>>>>> r e n t r e e s u i v a n t e On va utiliser un outil graphique : Meld (il existe ´enorm´ement d’´equivalents) 76 / 96
  77. 77. Corriger des conflits dans un fichier plus facilement g i t mergetool mergetool va lancer Meld (ou ´equivalent) pour chaque fichier o`u il y a un conflit. 77 / 96
  78. 78. Utiliser Meld Meld (et ´equivalents) pr´esente sur trois colonnes, trois version du fichier : • locale `a gauche : votre derni`ere version de la branche r´eceptrice • remote `a droite : la derni`ere version de la branche `a fusionner • origin au centre : la derni`ere version commune aux deux branches Dans la pratique, on enregistrera le r´esultat voulu dans la colonne centrale, c’est `a dire sur origin. 78 / 96
  79. 79. Finaliser la r´esolution de conflits mergetool cr´e´e un fichier de sauvegarde <fichier>.orig, on peut les supprimer une fois la session mergetool termin´ee Il faut faire un merge commit : valider la r´esolution des conflits au sein d’un commit g i t s t a t u s g i t add cours . tex g i t commit −m ”Merge dans master de r e n t r e e s u i v a n t e ” 79 / 96
  80. 80. Mettre en ligne votre branche g i t push o r i g i n [ ma branche ] ma branche origin 80 / 96
  81. 81. Terminer une branche g i t branch −d r e n t r e e s u i v a n t e Il possible de terminer seulement une branche qui a ´et´e merge et n’a pas ´et´e modifi´ee depuis. Pour forcer la suppression d’une branche : g i t branch −D r e n t r e e s u i v a n t e 81 / 96
  82. 82. Partie 4 : remonter le temps C’est moi Doc ! Je suis de retour du futur... 82 / 96
  83. 83. Acc`es `a un commit • HEAD : dernier commit de la branche courante • nom branche/HEAD : dernier commit de la branche nom branche • donner le nom d’une branche revient `a pointer vers le dernier commit de cette branche Il est possible de se ”d´eplacer” relativement `a un commit • HEADˆ : un commit avant HEAD • HEADˆˆ : deux commits avant HEAD • HEAD˜42 : quarante deux commits avant HEAD 83 / 96
  84. 84. Acc`es `a un commit • trouver l’identifiant court d’un commit g i t log −−o n e l i n e • master@{20/09/2012} : prendre un commit `a une date donn´ee 84 / 96
  85. 85. Voyager dans le temps • mettre un fichier tel qu’il ´etait `a un commit donn´e g i t checkout [ nom commit ] [ f i c h i e r ] Cette manipulation modifie directement le fichier dans votre r´epertoire de travail. • remettre un fichier ”en l’´etat” g i t checkout HEAD [ f i c h i e r ] 85 / 96
  86. 86. Annexe 1 : Quelques conseils tout va bien se passer... 86 / 96
  87. 87. Commitez bien, commitez souvent • segmentez les tˆaches, faites un commit d`es que possible • ne commitez pas sciemment un code qui ne marche pas 87 / 96
  88. 88. Les branches c’est bon, mangez-en ! • s´eparez les tˆaches ind´ependantes • n’h´esitez pas `a faire des exp´erimentations dans une branche d´edi´ee • gardez une branche ”stable” `a tout moment de votre d´eveloppement 88 / 96
  89. 89. Jouez collectif • organisez-vous et concertez-vous avec vos partenaires • donnez des titres compr´ehensibles `a vos commits • suivez les avanc´ees des autres, donnez votre avis • construisez votre cycle de d´eveloppement intelligemment : en fonction de la taille et la nature de votre ´equipe, vos deadlines, etc. 89 / 96
  90. 90. Annexe 2 : Guide de survie Comme Rambo, mais en mieux. 90 / 96
  91. 91. Au d´ebut de la journ´ee de travail • je commence toujours par r´ecup´erer le travail des autres g i t p u l l • je v´erifie sur quelle branche je me trouve g i t branch g i t checkout 91 / 96
  92. 92. Quand je code • j’ajoute mes fichier modifi´es `a l’index g i t add • je v´erifie mes modifications suivies g i t s t a t u s • je valide mes changements dans un commit g i t commit 92 / 96
  93. 93. Partager mon travail • je publie mon travail au moins en fin de journ´ee g i t push • en cas de fast-forward, j’applique mes modifications apr`es celles des autres g i t p u l l −−rebase • en cas de conflit, je fait les modications `a la main g i t mergetool g i t rebase −−continue 93 / 96
  94. 94. Au secours, rien ne va plus ! • faire attention `a ce qu’on fait pour ´eviter les ennuis inutiles • DON’T PANIC ! • prendre le temps de lire les messages d’erreur de git (ils donnent souvent la solution) • il existe de tr`es nombreuses ressources sur le net 94 / 96
  95. 95. Des questions ? Ne mourrons pas idiots. 95 / 96
  96. 96. Merci de votre participation et `a une prochaine fois ! 96 / 96

×