-
Notifications
You must be signed in to change notification settings - Fork 1
/
doc-git.html
207 lines (199 loc) · 18.7 KB
/
doc-git.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<meta name="author" content="Olivier Lafleur" />
<title>Introduction à git</title>
<style type="text/css">code{white-space: pre;}</style>
<link rel="stylesheet" href="pandoc.css" type="text/css" />
</head>
<body>
<div id="header">
<h1 class="title">Introduction à git</h1>
<h2 class="author">Olivier Lafleur</h2>
<h3 class="date">4 mai 2015</h3>
</div>
<div id="TOC">
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#pourquoi-utiliser-git">Pourquoi utiliser git?</a></li>
<li><a href="#mise-en-place-de-git">Mise en place de git</a><ul>
<li><a href="#comment-git-fonctionne">Comment git fonctionne</a></li>
<li><a href="#première-utilisation">Première utilisation</a></li>
</ul></li>
<li><a href="#créer-un-dépôt">Créer un dépôt</a></li>
<li><a href="#suivi-des-modifications">Suivi des modifications</a></li>
<li><a href="#explorer-lhistorique">Explorer l’historique</a></li>
<li><a href="#auteur">Auteur</a></li>
</ul>
</div>
<h1 id="introduction">Introduction</h1>
<p>Ce document se veut une introduction au système de gestion de versions décentralisé <a href="http://git-scm.com">git</a>. Nous utiliserons l’exemple de git, mais les principes présentés pourraient aussi bien être appliqués à d’autres systèmes du genre comme Mercurial ou BitKeeper.</p>
<p>Ce document ne se veut absolument pas complet quand à l’utilisation de git. On veut présenter les concepts et les commandes de base qui permettent de fonctionner au jour le jour avec un système de gestion de versions. Au fil du temps, vous pourrez par la suite explorer les possibilités de git en découvrant graduellement ses autres fonctionnalités, qui en font un outil très puissant.</p>
<h1 id="pourquoi-utiliser-git">Pourquoi utiliser git?</h1>
<p>Lorsque l’on programme, il n’est pas rare que l’on soit plusieurs à vouloir travailler sur un même bout de code. Cependant, cela peut devenir problématique lorsque l’on veut changer du code à des endroits différents.</p>
<p>Certaines personnes utilisent le courriel ou une clé USB, mais cela devient rapidement très complexe et il est facile de faire des erreurs lors de l’intégration du code d’un collègue dans le sien.</p>
<p>Une technique est de travailler chacun son tour: la personne A commence le code, envoie le résultat à une personne B, qui travaille dessus et renvoie le tout à la personne A. Ce va-et-vient peut être laborieux et ralentir de beaucoup ce qu’il serait possible de réaliser en travaillant en parallèle.</p>
<p>Quels seraient donc les avantages d’utiliser la gestion de versions?</p>
<ul>
<li><p>Tout ce qui est sauvegardé (on dit faire un <em>commit</em>) n’est jamais perdu. Cela veut dire que l’on peut l’utiliser comme la fonctionnalité pour revenir en arrière (<em>undo</em>) d’un éditeur. Par ailleurs, puisque toutes les anciennes versions sont sauvegardées, il est toujours possible de revenir dans le temps et de se replacer dans un état passé.</p></li>
<li><p>Nous avons une liste des changements qui ont été faits, par qui et quand. On sait donc à qui poser nos questions plus tard lorsque ce n’est pas tout à fait clair.</p></li>
<li><p>C’est difficile (mais pas impossible) de réécrire par-dessus les changements de quelqu’un. Le système de gestion de versions avertit automatiquement l’usager lorqu’il y a un conflit entre deux changements effectués sur la même ligne par deux personnes différentes.</p></li>
</ul>
<p>La gestion de versions est essentielle pour tous les projets de développement logiciel d’une certaine ampleur, mais la plupart des programmeurs l’utilisent pour leurs petits projets aussi. Ce n’est pas non plus que pour du logiciel: les livres, les notes de cours (comme celles-ci), les petits jeu de données et tout ce qui change à travers le temps et a besoin d’être partagé peut (et devrait) être stocké dans un système de gestion de versions.</p>
<h1 id="mise-en-place-de-git">Mise en place de git</h1>
<p>Commençons par explorer comment la gestion de versions peut être utilisée pour garder une trace de ce qu’une personne a fait, et quand. On peut donc éviter de se retrouver avec des noms de fichiers laborieux incluant des VERSION_FINALE_2_olivier ou autres noms du genre, comme illustré dans <a href="http://www.phdcomics.com/comics/archive.php?comicid=1531">une bande dessinée</a> du <em>comic</em> en ligne <a href="http://phdcomics.com">Piled Higher and Deeper</a>.</p>
<p>Nous avons tous déjà été dans cette situation par le passé. Il est ridicule de se retrouver avec de multiples versions presqu’identiques d’un même document.</p>
<p>Les systèmes de gestion de version commencent avec une version de base du document et sauvegardent seulement les changements (le <em>diff</em>) que vous avez faits à chaque étape.</p>
<div class="figure">
<img src="seq.png" alt="Le document de base et ses changements" />
<p class="caption">Le document de base et ses changements</p>
</div>
<p>À partir du moment où on commence à voir les changements comme étant séparés du document lui-même, on peut penser à “appliquer” des changements différents sur le document de base et ainsi obtenir des versions différentes du document. Par exemple, deux utilisateurs peuvent faire des changements indépendants sur le même document.</p>
<h2 id="comment-git-fonctionne">Comment git fonctionne</h2>
<p>Un système de gestion de versions est un outil qui garde une trace de ces changements pour nous et nous aide à amalgamer tous les changements ensemble. Un système comme git est conçu pour garder de multiples changements synchronisés sur différents ordinateurs et serveurs. C’est pourquoi on dit qu’il s’agit d’un système <em>distribué</em>, par opposition à SVN ou Team Foundation Server, qui sont des systèmes dits centralisés: on doit obligatoirement se connecter au serveur central pour faire un <em>commit</em>.</p>
<p>Un dépôt (<em>repository</em> en anglais) est un ensemble de fichiers que nous voulons versionner.</p>
<p>Avec git, chaque utilisateur qui veut faire un changement à un dépôt a sa propre copie des fichiers dans ce dépôt, ainsi que sa copie des changements (les <em>commits</em>) qui ont été faits à ceux-ci. Git garde les <em>commits</em> dans un répertoire caché avec les copies des fichiers.</p>
<h2 id="première-utilisation">Première utilisation</h2>
<p>La première fois que l’on utilise git sur une nouvelle machine, nous avons besoin de configurer quelques paramètres. Voici comment on procède (dans le terminal):</p>
<pre><code>$ git config --global user.name "Olivier Lafleur"
$ git config --global user.email "[email protected]"</code></pre>
<p>(Utilisez évidemment votre nom et votre adresse courriel à la place de mes informations.)</p>
<p>Les commandes git sont écrites sous la forme <code>git verbe</code>, où <code>verbe</code> est ce que nous voulons faire. Dans ce cas, nous donnons à git notre nom et notre adresse courriel, en lui disant que nous voulons utiliser ces paramètres de façon globale (pour tous les projets sur cet ordinateur).</p>
<p>Les commandes précédentes ont seulement besoin d’être exécutées une seule fois: le <em>flag</em> <code>--global</code> dit à git d’utiliser ces paramètres pour tous les projets.</p>
<h1 id="créer-un-dépôt">Créer un dépôt</h1>
<p>Une fois que git est configuré, nous pouvons commencer à l’utiliser. Créons un répertoire pour nos fichiers:</p>
<pre><code>$ mkdir poésie
$ cd poésie</code></pre>
<p>et disons à git de créer un dépôt - un endroit où git peut stocker les anciennes versions de nos fichiers:</p>
<pre><code>$ git init</code></pre>
<p>Si nous utilisons <code>ls</code> pour montrer le contenu du répertoire, on dirait que rien n’a changé. Par contre, si nous ajoutons le <em>flag</em> <code>-a</code> pour tout montrer, on voit que git a créé un répertoire caché appelé <code>.git</code>:</p>
<pre><code>$ ls -a
. .. .git</code></pre>
<p>Git stocke l’information sur le projet dans ce sous-répertoire spécial. Si jamais nous le supprimons, nous perdrons l’historique de ce projet.</p>
<p>On peut s’assurer que tout est mis en place de façon appropriée en demandant à git de nous dire quel est le statut du projet:</p>
<pre><code>$ git status
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)</code></pre>
<h1 id="suivi-des-modifications">Suivi des modifications</h1>
<p>Créons tout d’abord un fichier appelé <code>soir_dhiver.txt</code> qui contiendra de la poésie. Vous pouvez utiliser l’éditeur de votre choix pour ce faire. L’important est qu’il soit créé dans le répertoire qui est versionné (<code>poésie</code> dans ce cas).</p>
<p>Entrez le texte suivant dans le fichier <code>soir_dhiver.txt</code>:</p>
<pre><code>Ah! comme la neige a neigé!</code></pre>
<p><code>soir_dhiver.txt</code> contient maintenant une seule ligne. Si on demande le statut du projet encore une fois, git nous dit qu’il a remarqué le nouveau fichier:</p>
<pre><code>$ git status
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
soir_dhiver.txt
nothing added to commit but untracked files present (use "git add" to track)</code></pre>
<p>Le message <em>Untracked files</em> avec le nom de fichier écrit en rouge signifie qu’il y a un fichier dans le répertoire dont git ne tient pas compte. Nous pouvons lui dire de le surveiller en utilisant la commande <code>git add</code>:</p>
<pre><code>$ git add soir_dhiver.txt</code></pre>
<p>et s’assurer que c’est bien ce qui s’est passé:</p>
<pre><code>$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: soir_dhiver.txt
</code></pre>
<p>On voit que le nom de fichier est maintenant indiqué en vert. Git sait donc qu’il est supposé surveiller <code>soir_dhiver.txt</code>, mais il n’a pas encore enregistré ces changements comme des <em>commits</em>. Pour lui dire de le faire, nous avons besoin d’exécuter une commande de plus:</p>
<pre><code>$ git commit -m "Commencer l'écriture du poème"
[master (root-commit) bef8ac3] Commencer l'écriture du poème
1 file changed, 1 insertion(+)
create mode 100644 soir_dhiver.txt</code></pre>
<p>Quand on exécute la commande <code>git commit</code>, git prend tout ce qu’on lui a dit de sauvegarder lorsqu’on a utilisé la commande <code>git add</code> et le stocke comme une copie permanente à l’intérieur du répertoire spécial <code>.git</code>. Cette copie permanente est appelée une révision et son identifiant court est <code>bef8ac3</code> (votre révision aura un autre identifiant.)</p>
<p>On utilise le flag <code>-m</code> (pour “message”) pour enregistrer un commentaire court, descriptif et spécifique qui nous aidera plus tard à nous rappeler ce que nous avons fait comme changement, et pourquoi. Si on exécute <code>git commit</code> sans l’option <code>-m</code>, git lancera l’éditeur par défaut afin d’écrire un plus long message, si on le souhaite.</p>
<p>Un bon message de <em>commit</em> commence avec un bref résumé (moins de 50 caractères) des changements apportés dans ce <em>commit</em>. Si vous voulez donner plus de détails, ajoutez une ligne blanche entre la ligne de résumé et les remarques additionnelles.</p>
<p>Maintenant, si on fait <code>git status</code>, on obtient:</p>
<pre><code>$ git status
On branch master
nothing to commit, working directory clean</code></pre>
<p>Il nous dit que tout est à jour. Si l’on veut savoir ce que l’on a fait récemment, on peut demander à git de nous montrer l’historique du projet en utilisant <code>git log</code>:</p>
<pre><code>$ git log
commit bef8ac358d77d6e57833947f96a16199bba885ee
Author: Olivier Lafleur <[email protected]>
Date: Tue Mayh 5 09:51:56 2015 -0400
Commencer l'écriture du poème
</code></pre>
<p>La commande <code>git log</code> fait une liste de toutes les révisions faites dans ce dépôt en ordre chronologique inverse. Pour chaque révision, il est indiqué l’identifiant complet (qui commence avec les mêmes caractères que l’identifiant court affiché par la commande <code>git commit</code> réalisée plus tôt), l’auteur de la révision, le moment où elle a été créée et le message de <em>log</em> qui a été donné lorsque la révision a été créée.</p>
<p>En ce moment, si on exécute <code>ls</code>, on ne voit encore qu’un seul fichier, <code>soir_dhiver.txt</code>. C’est parce que git sauvegarde les informations sur l’historique des fichiers dans le répertoire spécial <code>.git</code> dont on a parlé plus tôt pour ne pas que notre système de fichiers devienne encombré (et pour ne pas que l’on modifie ou supprime une ancienne version).</p>
<p>Maintenant, rajoutons des vers dans notre poème.</p>
<pre><code>Ma vitre est un jardin de givre.
Ah! comme la neige a neigé!
Qu'est-ce que le spasme de vivre
Ô la douleur que j'ai, que j'ai!</code></pre>
<p>Lorsque l’on exécute <code>git status</code>, il nous dit qu’un fichier qu’il connaît a été modifié:</p>
<pre><code>$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: soir_dhiver.txt
no changes added to commit (use "git add" and/or "git commit -a")</code></pre>
<p>La dernière ligne est ce qui est important: aucun changement ajouté au <em>commit</em>. Nous avons changé ce fichier, mais n’avons pas dit à git que nous voulions sauvegarder ces changements (ce que l’on fait avec <code>git add</code>). Faisons cela. C’est une bonne pratique de toujours passer en revue les changements effectués avant de les sauvegarder. On fait cela en utilisant <code>git diff</code>. Cela nous montre les différences entre l’état courant du fichier et la plus récente version sauvegardée:</p>
<pre><code>$ git diff
diff --git a/soir_dhiver.txt b/soir_dhiver.txt
index 45a1c88..be81340 100644
--- a/soir_dhiver.txt
+++ b/soir_dhiver.txt
@@ -1 +1,5 @@
Ah! comme la neige a neigé!
+Ma vitre est un jardin de givre.
+Ah! comme la neige a neigé!
+Qu'est-ce que le spasme de vivre
+Ô la douleur que j'ai, que j'ai!</code></pre>
<p>La sortie est cryptique parce qu’il s’agit en fait d’une série de commandes pour des éditeurs ou des commandes Unix comme <code>patch</code> qui leur dit comment reconstruire un fichier à partir d’un autre fichier. Si on découpe en petites parties:</p>
<ul>
<li><p>La première ligne nous dit que git produit une sortie similaire à la commande Unix <code>diff</code>, qui compare l’ancienne et la nouvelle version d’un fichier.</p></li>
<li><p>La deuxième ligne nous dit exactement quelles révisions du fichier est-ce que git compare: <code>45a1c88</code> et <code>be81340</code> sont des étiquettes générées automatiquement pour ces révisions.</p></li>
<li><p>La troisième et la quatrième ligne nous disent le nom du fichier qui est changé.</p></li>
<li><p>Les lignes restantes sont les plus intéressantes. Ils nous montrent les différences effectives et les lignes sur lesquelles elles sont. En particulier, le marqueur <code>+</code> dans la première colonne montre que nous ajoutons des lignes.</p></li>
</ul>
<p>Après avoir passé en revue nos changements, c’est le temps de <em>commiter</em>:</p>
<pre><code>$ git commit -m "Ajoute des vers au poème"
On branch master
Changes not staged for commit:
modified: soir_dhiver.txt
no changes added to commit</code></pre>
<p>Oups! Git ne veut pas <em>commiter</em> car nous n’avons pas utilisé <code>git add</code> en premier. Réparons cette erreur:</p>
<pre><code>$ git add soir_dhiver.txt
$ git commit -m "Ajoute des vers au poème"
[master d3a16e0] Ajoute des vers au poème
1 file changed, 4 insertions(+)
</code></pre>
<p>On peut donc maintenant afficher l’historique de nos <em>commits</em> :</p>
<pre><code>$ git log
commit d3a16e0fc131c38580e4751897aeda1168ea9082
Author: Olivier Lafleur <[email protected]>
Date: Tue May 5 10:52:01 2015 -0400
Ajoute des vers au poème
commit bef8ac358d77d6e57833947f96a16199bba885ee
Author: Olivier Lafleur <[email protected]>
Date: Tue May 5 09:51:56 2015 -0400
Commencer l'écriture du poème</code></pre>
<p>Et si on demande à git son statut, il nous répond:</p>
<pre><code>$ git status
On branch master
nothing to commit, working directory clean</code></pre>
<p>Pour récapituler, lorsque nous voulons ajouter des changements à notre dépôt, nous devons:</p>
<ul>
<li>ajouter les fichiers changés (<code>git add</code>)</li>
<li><em>commiter</em> les changements au dépôt (<code>git commit</code>).</li>
</ul>
<p>Par ailleurs, lorsqu’on a des changements dans plusieurs fichiers, la commande <code>git add --all .</code> permet d’ajouter tous les changements (y compris les suppressions grâce à l’option <code>--all</code>) dans le répertoire courant (donné en paramètre par le <code>.</code>).</p>
<h1 id="explorer-lhistorique">Explorer l’historique</h1>
<p>Si nous voulons voir ce que nous avons changé et quand, il est possible de revenir en arrière dans notre historique.</p>
<h1 id="auteur">Auteur</h1>
<p>Olivier Lafleur (<a href="mailto:[email protected]">[email protected]</a>)</p>
<p>Les corrections et suggestions pour améliorer ce document sont très appréciées. Vous pourrez trouver la dernière version de ce document à l’adresse <a href="https://github.com/dinfcll/doc-git/" class="uri">https://github.com/dinfcll/doc-git/</a></p>
<p>Ce contenu est lui aussi mis à votre disposition selon les termes de la <a href="http://creativecommons.org/licenses/by/4.0/">Licence Creative Commons Attribution 4.0 International</a> CC-BY.</p>
<p>Par ailleurs, il est important de mentionner que le contenu de ce document est fortement inspiré du contenu des formations de l’organisme <em><a href="http://software-carpentry.org">Software Carpentry</a></em>, organisme à but non lucratif qui met disponible en ligne son contenu sous licence Creative Commons.</p>
<div id="footer">
© 2015 <a href="http://olivierlafleur.com">Olivier Lafleur</a>
</div>
</body>
</html>