aboutsummaryrefslogtreecommitdiff
path: root/fichiers
diff options
context:
space:
mode:
authorRobert Alessi <alessi@robertalessi.net>2018-10-03 15:47:28 +0200
committerRobert Alessi <alessi@robertalessi.net>2018-10-03 15:47:28 +0200
commite0fff70aec7a11ad6d7a3f1d22bd52dad5b7a0bf (patch)
treede0e2d2f2ae4958ce01574b97a1b98ee76db1c91 /fichiers
parentfb54e0d5ec2df0abd20f456a7d07c297a67110ff (diff)
downloadcourses-e0fff70aec7a11ad6d7a3f1d22bd52dad5b7a0bf.tar.gz
02-git.tex: introduction
Diffstat (limited to 'fichiers')
-rw-r--r--fichiers/01-ligne-de-commande.tex2
-rw-r--r--fichiers/02-git.tex357
2 files changed, 353 insertions, 6 deletions
diff --git a/fichiers/01-ligne-de-commande.tex b/fichiers/01-ligne-de-commande.tex
index 66cfdce..edc3765 100644
--- a/fichiers/01-ligne-de-commande.tex
+++ b/fichiers/01-ligne-de-commande.tex
@@ -606,7 +606,7 @@ possibles:
606 \verb+photos_de_vacances.zip+ 606 \verb+photos_de_vacances.zip+
607\end{quoting} 607\end{quoting}
608 608
609\paragraph{Fichiers cachés} 609\paragraph{\hypertarget{lnk_hidden}{Fichiers cachés}}
610Tout fichier dont le nom commence par un point (\mintinline{text}|.|) 610Tout fichier dont le nom commence par un point (\mintinline{text}|.|)
611est considéré comme un fichier caché. Le plus souvent, les fichiers 611est considéré comme un fichier caché. Le plus souvent, les fichiers
612cachés contiennent des paramètres de configuration. La commande 612cachés contiennent des paramètres de configuration. La commande
diff --git a/fichiers/02-git.tex b/fichiers/02-git.tex
index 87767ab..a314c80 100644
--- a/fichiers/02-git.tex
+++ b/fichiers/02-git.tex
@@ -1,5 +1,7 @@
1\input{../_preamble} 1\input{../_preamble}
2%\input{../_preamble_bbl} 2\input{../_preamble_bbl}
3% \usepackage{biblatex}
4% \addbibresource{../bibliography}
3\usepackage{menukeys} 5\usepackage{menukeys}
4\title{Git} 6\title{Git}
5\usepackage{float} 7\usepackage{float}
@@ -32,13 +34,358 @@
32\renewcommand{\contentsname}{Sommaire} 34\renewcommand{\contentsname}{Sommaire}
33\tableofcontents 35\tableofcontents
34 36
35\listoflistings 37% \listoflistings
36 38
37\needspace{3\baselineskip} 39% \needspace{3\baselineskip}
38\listoftables 40% \listoftables
39 41
40\chapter{Introduction} 42\chapter{Introduction}
41\label{cha:introduction} 43\label{cha:introduction}
42 44
45\paragraph{Avertissement}
46Dans les pages qui suivent, on cherche à donner au lecteur quelques
47éléments sur la notion de \emph{système de contrôle de version} en
48général et sur \emph{Git} en particulier. L'ouvrage de référence,
49\citetitle{Chacon.Straub2018}, traduit en français, est disponible en
50ligne\autocite{Chacon.Straub2018}.
43 51
44\end{document} \ No newline at end of file 52\section{Les systèmes de contrôle de version}
53\label{sec:vers-contr-syst}
54Les \enquote{systèmes de contrôle de version}, en anglais
55\emph{version control systems} (VCS), sont des logiciels qui
56permettent de suivre toutes les modifications des fichiers et des
57répertoires qui se trouvent dans un répertoire donné. À partir du
58moment où l'on décide de suivre le contenu d'un répertoire, on peut
59retrouver l'état qui était le sien dans le passé à tout moment.
60
61Supposons que l'on ait quelque part modifié un paragraphe dans un
62texte, ajouté ou retranché des lignes: le système de contrôle de
63version permet alors de retrouver la chronologie de toutes les
64modifications et de les afficher clairement, l'une après l'autre. On a
65ainsi l'assurance de ne jamais rien perdre de son travail.
66
67Le contrôle de version permet également de travailler en même temps
68sur différentes \emph{branches}. On distingue ainsi la \emph{branche
69 principale} de toutes les \emph{branches secondaires} que l'on peut
70ouvrir à tout moment. Prenons un exemple: à un moment donné, on
71souhaite revenir sur une page complexe que l'on a rédigée et y
72apporter des modifications. Mais pour autant, on n'approuve pas encore
73ces modifications et on voudrait ne rien perdre de la version
74originale. On ouvre alors une \emph{branche secondaire} dans laquelle
75on modifie à souhait la page. Durant tout le travail sur la branche
76secondaire, le travail enregistré dans la branche principale n'est pas
77altéré. Une fois terminé le travail sur la branche secondaire, on peut
78l'abandonner ou bien, si le résultat est satisfaisant, le
79conserver. Dans ce cas, on demande au système de contrôle de version
80de \emph{fusionner} dans la branche principale la branche secondaire
81sur laquelle on a travaillé. Puis on continue le travail dans la
82branche principale, après avoir effacé la branche secondaire, tout en
83sachant qu'à tout moment, toutes les étapes de ces modifications
84peuvent être retrouvées. Bien entendu, le système permet d'ouvrir
85simultanément autant de branches qu'on le souhaite.
86
87\subsection{Différents concepts, différentes approches}
88\label{sec:diff-conc-diff}
89On distingue trois types de systèmes de contrôle de version:
90\begin{enumerate}
91\item \textbf{Les systèmes locaux} qui enregistrent les modifications
92 dans une base de données. Quand un fichier est modifié, ces systèmes
93 enregistrent non pas les deux versions du fichier modifié, mais un
94 seul fichier, en plus du fichier initial, dans lequel sont
95 simplement notées les \emph{différences} de l'un à l'autre.
96\item \textbf{Les systèmes centralisés} qui font la même chose que les
97 systèmes locaux, mais dans lesquels la base de données se trouve sur
98 un serveur. L'avantage est que l'on peut alors organiser un travail
99 de groupe. Mais l'inconvénient est que si le serveur est en panne,
100 alors la base de données est inaccessible et personne ne peut
101 travailler.
102\item \textbf{Les systèmes distribués} dans lesquels les différents
103 utilisateurs travaillent non pas sur des fichiers reconstitués à
104 l'aide de la somme des modifications enregistrées sur un serveur,
105 mais sur une version autonome et dupliquée de tous les fichiers qui
106 sont sur le serveur. Chacun travaille sur ses fichiers, même hors
107 réseau. Puis une fois le travail terminé, on envoie sur le serveur
108 un nouvel état de la base de données que les autres peuvent
109 synchroniser à tout moment.
110\end{enumerate}
111
112Git est un système de contrôle de version \emph{distribué}. Par
113rapport à d'autres systèmes de la même catégorie, il offre un avantage
114considérable: celui de travailler non pas sur les \emph{différences}
115entre les modifications des fichiers, mais sur des \emph{instantanés}
116complets. Prenons un exemple. Soit le fichier suivant
117(\verb|recherche.txt|):\label{ref:recherche}
118\begin{minted}[linenos]{text}
119PREMIÈRE PARTIE
120===============
121
122COMBRAY
123-------
124
125I
126
127Longtemps, je me suis couché très tôt. Parfois, à peine ma
128bougie éteinte, mes yeux se fermaient si vite que j'avais juste le
129temps de me dire: «Je m'endors.»
130\end{minted}
131
132Puis l'auteur se ravise et écrit:
133\begin{minted}[linenos]{text}
134PREMIÈRE PARTIE
135===============
136
137COMBRAY
138-------
139
140I
141
142Longtemps, je me suis couché de bonne heure. Parfois, à peine ma
143bougie éteinte, mes yeux se fermaient si vite que je n'avais pas le
144temps de me dire: «Je m'endors.»
145\end{minted}
146
147Si l'on demande maintenant à un système informatique d'analyser les
148différences entre les deux états de \verb|recherche.txt|, il pourra
149produire un résultat comparable à celui-ci:
150
151\label{ref:diff}
152\begin{minted}[linenos,escapeinside=||]{text}
153--- recherche.txt 2018-10-03 12:35:05.848903296 +0200
154+++ recherche.txt 2018-10-03 12:31:04.292356175 +0200
155|\textcolor{Blue}{@@ -6,6 +6,6 @@}|
156
157 I
158|\textcolor{Red}{-Longtemps, je me suis couché très tôt. Parfois, à peine ma}|
159|\textcolor{Red}{-bougie éteinte, mes yeux se fermaient si vite que j'avais juste le}|
160|\textcolor{Green}{+Longtemps, je me suis couché de bonne heure. Parfois, à peine ma}|
161|\textcolor{Green}{+bougie éteinte, mes yeux se fermaient si vite que je n'avais pas le}|
162 temps de me dire: «Je m'endors.»
163\end{minted}
164
165\paragraph{Commentaire}
166La ligne~3 du rapport ci-dessus permet de comprendre que les
167modifications n'interviennent pas avant la ligne~6 du fichier original
168\verb|recherche.txt|. Ensuite, nous trouvons les modifications,
169entourées de \emph{deux lignes non modifiées qui donnent le contexte}:
170ce sont les lignes~5 et 10 du rapport, qui renvoient respectivement
171aux lignes~7 et 11 du fichier original. Enfin, nous trouvons les
172modifications: dans le rapport, les lignes~6 et 7, rendues en rouge et
173précédées du signe $-$, ont été remplacées dans la deuxième version
174par les lignes~8 et 9, rendues en vert, et précédées du signe $+$.
175
176Les systèmes de contrôle de version peuvent donc procéder de deux
177manières différentes:
178\begin{enumerate}
179\item Enregistrer le fichier original seulement, puis tous les
180 rapports successifs qui donnent les modifications. Ainsi, pour
181 donner l'état le plus récent d'un fichier, il suffit de prendre
182 l'original puis de lui appliquer toutes les modifications
183 successives.
184\item Enregistrer toutes les versions successives des fichiers sous la
185 forme d'\emph{instantanés}. Dans ce cas, les rapports qui
186 enregistrent les modifications ne sont pas eux-mêmes enregistrés,
187 mais peuvent toujours être produits à partir de deux instantanés
188 enregistrés. \textbf{C'est ainsi que procède Git}.
189\end{enumerate}
190
191Bien entendu, quand on travaille sur de nombreux fichiers
192simultanément et que, d'une étape à l'autre de son travail, on n'en
193modifie que quelques-uns, Git ne prend pas d'instantané des fichiers
194non modifiés. Au lieu de faire cela, il enregistre simplement un
195\emph{pointeur} vers le dernier instantané du fichier, c'est-à-dire
196vers la dernière version modifiée de ce fichier.
197
198Cette méthode présente de nombreux avantages dont le plus évident
199tient à la sécurité. En effet, les systèmes qui enregistrent seulement
200les rapports de modifications ne sont plus en mesure de restituer un
201fichier donné si l'un de ces rapports est corrompu. Si un chaînon est
202manquant, c'est toute la chaîne qui est brisée. Git n'est pas
203vulnérable sur ce point.
204
205\section{Prise en main de Git}
206\label{sec:prise-en-main}
207\href{https://notabug.org/ralessi/courses/wiki#installation-de-git}{Une
208fois Git installé}, il faut l'initialiser en lui indiquant votre nom
209et votre email. Pour cela, il suffit d'entrer successivement les deux
210lignes suivantes, en veillant à substituer à la fin de chaque ligne
211les informations de l'exemple par celles de votre identité. On
212veillera également à placer le prénom et le nom, séparé par un espace,
213entre guillemets doubles:
214\begin{minted}[linenos]{text}
215git config --global user.name "John Doe"
216git config --global user.email johndoe@example.com
217\end{minted}
218
219Ensuite, \href{./01-ligne-de-commande.pdf}{muni du cours sur la ligne
220 de commande}, il est possible de créer un répertoire de
221travail. Nous allons créer ce répertoire à l'intérieur de notre
222répertoire \verb|Documents|, puis nous rendre à l'intérieur de ce
223répertoire à l'aide de la commande \verb|cd|:
224\begin{minted}{text}
225[robert@kiddo ~]$ cd Documents
226[robert@kiddo Documents]$ mkdir travail
227[robert@kiddo Documents]$ cd travail
228[robert@kiddo travail]$
229\end{minted}
230
231L'étape suivante consiste à demander à Git de suivre le contenu de ce
232répertoire:
233\begin{minted}{text}
234[robert@kiddo travail]$ git init
235Dépôt Git vide initialisé dans /home/robert/Documents/travail/.git/
236\end{minted}
237
238La réponse donnée par Git nous indique où sera maintenue sa base de
239données: dans un
240\href{./01-ligne-de-commande.pdf#lnk_hidden}{répertoire caché}
241\verb|.git| à l'intérieur du répertoire \verb|travail|.
242
243Commençons donc le travail. À l'aide d'un éditeur de texte, saisissons
244le fichier \mintinline{text}|recherche.txt| donné
245\vpageref{ref:recherche} et enregistrons-le dans sa première version.
246La commande suivante \verb|git status| demande à Git de nous
247\emph{fournir un état} du répertoire:
248\begin{minted}[linenos,escapeinside=||]{text}
249[robert@kiddo travail]$ git status
250Sur la branche master
251
252Validation initiale
253
254Fichiers non suivis:
255 (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
256
257 |\textcolor{Red}{recherche.txt}|
258
259aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)
260\end{minted}
261
262\paragraph{Commentaire}
263Comme on le voit, Git est toujours très explicite. Voici ce qu'il faut
264retenir ici de ce rapport:
265\begin{enumerate}
266\item Ligne~2: par défaut, la \emph{branche principale} est appelée
267 par Git \verb|master|.
268\item Ligne~6 et suivantes: Git donne une simple liste de fichiers
269 trouvés dans le répertoire et indique qu'on ne lui a pas (encore)
270 demandé de les \emph{suivre}. C'est un point important qu'il faut
271 bien comprendre: \emph{Git ne suivra que les fichiers qu'on lui a
272 demandé d'indexer}.
273\item Ligne~7: Git nous donne la commande à utiliser pour indexer le
274 fichier qui a été trouvé: \mintinline{bash}|git add <fichier>|
275\end{enumerate}
276
277Exécutons cette commande, puis demandons à Git un nouveau rapport:
278\begin{minted}[linenos,escapeinside=||]{text}
279[robert@kiddo travail]$ git add recherche.txt
280[robert@kiddo travail]$ git status
281Sur la branche master
282
283Validation initiale
284
285Modifications qui seront validées :
286 (utilisez "git rm --cached <fichier>..." pour désindexer)
287
288 |\textcolor{Green}{nouveau fichier : recherche.txt}|
289\end{minted}
290
291La commande \mintinline{bash}|git add recherche.txt| a eu pour effet
292de placer \verb|recherche.txt| \emph{dans la zone d'index de Git} que
293l'on appelle \emph{zone de travail} ou \emph{staging area}.
294
295La dernière opération consiste à enregistrer le fichier dans la base
296de données de Git: cela se fait à l'aide de la commande
297\mintinline{bash}|git commit|. La syntaxe de cette commande est la
298suivante:
299\begin{minted}{bash}
300git commit <fichier> -m "<message>"
301\end{minted}
302où \verb|<fichier>| est le nom du ou des fichiers à enregistrer, et
303\verb|<message>| une petite ligne susceptible de servir
304d'aide-mémoire:
305\begin{minted}{text}
306[robert@kiddo travail]$ git commit recherche.txt -m "version initiale"
307[master (commit racine) fa1ec00] version initiale
308 1 file changed, 11 insertions(+)
309 create mode 100644 recherche.txt
310\end{minted}
311
312\paragraph{Poursuite du travail}
313Git enregistre tous les \emph{commits} dans un fichier journal, en
314anglais \emph{log file} ou plus simplement \emph{log}. Dans les
315exemples qui suivent, nous avons inséré dans le fichier
316\verb|recherche.txt| donné \vpageref{ref:recherche} les modifications
317correspondant à la deuxième version du fichier.
318
319Comme ce fichier est indexé, la commande \verb|git diff| nous montre
320immédiatement quelles sont les différences (v. plus haut
321\vpageref{ref:diff}):
322\begin{minted}[linenos,escapeinside=||]{text}
323[robert@kiddo travail]$ git diff
324diff --git a/recherche.txt b/recherche.txt
325index 3baf502..f230132 100644
326--- a/recherche.txt
327+++ b/recherche.txt
328|\textcolor{Blue}{@@ -6,6 +6,6 @@}| COMBRAY
329
330 I
331
332|\textcolor{Red}{-Longtemps, je me suis couché très tôt. Parfois, à peine ma}|
333|\textcolor{Red}{-bougie éteinte, mes yeux se fermaient si vite que j'avais juste le}|
334|\textcolor{Green}{+Longtemps, je me suis couché de bonne heure. Parfois, à peine ma}|
335|\textcolor{Green}{+bougie éteinte, mes yeux se fermaient si vite que je n'avais pas le}|
336 temps de me dire: «Je m'endors.»
337\end{minted}
338
339Pour terminer, enregistrons ces modifications:
340\begin{minted}{text}
341[robert@kiddo travail]$ git commit recherche.txt -m "nouvelle version de l'incipit"
342[master 83b6c3e] nouvelle version de l'incipit
343 1 file changed, 2 insertions(+), 2 deletions(-)
344\end{minted}
345
346Et demandons à Git de nous fournir un extrait de son journal:
347\begin{minted}[linenos,escapeinside=||]{text}
348[robert@kiddo travail]$ git log
349|\textcolor{Brown}{commit 83b6c3e6dad72116eac5ce7d1ba70968e4e57ebb}|
350Author: Robert Alessi <alessi@robertalessi.net>
351Date: Wed Oct 3 15:05:32 2018 +0200
352
353 nouvelle version de l'incipit
354
355|\textcolor{Brown}{commit fa1ec001efdca9c69cc768dc9cf83706bdb6e603}|
356Author: Robert Alessi <alessi@robertalessi.net>
357Date: Wed Oct 3 14:49:10 2018 +0200
358
359 version initiale
360\end{minted}
361
362Nous voyons aux lignes~2 et 8 qu'à chaque \emph{commit} est associé un
363\emph{numéro de registre}, en notation hexadécimale, formé d'une
364séquence de~40 caractères allant de \verb|0| à \verb|9| et de \verb|a|
365à \verb|f|.
366
367\subsection{Résumé des commandes}
368\label{sec:resume-des-commandes}
369\begin{enumerate}
370\item \verb|git config --global| $\rightarrow$ paramétrage initial de
371 Git.
372\item \verb|git init| $\rightarrow$ initialisation de Git dans un
373 nouveau répertoire.
374\item \verb|git status| $\rightarrow$ demande à Git un \emph{rapport
375 d'état}.
376\item \verb|git add| $\rightarrow$ indexe des fichiers dans la zone de
377 travail. Les fichiers indexés sont ceux qui seront suivis par
378 Git.
379\item \verb|git commit <fichier> -m "<message>"| $\rightarrow$
380 enregistre dans la base de données de Git les versions modifiées des
381 fichiers sous forme d'instantanés.
382\item \verb|git diff| $\rightarrow$ montre les différences entre la
383 version actuelle des fichiers et leur dernière version enregistrée
384 par %
385 \verb|git commit|.
386\item \verb|git log| $\rightarrow$ affiche le journal de Git.
387\end{enumerate}
388
389\hfill\verb|../.. à suivre|
390
391\end{document}