Téléchargé parquicky_osm
PDF, PPTX105 vues

Git pratique

Le document présente un guide complet sur l'utilisation de Git, un gestionnaire de version, couvrant des thèmes basiques et avancés. Il aborde la configuration, la création de dépôts, la gestion des branches, ainsi que des commandes spécifiques pour manipuler l'historique des versions. Enfin, il met en lumière les différences entre le travail local et les interactions avec des dépôts distants.

Intégrer la présentation

Télécharger en tant que PDF, PPTX
1 / 143
2 / 143
3 / 143
4 / 143
5 / 143
6 / 143
7 / 143
8 / 143
9 / 143
10 / 143
11 / 143
12 / 143
13 / 143
14 / 143
15 / 143
16 / 143
17 / 143
18 / 143
19 / 143
20 / 143
21 / 143
22 / 143
23 / 143
24 / 143
25 / 143
26 / 143
27 / 143
28 / 143
29 / 143
30 / 143
31 / 143
32 / 143
33 / 143
34 / 143
35 / 143
36 / 143
37 / 143
38 / 143
39 / 143
40 / 143
41 / 143
42 / 143
43 / 143
44 / 143
45 / 143
46 / 143
47 / 143
48 / 143
49 / 143
50 / 143
51 / 143
52 / 143
53 / 143
54 / 143
55 / 143
56 / 143
57 / 143
58 / 143
59 / 143
60 / 143
61 / 143
62 / 143
63 / 143
64 / 143
65 / 143
66 / 143
67 / 143
68 / 143
69 / 143
70 / 143
71 / 143
72 / 143
73 / 143
74 / 143
75 / 143
76 / 143
77 / 143
78 / 143
79 / 143
80 / 143
81 / 143
82 / 143
83 / 143
84 / 143
85 / 143
86 / 143
87 / 143
88 / 143
89 / 143
90 / 143
91 / 143
92 / 143
93 / 143
94 / 143
95 / 143
96 / 143
97 / 143
98 / 143
99 / 143
100 / 143
101 / 143
102 / 143
103 / 143
104 / 143
105 / 143
106 / 143
107 / 143
108 / 143
109 / 143
110 / 143
111 / 143
112 / 143
113 / 143
114 / 143
115 / 143
116 / 143
117 / 143
118 / 143
119 / 143
120 / 143
121 / 143
122 / 143
123 / 143
124 / 143
125 / 143
126 / 143
127 / 143
128 / 143
129 / 143
130 / 143
131 / 143
132 / 143
133 / 143
134 / 143
135 / 143
136 / 143
137 / 143
138 / 143
139 / 143
140 / 143
141 / 143
142 / 143
143 / 143
11 Decembre 2017 – LOGal Laboratoire Ouvert Grenoblois - Julien Thevenon Git Pratique CC-by-SA
Plan • Introduction • Git basique • Git avancé • Git en réseau • Méthodologie de branches • Dépots multiples
INTRODUCTION
Introduction • Gestionnaire de version – Garde un historique du projet et permet de naviguer dans celui-ci • Pourquoi? – Un projet c'est vivant et ca évolue – Besoin de revenir en arrière • correction de bug dans une version précédente • erreur dans le dévelopment – Plusieurs fonctionnalités à développer en parallèle – Pour travailler à plusieurs • nécessiter de se synchroniser
Introduction • Historique – Création en 2005 par Linus Torvald • Spécifications – Etre rapide – Design simple – Etre efficace pour le développement en parallèle par de nombreuses personnes – Etre entièrement distribué – Scalable en terme de rapidité et de place
GIT BASIQUE
Git et les graphes • L'historique du projet est un graphe orienté • Les commandes git agissent sur le graphe
Configuration de Git • Permet de spécifier le nom de l utilisateur – $ git config --global user.name "John Doe" • Son adresse mail – $ git config --global user.email johndoe@example.com • L'éditeur de texte à utiliser – $ git config --global core.editor emacs
Configuration de Git • Lister les clefs de configuration – $ git config -–list • Connaitre la valeur d'une clef – $ git config user.name • Sur les version récentes pour savoir où est définie la clef – $git config user.name -–show-origin
Configuration de Git • Configuration bas niveau – dans /etc/gitconfig – modifiable via git config –system • Configuration utilisateur – ~/.gitconfig ou ~/.config/git/config – modifiable via git config –global • Possibilité d'avoir une configuration locale au dépot
Création d'un dépot GIT • A partir de rien – Dans un répertoire exécutez la commande – $ git init • A partir d'un dépot existant – $ git clone <URI> [nom du dépot]
Git status • Donne l'état de votre dépot git – Branche sur laquelle vous êtes
Git status • Donne l'état de votre dépot git – Fichiers prêts à être commités
Git status • Donne l'état de votre dépot git – Fichiers en cours de modification
Git status • Donne l'état de votre dépot git – Fichiers non versionnés
Git status • Donne l'état de votre dépot git – Commandes à effectuer sur les fichiers
Git status • Donne l'état de votre dépot git – Eventuellement opérations en cours • A utiliser sans moderation !
Mécanisme de staging • Dans subversion • Dans Git Working Directory Repository Working Directory RepositoryStaging Area svn add / svn commit svn checkout
Mécanisme de staging • Inconvénients – Etape supplémentaire – Perturbe les personnes venant d'autres VCS • Avantages – Apporte beaucoup de flexibilité – Permet de préparer les commits en plusieurs fois – Permet des fonctionnalités avancées – Certaines commandes équivalentes à SVN
Versionner un fichier Working Directory Staging Area Repository v1
Versionner un fichier • $git add LICENCE Working Directory Staging Area Repository v1
Versionner un fichier Working Directory Staging Area Repository v1 v1
Versionner un fichier • $git commit Working Directory Staging Area Repository v1 v1
Versionner un fichier Working Directory Staging Area Repository v1 v1
Modifier un fichier Working Directory Staging Area Repository v1v2
Modifier un fichier Working Directory Staging Area Repository v1v2 • $git add LICENCE
Modifier un fichier Working Directory Staging Area Repository v1v2 v2
Modifier un fichier Working Directory Staging Area Repository v1v2 • $git commit v2
Modifier un fichier Working Directory Staging Area Repository v2 v2
Annuler une modification locale Working Directory Staging Area Repository v1v2
Annuler une modification locale Working Directory Staging Area Repository v1v2 • $git checkout -- LICENSE
Annuler une modification locale Working Directory Staging Area Repository v1 v1
Unstager une modification Working Directory Staging Area Repository v1v2 v2
Unstager une modification Working Directory Staging Area Repository v1v2 v2 • $git reset HEAD LICENSE
Unstager une modification Working Directory Staging Area Repository v1v2
Renommage/Suppression de fichier • Fichiers non versionnés – mv / rm • Fichiers versionnés – git mv / git rm – Ne pas oublier de faire git add + git commit !
Visualiser les diférences Working Directory Staging Area Repository v1v2 vB vA
Visualiser les diférences Working Directory Staging Area Repository v1v2 vB • $git diff vA
Visualiser les diférences Working Directory Staging Area Repository v1v2 vB • $git add fichier2.txt vA
Visualiser les diférences Working Directory Staging Area Repository v1v2 vB • $ git diff $ git diff --cached vA
Visualiser les diférences Working Directory Staging Area Repository v1v2 vB • $ git diff HEAD vA
Les Tags • Utilisés pour marquer une version, une étape • Tag simple – git tag <nom du tag> <objet à tagguer> • Tag annoté – git tag -a <nom du tag> <objet à tagguer> – Associe un message au tag, la date et le nom de celui qui tag • Lister les tags – git tag -l • Supprimer un tag – git tag -d <nom du tag>
Ignorer des fichiers • Par exemple – les fichiers temporaires – Backups – Build – ...
Ignorer des fichiers • Création d un fichier .gitignore – Placé à la racine du projet – Défini des patterns de nom de fichiers à ignorer – A versionner comme n'importe quel fichier
Visualiser l historique • $ git log $ gitk --all
Branches • Divergence du développement principal – Permet d'avoir du développement parallèle • Dans les CVS souvent – Peu performant, lourd – Complexe à manipuler • Dans Git – Rapide, léger – Facile à manipuler • Git encourage l'utilisation des branches
Gestion des branches • Lister les branches – git branch • Création d'une branch – git branch<nom de la branche> • Suppression d'une branche fusionnée – git branch -d <nom de la branche> • Suppression d'une branche non fusionnée – git branch -D <nom de la branche> • Renommage d'une branche – git branch -m <nom> <nouveau nom>
Navigation dans les branches • L'étiquette HEAD – indique ou l'on travaille dans l'arbre – Par défaut HEAD est sur la branche master
Navigation dans les branches • Changement de branche – Déplacement de HEAD sur une autre branche – $ git checkout <nom de branche>
Navigation dans les branches • Création d'une branche et changement de branche – $ git branch <nom de branche> – $ git checkout <nom de branche> • Ou en une seule commande – $git checkout -b <nom de branche>
Fusion de branche • Permet d'incorporer les changements d'une branche dans une autre – Commande git merge <branche à fusionner> – S'exécute dans la branche cible – Peut éventuellement créer un commit
Fusion de branche • Fusion de develop dans master – HEAD sur master – $ git merge develop
Fusion de branche • Fusion de develop dans master – Un nouveau commit créé par le merge
Fusion de branche • Fusion de develop dans master – HEAD sur master – $ git merge develop
Fusion de branche • Fusion de develop dans master – Pas nouveau commit créé par le merge – Merge de type Fast-Forward
Fusion de branche • Dans certains cas • Il y a conflit
Fusion de branche • $ git status
Fusion de branche • Résolution du conflit à la main Code venant de la branche master
Fusion de branche • Résolution du conflit à la main Code venant de la branche toto
Fusion de branche • Résolution du conflit à la main
Fusion de branche • Résolution du conflit à la main On marque comme résolu – git add <nom du fichier> • Et on commit – git commit
Gitk • Visualisation graphique de votre dépot – Par défaut: de la branche courante – --all: de toutes les branches
GIT AVANCE
Modifier le commit précédent • Très utile en cas d'erreur ou d'oubli • Modification du message de commit – $ git commit –-amend – On change juste le message • Modification du contenu du commit – On fait des modifications – $git add pour les stager – $git commit –-amend – Les modifications sont fusionnées avec celle du commit précédent • ATTENTION: modification de l historique !!
Commiter des fichiers par morceaux • Possible grace au mécanisme de staging – Seul ce qui est stagé est commité – On stage des parties de fichier • Tres utile en cas de: – Plusieurs modifs à commiter séparement – Commiter le code utile sans le code de debug – ...
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $git status
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $git diff
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $git add -p a.c • ? h
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • ? s
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • ? y • ? n
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $ git status V2.1
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $ git diff $git diff –cached • Il suffit ensuite de commiter V2.1
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $git add -e a.c Patch à éditer
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $git add -e a.c • Le patch est appliqué à l enregistrement Patch modifié
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $ git status V2.1
Commiter des fichiers par morceaux Working Directory Staging Area Repository v1v2 • $ git diff $git diff –cached • Il suffit ensuite de commiter V2.1
Identifier un commit • Tous les commits ont un ID – Checksum sur 160bits dépendant de • La date • L'auteur • Contenu des modifications – Représenté par une chaine de 40 caracteres • Les IDs sont utilisés pour chainer l historique • Modifier un commit => modifier son ID => modifier l historique !!
Identifier un commit • Identification relative possible • En considérant toujours le 1er prédécesseur – <identifiant>~<nombre> – HEAD~1 est le commit précédent • En choisissant le prédécesseur en cas de merge – <identifiant>^<nombre> – HEAD^1 est le prédécesseur[0] de HEAD – HEAD^2 est le prédécesseur[1] de HEAD
git checkout • Ramène HEAD en arrière dans l histoire – git checkout <identifiant de commit> – $ git checkout d607101
git checkout • Ramène HEAD en arrière dans l histoire – git checkout d607101 – La branche courante ne bouge pas – Les fichiers locaux ne sont pas modifiés – Place HEAD dans un état détaché
git checkout • Un nouveau commit ne serait sur aucune branche • Pour l'assurer mieux vaut créer une nouvelle branche
git checkout • Un commit sur une branche ne peut pas être perdu – Encore plus sur: créer la branche avant le commit
git checkout • Pas de panique, Git vous prévient – Au moment du git checkout – Au moment du git status
git reset • Ramène HEAD et la branche en arrière dans l'histoire – git reset <identifiant de commit> – git reset d607101
git reset • Ramène HEAD et la branche en arrière dans l'histoire – git reset <identifiant de commit> – La branche courante bouge – Les fichiers locaux sont possiblement modifiés – HEAD n'est pas dans un etat detaché – ATTENTION : l'historique est modifié
git reset Working Directory Staging Area Repository v2v2 • $ git reset --soft HEAD~1
git reset Working Directory Staging Area Repository v1v2 v2
git reset Working Directory Staging Area Repository v2v2 – $ git reset --mixed HEAD~1 • Ou – $ git reset HEAD~1
git reset Working Directory Staging Area Repository v1v2
git reset Working Directory Staging Area Repository v2v2 – $ git reset --hard HEAD~1
git reset Working Directory Staging Area Repository v1v1 • ATTENTION: Tous les fichiers versionnés locaux sont écrasés !!
git rebase • Réapplique une branche sur une autre – On se rebase par rapport à une autre branche – La branche courante est modifiée – $ git rebase master
git rebase • Réapplique une branche sur une autre – Retrouve le commit commun – Recrée les commits suivants sur la branche par rapport à laquelle on se rebase – ATTENTION: historique modifié!!
git rebase • Alternative au merge • Très utile pour – Se réaligner par rapport à une branche ayant évolué – Eviter d'avoir un historique en gare de triage • Si la branche par rapport à laquelle on se rebase n'a pas evolué – Fast Forward
git rebase -i • Permet de retravailler l'historique – git rebase -i <identifiant de commit> • Modifications possibles – Supprimer des commits – Réordonner les commits – Fusionner des commits – Editer des commits – Découper des commits • ATTENTION: modifie l'historique !
git rebase -i • Les commits sont affichés dans l'ordre inverse • Seront refaits en fonction des commandes
git rebase -i • Ligne supprimée => commit supprimé
git rebase -i • Réordonner les lignes => réordonner les commits
git rebase -i • Fusion des commits en changeant la commande en squash ou fixup
git rebase -i • Editer des commits en changeant la commande en edit
git rebase -i • La commande arrête son execution après avoir effectué le commit – $ git commit --amend permet de modifier le commit a posteriori – $ git reset HEAD~1 ramène au point juste avant le commit avec les modifs stagés • Plusieurs commit => commit divisé en plusieurs • Pour relancer la commande – $ git rebase --continue
git rebase -i • En cas de problème pendant l exécution – $ git rebase --abort – Rétablit la branche dans l'état avant rebase • Si vous n'êtes pas sur de vous – $ git branch <nom de branche> – Crée une branche de “sauvegarde”
git stash • Sauvegarder les fichiers versionnés modifés et les fichiers stagés – $ git stash – Le répertoire de travail est propre • Lister ce qui est stashé – $ git stash list
git stash • Réappliquer le stash – $ git stash apply – $ git stash apply stash@{index} • Réappliquer le stash en rétablissant le stage – Ajouter l option –index • Créer une branch à partir du stash – $ git stash branch <nom de branche>
git blame • Permet de savoir d'ou viennent les lignes d'un fichier – $ git blame <nom de fichier> • Possibilité de restreindre à une ligne ou un bloc de ligne – $ git blame <nom de fichier> -L<nb>,<nb>
git bisect • Permet de rechercher par dichotomie quel commit a introduit un bug • Initier la recherche – $ git bisect start • Indiquer que le commit courant a le bug – $git bisect bad • Indiquer un commit qui n'avait pas encore le bug – $ git bisect good <identifiant de commit>
git bisect • Git checkout le commit du milieu • On indique si le bug est présent ou pas – $ git bisect good ou $git bisect bad • Ainsi de suite jusqu'à atteindre le commit qui introduit le bug • Indiquer la fin de la recherche et rétablir HEAD dans l'état initial – $ git bisect reset
git bisect • On peut automatiser bisect via un script • Status du script – 0 si le bug n'est pas présent – 1 si le bug est présent • Initialisation de la recherche – $ git bisect start <id bug> <id ok> • Démarrage de la recherche – $ git bisect run <nom du script>
Divers • Annuler l'effet d un commit – git revert <identifiant de commit> – Crée un commit “mirroir” • “Piquer” un commit – Git cherry-pick <identifiant de commit> – Applique le commit dans la branche courante • Se rappeler la résolution des conflits – git config --global rerere.enabled true
Git en réseau
Mécanisme de staging • Dans subversion • Dans Git Working Directory Repository Working Directory Local Repository Staging Area svn add / svn commit svn checkout Remote Repository
Local vs remote • On travail toujours sur un dépot local • Un dépot distant est appelé remote • L'argument de git clone est un remote – Ce remote s'appelle origin • Interactions avec les remote – Commandes spécifiques • Git est decentralisé – Possibilité d'avoir plusieurs remote
Gestion des remote • Lister les remote – $git remote -v • Ajouter un remote – $ git remote add <nom> <URI> • Supprimer un remote – $ git remote remove <nom> • Récuperer l'historique de tous les remote – $ git remote update
Interaction avec les remote • Récuperer l'historique d'un remote – $ git fetch <nom du remote> – Les fichiers du répertoire de travail ne sont pas modifiés • Connaitre son status par rapport aux remote – $ git status
Interaction avec les remote • Récuperer une branche en local – $ git checkout -b <nom local> <remote>/<branch> • Créer une branche locale sur un remote – $ git push -u <remote> <branche>[:nom distant] • Infos de branche – $ git branch -avv
Interaction avec les remote • Pousser une branche vers un remote – $ git push <nom du remote> <branche> • Mettre à jour une branche depuis un remote – $ git pull • Connaitre son status par rapport aux remote – $ git status • Pousser les tags – $ git push <nom du remote> <tag> – $ git push --all
Interaction avec les remote • Le remote est en avance de 3 commits – $ git status
Interaction avec les remote • On récupere l historique – $ git fetch – $ git status
Interaction avec les remote • On récupere les modifications de la branche – $ git pull – $ git status
Interaction avec les remote • Le remote est en retard de 3 commits – $ git status
Interaction avec les remote • On pousse les modifications de la branche – $ git push – $ git status
Interaction avec les remote Repo Dev Reference Repo For auditorsFor auditors For integrators/developersFor integrators/developers repo In git: “origin” Developer A Local Repo (.git) Developer B Local Repo (.git) Developer C Local Repo (.git) Auditor Local Repo (.git)
Interaction avec les remote • Gestion du repo central • Qui l administre ? • Qui donne les droits • Tous les développeurs doivent pouvoir écrire • Qui controle qui pousse quoi et ou ? • Qui a le droit de modifier l historique ? • Quel impact sur les autres ? • Risque de collision de branches entre devs Repo dev Developer B Local Repo (.git) git fetch git pull git push
Interaction avec les remote fork Fork ADepot Reference In all git: “reference” For auditorsFor auditors IntegratorIntegrator Developer A Local Repo (.git) Developer B Local Repo (.git) Developer C Local Repo (.git) Personal Fork In A git: “origin” In B,C git : “fork_A” Auditor Local Repo (.git) Other DevelopersOther Developers Fork B Fork C Personal Fork In B git: “origin” In A,C git : “fork_B” Personal Fork In C git: “origin” In A,B git : “fork_C” fork fork fork
Interaction avec les remote Fork B Developer B Local Repo (.git) git fetch git pull git push Developer X Local Repo (.git) git fetch git pull • Fork B est une copie du repo d origine • Pas besoin de droits sur le depot d origine • B gere ses propres droits d'acces • Seul B a les droits d écriture • Pas de risque qu'on casse son repo • Seul B peut modifier l'historique • Pas de risque de casser les autres repos • B gere ses propres branches • Pas de collision avec celles des autres • Les autres devs peuvent puller depuis B • Permet des interactions entre développeurs avec seulement des droits d'écriture
Méthodologie de branche
Méthodologie de branche • La branche master est la branche stable – Recoit les versions officielles
Méthodologie de branche • La branche d'intégration recoit les développements – Commune à tous les développeurs
Méthodologie de branche • On crée des branches a partir de la branche d'intégration – Pour les corrections de bug
Méthodologie de branche • On crée des branches a partir de la branche d'intégration – Pour les corrections de bug – Pour les nouvelles fonctionnalités
Méthodologie de branche • Chaque branche avance à son rythme
Méthodologie de branche • Quand un développement est achevé on le rentre dans la branche d integration – Merge ou rebase Fast forward
Méthodologie de branche • Quand on veut faire une livraison on ramène l'intégration dans la branche master – Merge ou rebase Fast Forward
Méthodologie de branche • On réaligne les développement en cours sur la nouvelle version officielle – Rebase si on veut un historique linéaire – Merge si on veut conserver l historique (Pull Request Github)
Méthodologie de branche • On tag la nouvelle version – Suppression des branches inutiles en cas de rebase
Dépots multiples
Dépots multiples • Intéressant pour les projets composites – Aggrégat de blocks ayant chacun leur depot • Solutions – Submodules • Sorte de lien symbolique vers un autre dépot • Mécanisme intégré à Git • Peu pratique pour contribuer vers le dépot de départ • Lien se cassant facilement
Dépots multiples • Solutions – Subtree • Intègre un dépot complet en tant que sous- répertoire • Mécanisme intégré a Git • Pratique pour contribuer vers le dépot de départ • Maniement assez complexe – Repo • Dépot supplémentaire avec manifeste XML • Outil google • Moyennement pratique pour recontribuer • Maniement assez simple
Extras
References/Liens • Git Book – https://git-scm.com/book/en/v2 • Tutos en ligne – http://nvie.com/posts/a-successful-git-branchi ng-model – http://pcottle.github.io/learnGitBranching – http://think-like-a-git.net/sections/about-this-sit e/who-this-site-is-for.html – http://marklodato.github.io/visual-git-guide/ind ex-en.html – http://onlywei.github.io/explain-git-with-d3/#fr eeplay
References/Liens • Submodule vs subtree – https://codingkilledthecat.wordpress.com/201 2/04/28/why-your-company-shouldnt-use-git-su bmodules – http://typecastexception.com/post/2013/03/16/ Managing-Nested-Libraries-Using-the-GIT-Subtr ee-Merge-Workflow.aspx – http://git-scm.com/book/fr/v1/Utilitaires-Git-F usion-de-sous-arborescences
Licence • Cette présentation est disponible sous licence CC-by-SA 4.0 – https://creativecommons.org/licenses/by- sa/4.0/ • Les graphes d'historique GIT ont été réalisés sur ce site – http://onlywei.github.io/explain-git-with-d3/
Merci pour votre attention

Contenu connexe

PPTX
Présentation de git
parJulien Blin
 
PDF
Tutorial Git
parUCLouvain ACM Student Chapter
 
PDF
Migration d'une base de code subversion vers git
parGeoffrey Bachelet
 
PPTX
Versioning avec Git
parJean-Baptiste Vigneron
 
ODP
Rex docker en production meeutp-docker-nantes
parChristophe Furmaniak
 
ODP
Rancher, le (petit) orchestrateur qui vous veut du bien
parChristophe Furmaniak
 
PDF
Devoxx France : GruntJs In Action
parPublicis Sapient Engineering
 
PDF
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
parPublicis Sapient Engineering
 
Présentation de git
parJulien Blin
 
Tutorial Git
parUCLouvain ACM Student Chapter
 
Migration d'une base de code subversion vers git
parGeoffrey Bachelet
 
Versioning avec Git
parJean-Baptiste Vigneron
 
Rex docker en production meeutp-docker-nantes
parChristophe Furmaniak
 
Rancher, le (petit) orchestrateur qui vous veut du bien
parChristophe Furmaniak
 
Devoxx France : GruntJs In Action
parPublicis Sapient Engineering
 
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
parPublicis Sapient Engineering
 

Tendances

PPT
Git vs SVN
parneuros
 
PDF
kubernetes, pourquoi et comment
parJean-Baptiste Claramonte
 
PDF
Devoxx France - Où sont passés mes serveurs ?
parPublicis Sapient Engineering
 
PDF
Riak introduction
parDamien Krotkine
 
PDF
EBIZNEXT-RIAK
parebiznext
 
PDF
Kubernetes University, Cap sur l’orchestration Docker
parJean-Baptiste Claramonte
 
PDF
Stockage et analyse temps réel d'événements avec Riak chez Booking.com
parDamien Krotkine
 
PDF
Git développez autrement
parBertrand Chevrier
 
ODP
Rancher, l'orchestrateur qui vous veut du bien -- BreizhCamp2016
parChristophe Furmaniak
 
PDF
Docker en Production (Docker Paris)
parJérôme Petazzoni
 
PDF
JCertif 2012 : Git par la pratique
parRossi Oddet
 
PDF
Déploiement et gestion d'un site web avec Rancher
parAnthony Sigogne
 
PDF
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
parMembré Guillaume
 
ODP
Développement avec Intégration continue:Git, Jenkins, Tomcat, CentOS, ubuntu
parAhmed Archive
 
PPTX
Docker le buzz est il justifié ?
parRomain Chalumeau
 
PDF
Introduction à docker.io
parNicolas Hennion
 
PDF
Docker avec Rancher, du dev à la prod - Makazi au devopsdday 2016
parAlexis Ducastel
 
PDF
sshGate - RMLL 2011
parTauop
 
PDF
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
parParis Container Day
 
Git vs SVN
parneuros
 
kubernetes, pourquoi et comment
parJean-Baptiste Claramonte
 
Devoxx France - Où sont passés mes serveurs ?
parPublicis Sapient Engineering
 
Riak introduction
parDamien Krotkine
 
EBIZNEXT-RIAK
parebiznext
 
Kubernetes University, Cap sur l’orchestration Docker
parJean-Baptiste Claramonte
 
Stockage et analyse temps réel d'événements avec Riak chez Booking.com
parDamien Krotkine
 
Git développez autrement
parBertrand Chevrier
 
Rancher, l'orchestrateur qui vous veut du bien -- BreizhCamp2016
parChristophe Furmaniak
 
Docker en Production (Docker Paris)
parJérôme Petazzoni
 
JCertif 2012 : Git par la pratique
parRossi Oddet
 
Déploiement et gestion d'un site web avec Rancher
parAnthony Sigogne
 
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
parMembré Guillaume
 
Développement avec Intégration continue:Git, Jenkins, Tomcat, CentOS, ubuntu
parAhmed Archive
 
Docker le buzz est il justifié ?
parRomain Chalumeau
 
Introduction à docker.io
parNicolas Hennion
 
Docker avec Rancher, du dev à la prod - Makazi au devopsdday 2016
parAlexis Ducastel
 
sshGate - RMLL 2011
parTauop
 
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
parParis Container Day
 

Similaire à Git pratique

PDF
Découvrir et utiliser Git : le logiciel de gestion de versions décentralisé
parECAM Brussels Engineering School
 
PPTX
Git utilisation quotidienne
parSylvain Witmeyer
 
PDF
3_SCM_Git.pdf
parNourFrioui
 
PDF
Travailler avec git et eclipse
parFrancois ANDRE
 
PPTX
GIT Fundamentals
parAbderrazak BOUADMA
 
PDF
Introduction à git.pdf
parbadrfathallah2
 
PPTX
Git
parVladyslav Riabchenko
 
PDF
Git pour les (pas si) nuls
parMalk Zameth
 
PPTX
Presentation-git-ddddddddddddgithub.pptx
parbtbtrtrbtrbthtrhtrhw
 
PDF
Git ou le renouveau du contrôle de version
pargoldoraf
 
PDF
Initiation à Git, GitHub2.pdf
parmouad55
 
PDF
Formation autour de git et git lab
parAbdelghani Azri
 
PDF
Présentation du retour d'expérience sur Git
parIppon
 
KEY
Introduction à Git
parXavier Perez
 
ODP
Introduction à Git (avec PHPStorm)
parPMSIpilot
 
ODP
Reu tech-git-100915100046-phpapp01
parPMSIpilot
 
PDF
Les bases de git
parPierre Sudron
 
PPTX
TP_Git_Detaille_Debutant_Intermediaire_Conflit.pptx
parhassaadaoui
 
PDF
git.pdf
parJaouad Assabbour
 
PDF
introduction sur les fondamentaux Git.pdf
parMouhamedSouley
 
Découvrir et utiliser Git : le logiciel de gestion de versions décentralisé
parECAM Brussels Engineering School
 
Git utilisation quotidienne
parSylvain Witmeyer
 
3_SCM_Git.pdf
parNourFrioui
 
Travailler avec git et eclipse
parFrancois ANDRE
 
GIT Fundamentals
parAbderrazak BOUADMA
 
Introduction à git.pdf
parbadrfathallah2
 
Git
parVladyslav Riabchenko
 
Git pour les (pas si) nuls
parMalk Zameth
 
Presentation-git-ddddddddddddgithub.pptx
parbtbtrtrbtrbthtrhtrhw
 
Git ou le renouveau du contrôle de version
pargoldoraf
 
Initiation à Git, GitHub2.pdf
parmouad55
 
Formation autour de git et git lab
parAbdelghani Azri
 
Présentation du retour d'expérience sur Git
parIppon
 
Introduction à Git
parXavier Perez
 
Introduction à Git (avec PHPStorm)
parPMSIpilot
 
Reu tech-git-100915100046-phpapp01
parPMSIpilot
 
Les bases de git
parPierre Sudron
 
TP_Git_Detaille_Debutant_Intermediaire_Conflit.pptx
parhassaadaoui
 
git.pdf
parJaouad Assabbour
 
introduction sur les fondamentaux Git.pdf
parMouhamedSouley
 

Plus de quicky_osm

PDF
Git pratique
parquicky_osm
 
PDF
Soda sotm fr-2013_02_24
parquicky_osm
 
ODT
Soda sotm fr-2013_02_24
parquicky_osm
 
ODP
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 10 Novembre...
parquicky_osm
 
PDF
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 10 Novembre...
parquicky_osm
 
PDF
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 06 Juillet ...
parquicky_osm
 
ODP
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 06 Juillet ...
parquicky_osm
 
Git pratique
parquicky_osm
 
Soda sotm fr-2013_02_24
parquicky_osm
 
Soda sotm fr-2013_02_24
parquicky_osm
 
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 10 Novembre...
parquicky_osm
 
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 10 Novembre...
parquicky_osm
 
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 06 Juillet ...
parquicky_osm
 
Presentation OpenStreetMap (OSM) au Pole Numerique de la Drome le 06 Juillet ...
parquicky_osm
 

Git pratique

  • 1.
    11 Decembre 2017– LOGal Laboratoire Ouvert Grenoblois - Julien Thevenon Git Pratique CC-by-SA
  • 2.
    Plan • Introduction • Gitbasique • Git avancé • Git en réseau • Méthodologie de branches • Dépots multiples
  • 3.
  • 4.
    Introduction • Gestionnaire deversion – Garde un historique du projet et permet de naviguer dans celui-ci • Pourquoi? – Un projet c'est vivant et ca évolue – Besoin de revenir en arrière • correction de bug dans une version précédente • erreur dans le dévelopment – Plusieurs fonctionnalités à développer en parallèle – Pour travailler à plusieurs • nécessiter de se synchroniser
  • 5.
    Introduction • Historique – Créationen 2005 par Linus Torvald • Spécifications – Etre rapide – Design simple – Etre efficace pour le développement en parallèle par de nombreuses personnes – Etre entièrement distribué – Scalable en terme de rapidité et de place
  • 6.
  • 7.
    Git et lesgraphes • L'historique du projet est un graphe orienté • Les commandes git agissent sur le graphe
  • 8.
    Configuration de Git •Permet de spécifier le nom de l utilisateur – $ git config --global user.name "John Doe" • Son adresse mail – $ git config --global user.email johndoe@example.com • L'éditeur de texte à utiliser – $ git config --global core.editor emacs
  • 9.
    Configuration de Git •Lister les clefs de configuration – $ git config -–list • Connaitre la valeur d'une clef – $ git config user.name • Sur les version récentes pour savoir où est définie la clef – $git config user.name -–show-origin
  • 10.
    Configuration de Git •Configuration bas niveau – dans /etc/gitconfig – modifiable via git config –system • Configuration utilisateur – ~/.gitconfig ou ~/.config/git/config – modifiable via git config –global • Possibilité d'avoir une configuration locale au dépot
  • 11.
    Création d'un dépotGIT • A partir de rien – Dans un répertoire exécutez la commande – $ git init • A partir d'un dépot existant – $ git clone <URI> [nom du dépot]
  • 12.
    Git status • Donnel'état de votre dépot git – Branche sur laquelle vous êtes
  • 13.
    Git status • Donnel'état de votre dépot git – Fichiers prêts à être commités
  • 14.
    Git status • Donnel'état de votre dépot git – Fichiers en cours de modification
  • 15.
    Git status • Donnel'état de votre dépot git – Fichiers non versionnés
  • 16.
    Git status • Donnel'état de votre dépot git – Commandes à effectuer sur les fichiers
  • 17.
    Git status • Donnel'état de votre dépot git – Eventuellement opérations en cours • A utiliser sans moderation !
  • 18.
    Mécanisme de staging •Dans subversion • Dans Git Working Directory Repository Working Directory RepositoryStaging Area svn add / svn commit svn checkout
  • 19.
    Mécanisme de staging •Inconvénients – Etape supplémentaire – Perturbe les personnes venant d'autres VCS • Avantages – Apporte beaucoup de flexibilité – Permet de préparer les commits en plusieurs fois – Permet des fonctionnalités avancées – Certaines commandes équivalentes à SVN
  • 20.
    Versionner un fichier WorkingDirectory Staging Area Repository v1
  • 21.
    Versionner un fichier •$git add LICENCE Working Directory Staging Area Repository v1
  • 22.
    Versionner un fichier WorkingDirectory Staging Area Repository v1 v1
  • 23.
    Versionner un fichier •$git commit Working Directory Staging Area Repository v1 v1
  • 24.
    Versionner un fichier WorkingDirectory Staging Area Repository v1 v1
  • 25.
    Modifier un fichier WorkingDirectory Staging Area Repository v1v2
  • 26.
    Modifier un fichier WorkingDirectory Staging Area Repository v1v2 • $git add LICENCE
  • 27.
    Modifier un fichier WorkingDirectory Staging Area Repository v1v2 v2
  • 28.
    Modifier un fichier WorkingDirectory Staging Area Repository v1v2 • $git commit v2
  • 29.
    Modifier un fichier WorkingDirectory Staging Area Repository v2 v2
  • 30.
    Annuler une modificationlocale Working Directory Staging Area Repository v1v2
  • 31.
    Annuler une modificationlocale Working Directory Staging Area Repository v1v2 • $git checkout -- LICENSE
  • 32.
    Annuler une modificationlocale Working Directory Staging Area Repository v1 v1
  • 33.
    Unstager une modification WorkingDirectory Staging Area Repository v1v2 v2
  • 34.
    Unstager une modification WorkingDirectory Staging Area Repository v1v2 v2 • $git reset HEAD LICENSE
  • 35.
    Unstager une modification WorkingDirectory Staging Area Repository v1v2
  • 36.
    Renommage/Suppression de fichier •Fichiers non versionnés – mv / rm • Fichiers versionnés – git mv / git rm – Ne pas oublier de faire git add + git commit !
  • 37.
    Visualiser les diférences WorkingDirectory Staging Area Repository v1v2 vB vA
  • 38.
    Visualiser les diférences WorkingDirectory Staging Area Repository v1v2 vB • $git diff vA
  • 39.
    Visualiser les diférences WorkingDirectory Staging Area Repository v1v2 vB • $git add fichier2.txt vA
  • 40.
    Visualiser les diférences WorkingDirectory Staging Area Repository v1v2 vB • $ git diff $ git diff --cached vA
  • 41.
    Visualiser les diférences WorkingDirectory Staging Area Repository v1v2 vB • $ git diff HEAD vA
  • 42.
    Les Tags • Utiliséspour marquer une version, une étape • Tag simple – git tag <nom du tag> <objet à tagguer> • Tag annoté – git tag -a <nom du tag> <objet à tagguer> – Associe un message au tag, la date et le nom de celui qui tag • Lister les tags – git tag -l • Supprimer un tag – git tag -d <nom du tag>
  • 43.
    Ignorer des fichiers •Par exemple – les fichiers temporaires – Backups – Build – ...
  • 44.
    Ignorer des fichiers •Création d un fichier .gitignore – Placé à la racine du projet – Défini des patterns de nom de fichiers à ignorer – A versionner comme n'importe quel fichier
  • 45.
    Visualiser l historique •$ git log $ gitk --all
  • 46.
    Branches • Divergence dudéveloppement principal – Permet d'avoir du développement parallèle • Dans les CVS souvent – Peu performant, lourd – Complexe à manipuler • Dans Git – Rapide, léger – Facile à manipuler • Git encourage l'utilisation des branches
  • 47.
    Gestion des branches •Lister les branches – git branch • Création d'une branch – git branch<nom de la branche> • Suppression d'une branche fusionnée – git branch -d <nom de la branche> • Suppression d'une branche non fusionnée – git branch -D <nom de la branche> • Renommage d'une branche – git branch -m <nom> <nouveau nom>
  • 48.
    Navigation dans lesbranches • L'étiquette HEAD – indique ou l'on travaille dans l'arbre – Par défaut HEAD est sur la branche master
  • 49.
    Navigation dans lesbranches • Changement de branche – Déplacement de HEAD sur une autre branche – $ git checkout <nom de branche>
  • 50.
    Navigation dans lesbranches • Création d'une branche et changement de branche – $ git branch <nom de branche> – $ git checkout <nom de branche> • Ou en une seule commande – $git checkout -b <nom de branche>
  • 51.
    Fusion de branche •Permet d'incorporer les changements d'une branche dans une autre – Commande git merge <branche à fusionner> – S'exécute dans la branche cible – Peut éventuellement créer un commit
  • 52.
    Fusion de branche •Fusion de develop dans master – HEAD sur master – $ git merge develop
  • 53.
    Fusion de branche •Fusion de develop dans master – Un nouveau commit créé par le merge
  • 54.
    Fusion de branche •Fusion de develop dans master – HEAD sur master – $ git merge develop
  • 55.
    Fusion de branche •Fusion de develop dans master – Pas nouveau commit créé par le merge – Merge de type Fast-Forward
  • 56.
    Fusion de branche •Dans certains cas • Il y a conflit
  • 57.
  • 58.
    Fusion de branche •Résolution du conflit à la main Code venant de la branche master
  • 59.
    Fusion de branche •Résolution du conflit à la main Code venant de la branche toto
  • 60.
    Fusion de branche •Résolution du conflit à la main
  • 61.
    Fusion de branche •Résolution du conflit à la main On marque comme résolu – git add <nom du fichier> • Et on commit – git commit
  • 62.
    Gitk • Visualisation graphiquede votre dépot – Par défaut: de la branche courante – --all: de toutes les branches
  • 63.
  • 64.
    Modifier le commitprécédent • Très utile en cas d'erreur ou d'oubli • Modification du message de commit – $ git commit –-amend – On change juste le message • Modification du contenu du commit – On fait des modifications – $git add pour les stager – $git commit –-amend – Les modifications sont fusionnées avec celle du commit précédent • ATTENTION: modification de l historique !!
  • 65.
    Commiter des fichierspar morceaux • Possible grace au mécanisme de staging – Seul ce qui est stagé est commité – On stage des parties de fichier • Tres utile en cas de: – Plusieurs modifs à commiter séparement – Commiter le code utile sans le code de debug – ...
  • 66.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $git status
  • 67.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $git diff
  • 68.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $git add -p a.c • ? h
  • 69.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • ? s
  • 70.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • ? y • ? n
  • 71.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $ git status V2.1
  • 72.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $ git diff $git diff –cached • Il suffit ensuite de commiter V2.1
  • 73.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $git add -e a.c Patch à éditer
  • 74.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $git add -e a.c • Le patch est appliqué à l enregistrement Patch modifié
  • 75.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $ git status V2.1
  • 76.
    Commiter des fichierspar morceaux Working Directory Staging Area Repository v1v2 • $ git diff $git diff –cached • Il suffit ensuite de commiter V2.1
  • 77.
    Identifier un commit •Tous les commits ont un ID – Checksum sur 160bits dépendant de • La date • L'auteur • Contenu des modifications – Représenté par une chaine de 40 caracteres • Les IDs sont utilisés pour chainer l historique • Modifier un commit => modifier son ID => modifier l historique !!
  • 78.
    Identifier un commit •Identification relative possible • En considérant toujours le 1er prédécesseur – <identifiant>~<nombre> – HEAD~1 est le commit précédent • En choisissant le prédécesseur en cas de merge – <identifiant>^<nombre> – HEAD^1 est le prédécesseur[0] de HEAD – HEAD^2 est le prédécesseur[1] de HEAD
  • 79.
    git checkout • RamèneHEAD en arrière dans l histoire – git checkout <identifiant de commit> – $ git checkout d607101
  • 80.
    git checkout • RamèneHEAD en arrière dans l histoire – git checkout d607101 – La branche courante ne bouge pas – Les fichiers locaux ne sont pas modifiés – Place HEAD dans un état détaché
  • 81.
    git checkout • Unnouveau commit ne serait sur aucune branche • Pour l'assurer mieux vaut créer une nouvelle branche
  • 82.
    git checkout • Uncommit sur une branche ne peut pas être perdu – Encore plus sur: créer la branche avant le commit
  • 83.
    git checkout • Pasde panique, Git vous prévient – Au moment du git checkout – Au moment du git status
  • 84.
    git reset • RamèneHEAD et la branche en arrière dans l'histoire – git reset <identifiant de commit> – git reset d607101
  • 85.
    git reset • RamèneHEAD et la branche en arrière dans l'histoire – git reset <identifiant de commit> – La branche courante bouge – Les fichiers locaux sont possiblement modifiés – HEAD n'est pas dans un etat detaché – ATTENTION : l'historique est modifié
  • 86.
    git reset Working DirectoryStaging Area Repository v2v2 • $ git reset --soft HEAD~1
  • 87.
    git reset Working DirectoryStaging Area Repository v1v2 v2
  • 88.
    git reset Working DirectoryStaging Area Repository v2v2 – $ git reset --mixed HEAD~1 • Ou – $ git reset HEAD~1
  • 89.
    git reset Working DirectoryStaging Area Repository v1v2
  • 90.
    git reset Working DirectoryStaging Area Repository v2v2 – $ git reset --hard HEAD~1
  • 91.
    git reset Working DirectoryStaging Area Repository v1v1 • ATTENTION: Tous les fichiers versionnés locaux sont écrasés !!
  • 92.
    git rebase • Réappliqueune branche sur une autre – On se rebase par rapport à une autre branche – La branche courante est modifiée – $ git rebase master
  • 93.
    git rebase • Réappliqueune branche sur une autre – Retrouve le commit commun – Recrée les commits suivants sur la branche par rapport à laquelle on se rebase – ATTENTION: historique modifié!!
  • 94.
    git rebase • Alternativeau merge • Très utile pour – Se réaligner par rapport à une branche ayant évolué – Eviter d'avoir un historique en gare de triage • Si la branche par rapport à laquelle on se rebase n'a pas evolué – Fast Forward
  • 95.
    git rebase -i •Permet de retravailler l'historique – git rebase -i <identifiant de commit> • Modifications possibles – Supprimer des commits – Réordonner les commits – Fusionner des commits – Editer des commits – Découper des commits • ATTENTION: modifie l'historique !
  • 96.
    git rebase -i •Les commits sont affichés dans l'ordre inverse • Seront refaits en fonction des commandes
  • 97.
    git rebase -i •Ligne supprimée => commit supprimé
  • 98.
    git rebase -i •Réordonner les lignes => réordonner les commits
  • 99.
    git rebase -i •Fusion des commits en changeant la commande en squash ou fixup
  • 100.
    git rebase -i •Editer des commits en changeant la commande en edit
  • 101.
    git rebase -i •La commande arrête son execution après avoir effectué le commit – $ git commit --amend permet de modifier le commit a posteriori – $ git reset HEAD~1 ramène au point juste avant le commit avec les modifs stagés • Plusieurs commit => commit divisé en plusieurs • Pour relancer la commande – $ git rebase --continue
  • 102.
    git rebase -i •En cas de problème pendant l exécution – $ git rebase --abort – Rétablit la branche dans l'état avant rebase • Si vous n'êtes pas sur de vous – $ git branch <nom de branche> – Crée une branche de “sauvegarde”
  • 103.
    git stash • Sauvegarderles fichiers versionnés modifés et les fichiers stagés – $ git stash – Le répertoire de travail est propre • Lister ce qui est stashé – $ git stash list
  • 104.
    git stash • Réappliquerle stash – $ git stash apply – $ git stash apply stash@{index} • Réappliquer le stash en rétablissant le stage – Ajouter l option –index • Créer une branch à partir du stash – $ git stash branch <nom de branche>
  • 105.
    git blame • Permetde savoir d'ou viennent les lignes d'un fichier – $ git blame <nom de fichier> • Possibilité de restreindre à une ligne ou un bloc de ligne – $ git blame <nom de fichier> -L<nb>,<nb>
  • 106.
    git bisect • Permetde rechercher par dichotomie quel commit a introduit un bug • Initier la recherche – $ git bisect start • Indiquer que le commit courant a le bug – $git bisect bad • Indiquer un commit qui n'avait pas encore le bug – $ git bisect good <identifiant de commit>
  • 107.
    git bisect • Gitcheckout le commit du milieu • On indique si le bug est présent ou pas – $ git bisect good ou $git bisect bad • Ainsi de suite jusqu'à atteindre le commit qui introduit le bug • Indiquer la fin de la recherche et rétablir HEAD dans l'état initial – $ git bisect reset
  • 108.
    git bisect • Onpeut automatiser bisect via un script • Status du script – 0 si le bug n'est pas présent – 1 si le bug est présent • Initialisation de la recherche – $ git bisect start <id bug> <id ok> • Démarrage de la recherche – $ git bisect run <nom du script>
  • 109.
    Divers • Annuler l'effetd un commit – git revert <identifiant de commit> – Crée un commit “mirroir” • “Piquer” un commit – Git cherry-pick <identifiant de commit> – Applique le commit dans la branche courante • Se rappeler la résolution des conflits – git config --global rerere.enabled true
  • 110.
  • 111.
    Mécanisme de staging •Dans subversion • Dans Git Working Directory Repository Working Directory Local Repository Staging Area svn add / svn commit svn checkout Remote Repository
  • 112.
    Local vs remote •On travail toujours sur un dépot local • Un dépot distant est appelé remote • L'argument de git clone est un remote – Ce remote s'appelle origin • Interactions avec les remote – Commandes spécifiques • Git est decentralisé – Possibilité d'avoir plusieurs remote
  • 113.
    Gestion des remote •Lister les remote – $git remote -v • Ajouter un remote – $ git remote add <nom> <URI> • Supprimer un remote – $ git remote remove <nom> • Récuperer l'historique de tous les remote – $ git remote update
  • 114.
    Interaction avec lesremote • Récuperer l'historique d'un remote – $ git fetch <nom du remote> – Les fichiers du répertoire de travail ne sont pas modifiés • Connaitre son status par rapport aux remote – $ git status
  • 115.
    Interaction avec lesremote • Récuperer une branche en local – $ git checkout -b <nom local> <remote>/<branch> • Créer une branche locale sur un remote – $ git push -u <remote> <branche>[:nom distant] • Infos de branche – $ git branch -avv
  • 116.
    Interaction avec lesremote • Pousser une branche vers un remote – $ git push <nom du remote> <branche> • Mettre à jour une branche depuis un remote – $ git pull • Connaitre son status par rapport aux remote – $ git status • Pousser les tags – $ git push <nom du remote> <tag> – $ git push --all
  • 117.
    Interaction avec lesremote • Le remote est en avance de 3 commits – $ git status
  • 118.
    Interaction avec lesremote • On récupere l historique – $ git fetch – $ git status
  • 119.
    Interaction avec lesremote • On récupere les modifications de la branche – $ git pull – $ git status
  • 120.
    Interaction avec lesremote • Le remote est en retard de 3 commits – $ git status
  • 121.
    Interaction avec lesremote • On pousse les modifications de la branche – $ git push – $ git status
  • 122.
    Interaction avec lesremote Repo Dev Reference Repo For auditorsFor auditors For integrators/developersFor integrators/developers repo In git: “origin” Developer A Local Repo (.git) Developer B Local Repo (.git) Developer C Local Repo (.git) Auditor Local Repo (.git)
  • 123.
    Interaction avec lesremote • Gestion du repo central • Qui l administre ? • Qui donne les droits • Tous les développeurs doivent pouvoir écrire • Qui controle qui pousse quoi et ou ? • Qui a le droit de modifier l historique ? • Quel impact sur les autres ? • Risque de collision de branches entre devs Repo dev Developer B Local Repo (.git) git fetch git pull git push
  • 124.
    Interaction avec lesremote fork Fork ADepot Reference In all git: “reference” For auditorsFor auditors IntegratorIntegrator Developer A Local Repo (.git) Developer B Local Repo (.git) Developer C Local Repo (.git) Personal Fork In A git: “origin” In B,C git : “fork_A” Auditor Local Repo (.git) Other DevelopersOther Developers Fork B Fork C Personal Fork In B git: “origin” In A,C git : “fork_B” Personal Fork In C git: “origin” In A,B git : “fork_C” fork fork fork
  • 125.
    Interaction avec lesremote Fork B Developer B Local Repo (.git) git fetch git pull git push Developer X Local Repo (.git) git fetch git pull • Fork B est une copie du repo d origine • Pas besoin de droits sur le depot d origine • B gere ses propres droits d'acces • Seul B a les droits d écriture • Pas de risque qu'on casse son repo • Seul B peut modifier l'historique • Pas de risque de casser les autres repos • B gere ses propres branches • Pas de collision avec celles des autres • Les autres devs peuvent puller depuis B • Permet des interactions entre développeurs avec seulement des droits d'écriture
  • 126.
  • 127.
    Méthodologie de branche •La branche master est la branche stable – Recoit les versions officielles
  • 128.
    Méthodologie de branche •La branche d'intégration recoit les développements – Commune à tous les développeurs
  • 129.
    Méthodologie de branche •On crée des branches a partir de la branche d'intégration – Pour les corrections de bug
  • 130.
    Méthodologie de branche •On crée des branches a partir de la branche d'intégration – Pour les corrections de bug – Pour les nouvelles fonctionnalités
  • 131.
    Méthodologie de branche •Chaque branche avance à son rythme
  • 132.
    Méthodologie de branche •Quand un développement est achevé on le rentre dans la branche d integration – Merge ou rebase Fast forward
  • 133.
    Méthodologie de branche •Quand on veut faire une livraison on ramène l'intégration dans la branche master – Merge ou rebase Fast Forward
  • 134.
    Méthodologie de branche •On réaligne les développement en cours sur la nouvelle version officielle – Rebase si on veut un historique linéaire – Merge si on veut conserver l historique (Pull Request Github)
  • 135.
    Méthodologie de branche •On tag la nouvelle version – Suppression des branches inutiles en cas de rebase
  • 136.
  • 137.
    Dépots multiples • Intéressantpour les projets composites – Aggrégat de blocks ayant chacun leur depot • Solutions – Submodules • Sorte de lien symbolique vers un autre dépot • Mécanisme intégré à Git • Peu pratique pour contribuer vers le dépot de départ • Lien se cassant facilement
  • 138.
    Dépots multiples • Solutions –Subtree • Intègre un dépot complet en tant que sous- répertoire • Mécanisme intégré a Git • Pratique pour contribuer vers le dépot de départ • Maniement assez complexe – Repo • Dépot supplémentaire avec manifeste XML • Outil google • Moyennement pratique pour recontribuer • Maniement assez simple
  • 139.
  • 140.
    References/Liens • Git Book –https://git-scm.com/book/en/v2 • Tutos en ligne – http://nvie.com/posts/a-successful-git-branchi ng-model – http://pcottle.github.io/learnGitBranching – http://think-like-a-git.net/sections/about-this-sit e/who-this-site-is-for.html – http://marklodato.github.io/visual-git-guide/ind ex-en.html – http://onlywei.github.io/explain-git-with-d3/#fr eeplay
  • 141.
    References/Liens • Submodule vssubtree – https://codingkilledthecat.wordpress.com/201 2/04/28/why-your-company-shouldnt-use-git-su bmodules – http://typecastexception.com/post/2013/03/16/ Managing-Nested-Libraries-Using-the-GIT-Subtr ee-Merge-Workflow.aspx – http://git-scm.com/book/fr/v1/Utilitaires-Git-F usion-de-sous-arborescences
  • 142.
    Licence • Cette présentationest disponible sous licence CC-by-SA 4.0 – https://creativecommons.org/licenses/by- sa/4.0/ • Les graphes d'historique GIT ont été réalisés sur ce site – http://onlywei.github.io/explain-git-with-d3/
  • 143.