Gérer les versions de vos fichiers : premiers pas avec git

—

par

Article Collaboratif
dans ,
logo Git
Logo de git (http://​git​-scm​.com) Git Logo by Jason Long is licen­sed under the Crea­tive Com­mons Attri­bu­tion 3.0 Unpor­ted License
Git est un logi­ciel de contrôle de ver­sions de fichiers. Il est dis­tri­bué sous licence GNU GPLv2 et est dis­po­nible sur les prin­ci­paux sys­tèmes d'exploitation. Cet article est le pre­mier d'une série de deux. Nous allons voir ici (1) à quoi sert le contrôle de ver­sions, (2) com­ment confi­gu­rer git et (3) les bases de son uti­li­sa­tion. Dans l'article sui­vant, nous ver­rons com­ment clo­ner un pro­jet (par exemple pour tra­vailler à plu­sieurs ou pour faire des sau­ve­gardes) et com­ment syn­chro­ni­ser les dif­fé­rentes copies.

Contexte : le contrôle de versions

Pourquoi faire ?

En bio­in­for­ma­tique comme dans d'autres domaines, nous sommes tous concer­nés par des fichiers/​programmes qui évo­luent, que ce soient nos scripts ou nos fichiers textes per­son­nels. Par­mi les ver­sions suc­ces­sives, on a typi­que­ment besoin d'iden­ti­fier la plus à jour ou celles qui cor­res­pondent à des ver­sions majeures afin de les dis­tin­guer par rap­port à toutes celles qui cor­res­pondent des chan­ge­ments mineurs.
  De plus, l'enchaî­ne­ment des ver­sions n'est pas tou­jours stric­te­ment linéaire et il peut se pro­duire des bran­che­ments où une ver­sion d'un docu­ment sert de point de départ à deux copies qui évo­luent indé­pen­dam­ment l'une de l'autre. Enfin, il est par­fois néces­saire d'aller au delà des ver­sions suc­ces­sives d'un seul docu­ment et d'admi­nis­trer les ver­sions suc­ces­sives de plu­sieurs docu­ments qui cor­res­pondent ensemble à un pro­jet. Les pro­blèmes pré­cé­dents se com­pliquent lorsque l'on a besoin de main­te­nir à jour une copie de ces fichiers à dif­fé­rents endroits ou avec dif­fé­rentes per­sonnes, et c'est encore pire si plu­sieurs de ces per­sonnes peuvent faire des modi­fi­ca­tions et les par­ta­ger à leur tour. Il faut alors gérer la syn­chro­ni­sa­tion et les accès concur­rents.

Logiciels de contrôle de version

Les logi­ciels de contrôle de ver­sions servent pré­ci­sé­ment à gérer les ver­sions suc­ces­sives d'un ensemble de docu­ments, ain­si que leur par­tage, leur mise à jour entre plu­sieurs uti­li­sa­teurs en gérant les conflits poten­tiels lorsque plu­sieurs per­sonnes font des modi­fi­ca­tions concur­rentes sur le même docu­ment. Les plus connus sont CVS, sub­ver­sion (svn), bazaar (bzr), mer­cu­rial, ou git que nous allons pré­sen­ter ici. On a sou­vent une vision un peu rébar­ba­tive des logi­ciels de contrôle de ver­sions alors qu'ils sont en géné­ral simples à prendre en main et se révèlent très utiles. Cet article a jus­te­ment pour but de vous aider à faire le pre­mier pas.
Il existe par ailleurs une quan­ti­té impres­sion­nante de didac­ti­ciels sur git. Sou­vent en anglais, mais pro­mis, nous allons faire un effort ici.
CVS et SVN uti­lisent un modèle en étoile avec un réper­toire maître sur les­quel se font toutes les mises à jour et sur lequel se syn­chro­nise chaque uti­li­sa­teur. Inver­se­ment, mer­cu­rial, bazaar et git reposent sur une approche décen­tra­li­sée : après dupli­ca­tion, la copie a le même sta­tut que l'original (on uti­lise sou­vent la méta­phore du clo­nage).
Ini­tia­le­ment codé par Linus Tor­valds pour gérer les ver­sions de son célèbre noyau, git est aujourd'hui mas­si­ve­ment uti­li­sé dans le monde de l'open-source, notam­ment via des pla­te­formes cen­tra­li­sées (bizarre, hein ?) telles que github ou bit­bu­cket. CVS et SVN étaient la réfé­rence il y a quelques années, et même s'ils res­tent lar­ge­ment uti­li­sés, git est aujourd'hui l'outil de ges­tion de ver­sions le plus clas­sique (on n'a pas dit le meilleur).
Bien sûr, comme nous ne sommes point inté­gristes, un petit encart montre l'équivalent sans git au début de chaque par­tie.
Pour un usage effi­cace d'un tuto­riel, il est géné­ra­le­ment conseillé de faire ce que per­sonne ne fait jamais : repro­duire les com­mandes et autres mani­pu­la­tions chez vous. (pré­sence d'un adulte non néces­saire)
Et, n'oubliez jamais : un ges­tion­naire de ver­sions se sou­vient de tout. NO EXCEPTION

Configurer git une bonne fois pour toutes

Sans git

Rien à faire pour cette étape. Cool, non ?

Avec git

Vous savez ce qu'on dit : un bon outil est dif­fi­cile à prendre en main, mais une fois cela fait rien ne le rem­place. C'est pareil pour git : 3 com­mandes suf­fisent à le confi­gu­rer. Il faut d'abord ouvrir un ter­mi­nal, et ins­tal­ler git :
1
2
3
4
5
6
# Vous pou­vez uti­li­ser les paquets de votre dis­tri­bu­tion, ou à défaut télé­char­ger git depuis http://​git​-scm​.com.
# Ici on se sim­pli­fie la vie et on prend la pre­mière option.
# Adap­tez selon votre dis­tri­bu­tion.
sudo apt-get ins­tall git # debian, ubun­tu et consorts
sudo pac­man -S git # archli­nux
# pour les autres, soit vous savez, soit vous êtes sur mac ou win­dows…
Ensuite, avant que git ne vous le demande offi­ciel­le­ment, vous devriez lan­cer ces deux com­mandes, très gitesques :
1
2
git config –glo­bal user.name "Gérard Men­vu­ça"
git config –glo­bal user.email "super.​gege@​wanadold.​fr"

Pourquoi ?

Parce que c'est ain­si que git vous iden­ti­fie­ra. Après avoir entré ces com­mandes, vous pour­rez voir dans votre fichier ~/.gitconfig que les valeurs sont enre­gis­trées ici… C'est en fait ici que git cher­che­ra si, dans le pro­jet dans lequel vous tra­vaillez, aucune de ces infor­ma­tions n'est ren­sei­gnée. Pour les trois de devant qui suivent : oui, cela per­met d'avoir plu­sieurs iden­ti­tés.

Le cas Windows/​OSX

Git est un pro­gramme suf­fi­sam­ment démo­cra­ti­sé pour se retrou­ver par­tout. Sous tout OS Unix-like (donc OSX aus­si), git est uti­li­sable dans la console, fût-elle bien cachée, et ins­tal­lable d'une manière ou d'une autre. Pour Win­dows, on nous souffle en cou­lisse que Power­shell gère l'affaire avec la même inter­face que les autres. You­pi !

Git pour remplir 2 Gb de RAM

Pour les plus aller­giques à la ligne de com­mande, ou pour ceux qui n'intègrent pas cet outil à leur work­flow, il existe une quan­ti­té impor­tante d'interfaces gra­phiques qui encap­sulent les com­mandes détaillées dans ce tuto. Elles néces­sitent tou­jours une com­pré­hen­sion de ce qu'est git et de ce qu'il fait (du moins cela ne peut que aider), ne vous atten­dez donc pas à vous éco­no­mi­ser la tota­li­té de ce tuto­riel en vous conten­tant d'un cli­co­drôme (d'autant que cer­taines fonc­tion­na­li­tés avan­cées dont vous pour­riez un jour avoir besoin pour­raient néces­si­ter l'intervention en ligne de com­mande).

Créer un projet vide

Sans git

Un mkdir et pouf, c'est fini !

Avec git

Un "git init" et pouf, c'est fini aus­si. On en pro­fi­te­ra pour voir éga­le­ment "git status".

git init

Cette com­mande crée un dépôt (aus­si appe­lé repo­si­to­ry), c'est à dire un réper­toire que git sur­veille­ra et gère­ra, pen­dant que vous y ajou­te­rez ou modi­fie­rez vos fichiers. Dans le jar­gon git, cela se tra­duit par la créa­tion d'un dos­sier caché nom­mé ".git", à l'endroit pré­cis où vous vous trou­vez quand vous lan­cez "git init". Ce réper­toire .git contien­dra toutes les infor­ma­tions sur le dépôt, ain­si que vos confi­gu­ra­tions locales. Cer­taines des (très) nom­breuses options seront abor­dées dans cet article. Les autres, moins impor­tantes, sont faci­le­ment trou­vables sur le net, et, pour vos pre­mières uti­li­sa­tions, il y a peu de chances que vous en ayez besoin :
1
2
3
4
5
6
7
8
9
$ mkdir /​some/​path/​to/​your/​pro­ject # créa­tion du réper­toire
$ cd /​some/​path/​to/​your/​pro­ject # on va dedans
$ ls -a # le réper­toire est bien vide
. ..
$ git init # bon, ben, créons un dépôt git vide ini­tia­li­sé dans /some/path/to/your/project/.git/
$ ls -a # la com­mande "git init" crée un réper­toire caché ".git"
. .. .git
$ ls .git # on jette un oeil dans le réper­toire
branches config des­crip­tion HEAD hooks info objects refs
Comme vous pou­vez le consta­ter, il y a déjà plein de trucs dans le .git alors qu'on n'a encore rien écrit… Rien d'anormal ; c'est comme quand vous venez d'installer un sys­tème : il y a déjà plein de bazar dans des réper­toires inutiles tels que lib, bin ou dev, users, pro­grams,… mais si vous tri­po­tez trop à ce qui s'y trouve sans savoir ce que vous faites, eh bien… vous aurez quelques pro­blèmes avec votre ins­tall. Git c'est pareil. Lais­sez-le gérer ses fichiers, il est meilleur que vous à ce niveau (pour les vôtres aus­si d'ailleurs). Néan­moins, vous serez peut-être ame­nés à modi­fier un peu les fichiers ".git/config" et ".git/description" selon ce que vous vou­drez, plus tard, quand cet article n'aura plus de secrets pour vous.

git status

Cette com­mande ne modi­fie rien, elle ne fait que par­ler. Et pour­tant, vous l'adorerez : elle ren­seigne sur l'état actuel du dépôt. Voyez plu­tôt :
1
2
3
4
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
nothing to com­mit (create/​copy files and use "git add" to track)
Ici, git nous indique clai­re­ment qu'on devrait se mettre au bou­lot. Il dit même com­ment (vous ver­rez, git est très malin à ce petit jeu), ce qui spoile un peu la pro­chaine par­tie de cet article.
Plus tard, cette com­mande nous res­ser­vi­ra. C'est l'occasion de reve­nir sur le réper­toire caché ".git" créé lors du "git init" : lorsque vous faite une com­mande git, par exemple "git status", git va cher­cher le pre­mier réper­toire ".git" qu'il trou­ve­ra en par­tant du réper­toire cou­rant puis en remon­tant suc­ces­si­ve­ment. De fait, lorsque vous serez la tête dans votre pro­jet avec votre pwd quelque part dans la hié­rar­chie, git trou­ve­ra seul le dépôt, et trou­ve­ra les infos néces­saires dans le ".git". Par contre, lorsque vous n'êtes pas dans un dépôt et faites "git status", git va vous ser­mo­ner. La preuve : git est remon­té jusqu'à la racine sys­tème sans trou­ver le moindre ".git".

Principes de base (pour travailler seul(e))

Sans git

Codez. Si vous sup­pri­mez un fichier par erreur : per­dez votre tra­vail et priez pour foremost sans pas­ser par la case départ.
Si vous vou­lez faire des sau­ve­gardes de ver­sion, faites des dumps de dos­siers avec des noms que vous ne com­pren­drez plus dans 2h, et que de toute façon vous ne réuti­li­se­rez jamais, sauf la semaine pro­chaine après le pro­blème de sau­ve­garde ; mais de toute façon vu que vous aviez tout refac­to­ri­sé, autant tout reprendre de zéro : effa­cez les dos­siers de sau­ve­garde faits à la main, allez deman­der de l'aide sur sta­cko­ver­flow. Expli­quez à votre boss que vous n'auriez pas une semaine de retard si mv et rm n'était pas aus­si proches syn­taxi­que­ment, appre­nez l'existance d'un truc qui s'appelle ges­tion­naire de ver­sions, pre­nez peur en lisant la page wiki­pé­dia, décou­vrez cet article. Expi­rez pro­fon­dé­ment, vous êtes sur la bonne voie et tout va déjà mieux.

Avec git

git status

Après la créa­tion du dépôt, "git status" vous disait que tout allait bien, et que la pro­chaine chose à faire est de créer des fichiers, puis d'utiliser "git add". Nous allons donc main­te­nant créer un fichier "firstFile.txt" et voir ce qui se passe.
1
2
3
4
5
$ vi first­File.txt
$ cat first­File.txt
This is the first line of my first file...
... and this is the second line
$
Ici, le fichier est créé à l'aide de vi, mais, évi­dem­ment, vous pou­vez uti­li­ser n'importe quoi : git se contente de com­pa­rer des fichier. Vous pou­vez copier-col­ler un fichier dans votre dépôt ou en créer un en modi­fiant votre disque dur avec un aimant ou un cure-dent, ce sera pareil : git n'a rien à voir avec un édi­teur de fichier, et se contente de com­pa­rer des fichiers quand vous le lui deman­dez. (il existe en réa­li­té une excep­tion, lors de la ges­tion des conflits, qui sera vu plus tard)
Main­te­nant que nous avons créé le fichier, voi­ci la réac­tion de git :
1
2
3
4
5
6
7
8
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Untra­cked files :
(use "git add <file>…" to include in what will be com­mit­ted)
        first­File.txt
nothing added to com­mit but untra­cked files present (use "git add" to track)
 

git add

Dans l'exemple pré­cé­dent, on voit que créer le fichier firstFile.txt dans le dépôt ne suf­fit pas pour que git le prenne en charge auto­ma­ti­que­ment, et qu'il faut pour cela faire un "git add".
1
2
3
4
5
6
7
8
$ git add first­File.txt
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : first­File.txt
$
Cela peut sem­bler inuti­le­ment com­pli­qué et mal­com­mode, mais c'est néces­saire afin d'indiquer quels sont les fichiers inté­res­sants. On ver­ra dans la sec­tion sur .gitignore un peu plus loin com­ment trai­ter les fichiers pas inté­res­sants.
Après avoir expli­ci­te­ment inclus firstFile.txt dans la liste des fichiers que git doit gérer, le der­nier "git status" indique que le fichier est bien pris en compte. À ce stade, git sait qu'il doit sur­veiller ce fichier et il en a pris une empreinte de la ver­sion cou­rante (un snap­shot dans la docu­men­ta­tion en anglais), qu'il stocke dans une zone tem­po­raire appe­lée l'index. Si main­te­nant on modi­fie le fichier firstFile.txt, git sait qu'il doit le sur­veiller et indique que le snap­shot qu'il a pris lors du "git add" n'est plus à jour. Il faut donc faire un nou­veau "git add" pour réac­tua­li­ser le snap­shot. L'exemple sui­vant illustre ce prin­cipe : le pre­mier "git status" reprend l'étape pré­cé­dente et indique que tout va bien ; on modi­fie ensuite le fichier et le "git status" qui suit indique que git dis­pose bien d'un snap­shot dans sa zone tem­po­raire (c'est la ligne "new file: firstFile.txt" qui est simi­laire à ce qu'on avait avant), mais que ce snap­shot n'est plus à jour car le fichier a été modi­fié depuis (ce sont les lignes à par­tir de "Changes not staged for commit:"). On fait de nou­veau un "git add firstFile.txt" pour mettre à jour le snap­shot et le troi­sième git sta­tus montre que tout va bien à nou­veau et que les chan­ge­ments sont prêts pour un commit (cf. sec­tion sui­vante).
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
$ cat first­File.txt
This is the first line of my first file...
... and this is the second line
 
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : first­File.txt
$ vi first­File.txt
$ cat first­File.txt
This is the first line of my first file...
... and this is the second line
Now we add ano­ther line
 
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : first­File.txt
Changes not sta­ged for com­mit :
  (use "git add <file>…" to update what will be com­mit­ted)
  (use "git che­ckout — <file>…" to dis­card changes in wor­king direc­to­ry)
        modi­fied : first­File.txt
$ git add first­File.txt
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : first­File.txt
De même, si on crée de nou­veaux fichiers (par exemple un readme et un fichier de licence) ou de nou­veaux réper­toires, il faut les ajou­ter avec "git add". Il est pos­sible d'ajouter plu­sieurs fichiers avec un seul "git add". L'ajout d'un réper­toire entraine l'ajout auto­ma­tique de tous les fichiers qu'il contient ; les réper­toires vides sont igno­rés.
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
$ ls
first­File.txt
$ vi README.txt
$ vi licence.txt
$ mkdir doc
$ vi doc/​docu­men­ta­tion.txt
$ vi doc/​other­Do­cu­men­ta­tion.txt
$ find . -name .git -a -type d -prune -o -print
.
./​README.txt
./​doc
./​doc/​docu­men­ta­tion.txt
./​doc/​other­Do­cu­men­ta­tion.txt
./​first­File.txt
./​licence.txt
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : first­File.txt
Untra­cked files :
  (use "git add <file>…" to include in what will be com­mit­ted)
        README.txt
        doc/​
        licence.txt
$ git add README.txt licence.txt doc
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : README.txt
        new file : doc/​docu­men­ta­tion.txt
        new file : doc/​other­Do­cu­men­ta­tion.txt
        new file : first­File.txt
        new file : licence.txt
À pro­pos de la dis­cri­mi­na­tion des dos­siers vides, car, diantre ! Cela peut être ennuyeux pour les dos­siers de logs, et il ne s'agit pas d'un bug de fonc­tion­ne­ment : dans la vraie vie réelle de l'internet, il existe plu­sieurs moyens de gar­der un dos­sier vide (comme ici ou là), et c'est a vous de choi­sir votre solu­tion pré­fé­rée (3615 ma life de lucas : j'ai une pré­fé­rence pour le bri­co­lage de .giti­gnore, puisqu'il per­met de spé­ci­fier des pat­terns de fichier à igno­rer, typi­que­ment les fichiers avec une exten­sion log, swp,…). L'usage du giti­gnore sera détaillé plus loin.

git commit (+ git status)

À ce stade, git sur­veille bien les fichiers et en prend des snap­shots, mais l'index où ils sont sto­ckés n'est qu'une zone tem­po­raire. Lorsque les fichiers sont à jour, le "git status" indique qu'ils sont main­te­nant prêts à être archi­vés de façon défi­ni­tive avec un "git commit". Typi­que­ment, on tra­vaille sur cer­tains fichiers en fai­sant des modi­fi­ca­tions (éven­tuel­le­ment plu­sieurs, comme nous l'avons fait aux figures pré­cé­dentes) jusqu'à réus­sir à ajou­ter une nou­velle fonc­tion­na­li­té ou jusqu'à en avoir débug­gué une. Le git commit per­met alors de dire "Voi­là, cette ver­sion des fichiers cor­res­pond à telle action". Cette ver­sion devient la nou­velle ver­sion à jour qui peut être par­ta­gée.
Remar­quez que le seul chan­ge­ment de ver­sion "offi­cielle" se fait d'un com­mit à l'autre, sans que per­sonne ne voit la longue série de modi­fi­ca­tions plus ou moins habiles qui figu­rait dans les "git add" et qui vous a per­mis d'y par­ve­nir.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ git sta­tus
On branch mas­ter
Ini­tial com­mit
Changes to be com­mit­ted :
  (use "git rm –cached <file>…" to uns­tage)
        new file : README.txt
        new file : doc/​docu­men­ta­tion.txt
        new file : doc/​other­Do­cu­men­ta­tion.txt
        new file : first­File.txt
        new file : licence.txt
$ git com­mit -m "First com­mit"
[mas­ter (root-com­mit) e26b158] First com­mit
5 files chan­ged, 10 inser­tions(+)
create mode 100644 README.txt
create mode 100644 doc/​docu­men­ta­tion.txt
create mode 100644 doc/​other­Do­cu­men­ta­tion.txt
create mode 100644 first­File.txt
create mode 100644 licence.txt
$ git sta­tus
On branch mas­ter
nothing to com­mit, wor­king direc­to­ry clean
Le para­mètre -m per­met d'indiquer un mes­sage décri­vant (briè­ve­ment) la fonc­tion­na­li­té que vous avez ajou­tée ou celle que vous avez amé­lio­rée ou cor­ri­gée. Il faut que ce mes­sage soit concis et infor­ma­tif (bon, ce n'est pas facile sur le pre­mier commit). Si vous pen­sez qu'il faut don­ner des détails, com­men­cez quand même par une phrase brève, lais­sez une ligne blanche, puis racon­tez ce que vous vou­lez.
Si vous ne don­nez pas l'option m et le mes­sage de com­mit, git va appe­ler votre édi­teur de texte par défaut (sou­vent nano si vous n'avez rien chan­gé, défi­nit par la variable d'environnement $EDITOR), ou un autre si vous avez uti­li­sé la com­mande "git config --global core.editor "vim"" ou équi­valent. Une fois démar­ré, l'éditeur de texte vous lais­se­ra écrire le mes­sage de com­mit.
Un paral­lèle avec l'industrie du bâti­ment est pos­sible : ima­gi­nez un com­mit comme une brique uti­li­sée pour construire un mur. C'est l'ensemble des briques posées les unes sur les autres qui rendent le pro­jet final. Plus tard, nous ver­rons qu'il est pos­sible de clo­ner un mur en construc­tion pour appo­ser ses propres briques, et de pro­po­ser ensuite une fusion des murs : le début du tra­vail col­la­bo­ra­tif.
Pour réca­pi­tu­ler, il faut donc faire une com­bi­nai­son d'une suite de "git add" pour ajou­ter les fichiers per­ti­nents à l'index, et "git commit" pour vali­der les chan­ge­ments des fichiers de l'index.
Lorsque vous com­men­cez à savoir ce que vous faites, un "git commit -a -m" com­bine les deux com­mandes pré­cé­dentes en ajou­tant les fichiers qui ont chan­gé (mais pas les nou­veaux) à l'index et en les vali­dant. Il est donc aisé de com­mi­ter plu­sieurs fichiers simul­ta­né­ment. Néan­moins, cela va à l'encontre de la phi­lo­so­phie de git : un com­mit devrait tou­jours être une modi­fi­ca­tion ato­mique, pas une pleine brouette de code désor­ga­ni­sée et obèse. Une excep­tion notable est cepen­dant lorsque vous créez un dépôt pour un pro­jet, comme Linus avant tous, le pre­mier commit (nom­mé sou­vent "initial commit") est géné­ra­le­ment un gros dump de ce qui a été fait aupa­ra­vant. Par exemple, cela per­met sim­ple­ment de suivre avec un échan­tillon­nage éle­vé l'évolution d'un pro­jet, et donc de contrô­ler faci­le­ment les ajouts de fonc­tion­na­li­tés, les ver­sions,… Exac­te­ment ce pour­quoi git existe. Et en plus c'est mieux pour faire de jolis gra­phiques !
Graphe d'activité du dépôt git du projet Julia
Graphe d'activité du dépôt git du pro­jet Julia
Donc : pré­fé­rez des commits ato­miques et simples, tou­chant le mini­mum de fichiers à chaque fois, avec un mes­sage de commit qui répond au pour­quoi, et non au com­ment dont la réponse est déjà dans le commit. Le dépôt du lan­gage Julia pré­sen­té dans un autre article est un bon exemple : des mil­liers de commits, et même les tous pre­miers sont ato­miques :
1
2
3
$ git clone https :/​/​github.com/​Julia­Lang/​julia
$ cd julia
$ git log –reverse # affi­cher les com­mits du plus ancien au plus récent

git log pour suivre l'historique des commit

La com­mande "git log" vous per­met de lis­ter l'auteur, la date et la des­crip­tion suc­cinte (celle qui figu­rait après le ‑m) des "git commit" suc­ces­sifs. La com­mande git log méri­te­rait un tuto à elle toute seule. Dans un pre­mier temps, la connaitre et l'utiliser sans argu­ments suf­fit lar­ge­ment. Disons que les trois lignes pré­cé­dentes seront votre pre­mier TP, si par mal­heur vous ne repro­dui­sez pas le tuto à la lec­ture.

git diff

Au cours du cycle typique "modi­fi­ca­tion de fichier(s) <-> git add  <-> git commit", git per­met plu­sieurs points de contrôle (le "git add" met à jour l'index tem­po­raire et le "git commit" met à jour le dépôt à par­tir de l'index) et on peut avoir besoin d'analyser ce qui a chan­gé de l'un à l'autre grâce à la com­mande "git diff".
  • Par défaut, "git diff" per­met de com­pa­rer la ver­sion cou­rante du fichier avec la der­nière ver­sion prise en compte par l'index (donc ce qui a chan­gé dans la ver­sion actuelle du fichier depuis le der­nier "git add")
  • Par contre, "git diff --cached" per­met de com­pa­rer la der­nière ver­sion prise en compte par l'index avec l'état lors du der­nier com­mit (donc ce qui va être modi­fié lors du pro­chain commit)
Il faut bien remar­quer qu'on ne com­pare jamais la ver­sion actuelle du fichier avec celle du der­nier commit, mais ce n'est pas très grave puisqu'il faut de toutes façons pas­ser par un "git add" entre les deux. Pour bien détailler toutes ces étapes, on va faire une pre­mière modi­fi­ca­tion dans un fichier, faire un "git add" pour mettre à jour l'index, puis faire une seconde modi­fi­ca­tion. On voit que le "git diff" montre bien la ver­sion cou­rante du fichier, mais ne met en valeur que la seconde modi­fi­ca­tion, alors que "git diff --cached" ne montre et ne met en valeur que la pre­mière modi­fi­ca­tion et ignore la seconde. Si ça vous semble nor­mal, c'est que vous avez bien assi­mi­lé le prin­cipe de git ; sinon reli­sez les sec­tions sur "git add" et "git commit".
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
$ cat first­File.txt
This is the first line of my first file...
... and this is the second line
Now we add ano­ther line
 
$ git sta­tus
On branch mas­ter
nothing to com­mit, wor­king direc­to­ry clean
$ echo "Adding a fourth line" >> first­File.txt
$ git sta­tus
On branch mas­ter
Changes not sta­ged for com­mit :
  (use "git add <file>…" to update what will be com­mit­ted)
  (use "git che­ckout — <file>…" to dis­card changes in wor­king direc­to­ry)
        modi­fied : first­File.txt
no changes added to com­mit (use "git add" and/​or "git com­mit ‑a")
$ git diff
diff –git a/​first­File.txt b/​first­File.txt
index 9a4e002..d5078b7 100644
–- a/​first­File.txt
+++ b/​first­File.txt
@@ -3,3 +3,4 @@ This is the first line of my first file...
Now we add ano­ther line
 
+Adding a fourth line
$ git add first­File.txt
$ git sta­tus
On branch mas­ter
Changes to be com­mit­ted :
  (use "git reset HEAD <file>…" to uns­tage)
        modi­fied : first­File.txt
$ git diff
$ git diff –cached
diff –git a/​first­File.txt b/​first­File.txt
index 9a4e002..d5078b7 100644
–- a/​first­File.txt
+++ b/​first­File.txt
@@ -3,3 +3,4 @@ This is the first line of my first file...
Now we add ano­ther line
+Adding a fourth line
$ echo "Adding a fifth line" >> first­File.txt
$ git diff
diff –git a/​first­File.txt b/​first­File.txt
index d5078b7..ba75664 100644
–- a/​first­File.txt
+++ b/​first­File.txt
@@ -4,3 +4,4 @@ Now we add ano­ther line
Adding a fourth line
+Adding a fifth line
$ git diff –cached
diff –git a/​first­File.txt b/​first­File.txt
index 9a4e002..d5078b7 100644
–- a/​first­File.txt
+++ b/​first­File.txt
@@ -3,3 +3,4 @@ This is the first line of my first file...
Now we add ano­ther line
+Adding a fourth line
$ git com­mit -m "this com­mit only adds the fourth line ; the fifth is igno­red as it is not yet in the index"
[mas­ter 61b5f1d] this com­mit only adds the fourth line ; the fifth is igno­red as it is not yet in the index
1 file chan­ged, 1 inser­tion(+)
$ git sta­tus
On branch mas­ter
Changes not sta­ged for com­mit :
  (use "git add <file>…" to update what will be com­mit­ted)
  (use "git che­ckout — <file>…" to dis­card changes in wor­king direc­to­ry)
        modi­fied : first­File.txt
no changes added to com­mit (use "git add" and/​or "git com­mit ‑a")
$ git diff
diff –git a/​first­File.txt b/​first­File.txt
index d5078b7..ba75664 100644
–- a/​first­File.txt
+++ b/​first­File.txt
@@ -4,3 +4,4 @@ Now we add ano­ther line
Adding a fourth line
+Adding a fifth line
$ git diff –cached
$
Le der­nier "git status" indique que firstFile.txt a été modi­fié depuis le der­nier snap­shot (ben oui, on vient d'y ajou­ter suc­ces­si­ve­ment deux lignes pour illus­trer "git diff" et "git diff --cached"). On en pro­fite pour mettre de l'ordre tout en réca­pi­tu­lant avec un "git add" pour mettre le snap­shot à jour, puis un "git commit".
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ git sta­tus
On branch mas­ter
Changes not sta­ged for com­mit :
  (use "git add <file>…" to update what will be com­mit­ted)
  (use "git che­ckout — <file>…" to dis­card changes in wor­king direc­to­ry)
        modi­fied : first­File.txt
no changes added to com­mit (use "git add" and/​or "git com­mit ‑a")
$ git add first­File.txt
$ git sta­tus
On branch mas­ter
Changes to be com­mit­ted :
  (use "git reset HEAD <file>…" to uns­tage)
        modi­fied : first­File.txt
$ git com­mit -m "added two more lines to explain how git diff works"
[mas­ter fcae267] added two more lines to explain how git diff works
1 file chan­ged, 1 inser­tion(+)
$ git sta­tus
On branch mas­ter
nothing to com­mit, wor­king direc­to­ry clean
$

gitignore

Dans un pro­jet, il y a des fichiers ou des réper­toires qu'il n'est pas utile d'archiver ou de par­ta­ger comme par exemple des fichiers inter­mé­diaires de com­pi­la­tion, des fichiers de log, les fichiers .bak géné­rés par cer­tains édi­teurs… Tant qu'on ne les ajoute pas grâce à un "git add" ce n'est pas bien grave, mais ils ont quand même l'inconvénient de pol­luer les "git status". De plus, on a vu pré­cé­dem­ment que lors d'un "git add" sur un réper­toire, git ajoute à l'index tous les fichiers du réper­toire, y com­pris les fichiers indé­si­rables.
En plus des fichiers inutiles, il est éga­le­ment bon d'éviter d'ajouter des fichiers binaires ou des fichiers com­pres­sés à un pro­jet si ceux-ci peuvent être amme­nés à chan­ger. En effet, git est bien adap­té aux fichiers textes mais pas trop aux autres types de fichiers (c'est logique, sou­ve­nez-vous du git diff de la sec­tion pré­cé­dente). Nor­ma­le­ment, à chaque modi­fi­ca­tion, git ne stocke que ce qui a chan­gé depuis la der­nière ver­sion. Dans le cas des fichiers binaires, il est donc obli­gé de sto­cker la ver­sion com­plète du fichier à chaque modi­fi­ca­tion, ce qui conduit rapi­de­ment à une aug­men­ta­tion impor­tante de la taille du dépôt.
Il est pos­sible d'indi­quer à git qu'il doit igno­rer cer­tains fichiers (en don­nant leur nom), ou cer­tains types de fichiers (à l'aide d'expressions régu­lières). Pour cela, créez un fichier nom­mé ".gitignore" à la racine du pro­jet (dans le réper­toire où il y a aus­si le réper­toire ".git" géné­ré lors du "git init"). Dans le fichier ".gitignore", met­tez un nom de fichier ou une expres­sion régu­lière par ligne.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ git sta­tus
On branch mas­ter<br>nothing to com­mit, wor­king direc­to­ry clean
$ touch first­File.txt.bak
$ mkdir log
$ touch log/​example.log
$ touch log/​example.log.gz
$ git sta­tus
On branch mas­ter<br>Untra­cked files :
  (use "git add <file>…" to include in what will be com­mit­ted)
        first­File.txt.bak
        log/​
nothing added to com­mit but untra­cked files present (use "git add" to track)
$ vi .giti­gnore
$ cat .giti­gnore
*.bak
log/​
$ On branch mas­ter
Untra­cked files :
  (use "git add <file>…" to include in what will be com­mit­ted)
        .giti­gnore
nothing added to com­mit but untra­cked files present (use "git add" to track)
$ ls -a
. .. doc first­File.txt first­File.txt.bak .git .giti­gnore licence.txt log README.txt
 
Le der­nier "git status" indique deux choses :
  • les fichiers se ter­mi­nant en ".bak" et le réper­toire "log" existent bien mais sont igno­rés par git confor­mé­ment au conte­nu du fichier ".gitignore"
  • le fichier ".gitignore" est trai­té par git comme un fichier nor­mal (on va déve­lop­per ce point dans le pro­chain para­graphe) et il nous faut donc faire un "git add" afin que git l'ajoute au dépôt, sur­veille ses modi­fi­ca­tions et le par­tage éven­tuel­le­ment avec d'autres uti­li­sa­teurs.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git add .giti­gnore
$ git sta­tus
On branch mas­ter
Changes to be com­mit­ted :
  (use "git reset HEAD <file>…" to uns­tage)
        new file : .giti­gnore
$ git com­mit -m "added a .giti­gnore file to ignore backup files and the log direc­to­ry"
[mas­ter 7deabd7] added a .giti­gnore file to ignore backup files and the log direc­to­ry
1 file chan­ged, 2 inser­tions(+)
create mode 100644 .giti­gnore
$ git sta­tus
On branch mas­ter
nothing to com­mit, wor­king direc­to­ry clean<
$
Il faut bien com­prendre que le conte­nu du fichier ".gitignore" est lu par git et qu'il indique les fichiers dont git ne tient pas compte lors de la mise à jour de l'index. Si vous avez l'esprit taquin, vous pou­vez évi­dem­ment men­tion­ner ".gitignore" dans votre ".gitignore". Git conti­nue­ra bien à en lire le conte­nu, mais n'ajoutera sim­ple­ment pas votre ".gitignore" à l'index.
Ce n'est sans doute pas une bonne idée si plu­sieurs per­sonnes col­la­borent au pro­jet. En effet, vos par­te­naires ne récu­pè­re­ront donc pas votre ".gitignore" avec les autres fichiers du pro­jet. Ils risquent alors d'ajouter des fichiers indé­si­rables lorsqu'ils feront un "git commit" (mais grâce à la nature décen­tra­li­sée de git, vous aurez quand même le loi­sir de reje­ter leur commit, il vous fau­dra juste refaire le ménage à la main).
On a évi­dem­ment ten­dance à conser­ver les mêmes .gitignore d'un pro­jet à l'autre, donc c'est un bon inves­tis­se­ment. Il existe éga­le­ment des géné­ra­teurs de .gitignore qui vous aident dans cette tâche.
Une appli­ca­tion très par­lante du giti­gnore dans tout pro­jet Python est d'ignorer l'ensemble des fichiers issus de la com­pi­la­tion :
*.pyc
__pycache__/
On peut également utiliser le gitignore pour conserver un dossier vide, comme expliqué dans la partie dédiée à git add, tout en évitant de tracker l'ensemble des fichiers de logs.

Note importante : avoir un gitignore n'est pas obligatoire. Un gitignore n'affecte que le dossier où il se trouve ainsi que ses sous-dossiers. Vous pouvez avoir plusieurs gitignore.

 

Conclusion

Les outils de gestion de versions comme git sont bien plus simples à utiliser qu'on ne le pense (du moins pour une utilisation de base).

Nous avons vu comment créer un dépôt, sélectionner les fichiers et les répertoires que l'on veut prendre en compte et enregistrer leurs versions successives. Dans le prochain article, nous verrons comment utiliser git dans un contexte collaboratif, détecter et résoudre les conflits que cela peut entrainer, créer des branches et indiquer les étapes qui correspondent à des versions.

L'excellent site first aid git recense les questions les plus fréquentes sur git (et leurs réponses)

Remerciements


Merci à Hautbit, NiGoPol et Slybzh pour les commentaires et discussions lors de l'édition de cet article.


À propos de cet article

Cet article et le suivant ont étés adaptés à partir d'un cours donné par Lucas Bourneuf.

Il a été rédigé par Lucas Bourneuf et Olivier Dameron.

Article Collaboratif

Pour continuer la lecture :

Commentaires

4 réponses à “Gérer les versions de vos fichiers : premiers pas avec git”

  1. Avatar de Pierre Marijon
    Pierre Marijon

    On aurait pu aus­si par­ler de forge logi­ciel (site pro­po­sant les mêmes fonc­tion­na­li­tés que github) libre, je cite­rais mais ce ne sont pas les seuls :

    * git­lab http://​git​lab​.org/ une ins­tance tenue par fra­ma­soft : https://​git​.fra​ma​soft​.org/
    * gogs http://​gogs​.io/ la démo : https://​try​.gogs​.io/

    Il y en a bien d'autres et beau­coup que j'ai vu pas­sé mais ne retrouve plus le nom, l'offre de forge logi­ciel est assez impres­sion­nante.

    Pour ceux qui vou­draient retrou­ver l'aspect décen­tra­li­sé de git je vous conseille d'aller voir du coté de git­chan http://​git​chain​.org/

    Répondre
  2. Avatar de Serious Lee
    Serious Lee

    Très bon tuto. Un petit first​File​.py à un moment sème le doute 😉

    Répondre
    1. Avatar de ZaZo0o
      ZaZo0o

      Bien vu 😉
      C'est cor­ri­gé !

      Répondre
  3. Avatar de hedjour
    hedjour

    Pour mémoire et ceux qui n'en ont pas 😉

    Répondre

Laisser un commentaire