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 :

Ensuite, avant que git ne vous le demande offi­ciel­le­ment, vous devriez lan­cer ces deux com­mandes, très gitesques :

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 :

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 :

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.

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 :

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".

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).

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.

À 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.

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 !

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 :

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".

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".

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.

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.

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 :

Note impor­tante : avoir un giti­gnore n'est pas obli­ga­toire. Un giti­gnore n'affecte que le dos­sier où il se trouve ain­si que ses sous-dos­siers. Vous pou­vez avoir plu­sieurs giti­gnore.

Conclusion

Les outils de ges­tion de ver­sions comme git sont bien plus simples à uti­li­ser qu'on ne le pense (du moins pour une uti­li­sa­tion de base).

Nous avons vu com­ment créer un dépôt, sélec­tion­ner les fichiers et les réper­toires que l'on veut prendre en compte et enre­gis­trer leurs ver­sions suc­ces­sives. Dans le pro­chain article, nous ver­rons com­ment uti­li­ser git dans un contexte col­la­bo­ra­tif, détec­ter et résoudre les conflits que cela peut entrai­ner, créer des branches et indi­quer les étapes qui cor­res­pondent à des ver­sions.

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

Remerciements

Mer­ci à Haut­bit, NiGo­Pol et Slybzh pour les com­men­taires et dis­cus­sions lors de l'édition de cet article.

À propos de cet article

Cet article et le sui­vant ont étés adap­tés à par­tir d'un cours don­né par Lucas Bour­neuf.

Il a été rédi­gé par Lucas Bour­neuf et Oli­vier Dame­ron.