Versionner son code avec Git : pourquoi et comment s’y mettre

Un dos­sier nom­mé « projet_final ». Puis « projet_final_v2 ». Puis « projet_final_v2_vraiment_final ». Puis « projet_final_v2_vraiment_final_CORRIGE ». Ça vous parle ? A moi oui ! A par­tir du moment où on fait cela, c’est qu’on res­sent le besoin de ver­sion­ner son travail.

Qu’est-ce que le versionning ?

Le ver­sion­ning c’est le fait de gar­der une trace de l’é­vo­lu­tion d’un pro­jet dans le temps. Il s’a­git de pou­voir répondre à des ques­tions simples mais essen­tielles : à quoi res­sem­blait ce fichier la semaine der­nière ? Qu’est-ce qui a chan­gé entre deux ver­sions ? Qui a modi­fié cette ligne, et pour­quoi ? Com­ment reve­nir à un état qui fonc­tion­nait avant que je ne casse tout ?

On peut ver­sion­ner « à la main », en dupli­quant des dos­siers ou en renom­mant des fichiers avec des dates ou des numé­ros. Mais cette méthode peut deve­nir très vite ingé­rable : les dos­siers s’ac­cu­mulent, on ne sait plus quelle ver­sion est la bonne et il est impos­sible de savoir pré­ci­sé­ment ce qui a chan­gé entre deux copies, sans les com­pa­rer fichier par fichier.

C’est pour résoudre ce pro­blème qu’existent les sys­tèmes de contrôle de ver­sion, ou VCS (Ver­sion Control Sys­tem) : des outils conçus spé­ci­fi­que­ment pour suivre l’his­to­rique d’un pro­jet de façon fiable, pré­cise et auto­ma­ti­sée. Git est aujourd’­hui le plus uti­li­sé d’entre eux. Git est celui dont j’ai sur­tout enten­du par­ler et celui que j’u­ti­lise. Mais il existe aus­si SVN (ou Sub­ver­sion) qui est uti­li­sé dans l’é­co­sys­tème WordPress.

Qu’est-ce que Git ?

Git est un sys­tème de contrôle de ver­sion décen­tra­li­sé, créé en 2005 par Linus Tor­valds, le créa­teur de Linux. Git per­met d’en­re­gis­trer l’é­tat d’un pro­jet à dif­fé­rents moments, sous forme « d’ins­tan­ta­nés » qu’on appelle des com­mits, et qui per­met de navi­guer entre ces instantanés.

Voi­ci quelques notions qui per­mettent de com­prendre com­ment Git orga­nise cela. 

1. Le dépôt, qu’on appelle aus­si repo­si­to­ry, ou encore « repo ») est l’en­droit où Git stocke tout l’his­to­rique du pro­jet : chaque com­mit, chaque modi­fi­ca­tion, chaque mes­sage asso­cié. Un com­mit est une pho­to­gra­phie de l’é­tat du pro­jet à un ins­tant T, accom­pa­gnée d’un mes­sage qui explique ce qui a changé.
2. Une branche est une ligne de déve­lop­pe­ment indé­pen­dante, déta­chée de la branche prin­ci­pale (qu’on appelle branche mas­ter) : elle per­met de tra­vailler sur une fonc­tion­na­li­té ou une cor­rec­tion sans tou­cher à la ver­sion prin­ci­pale du pro­jet, puis de fusion­ner ce tra­vail une fois qu’il est prêt. Cela per­met ain­si de tes­ter quelque chose sans tou­cher au code principal.

Quand on parle de Git on doit aus­si par­ler de GitHub, Git­Lab ou Bit­bu­cket. Git est l’ou­til qui gère les ver­sions sur votre machine, en local. GitHub, Git­Lab et Bit­Bu­cket sont des pla­te­formes en ligne qui hébergent des dépôts Git et qui faci­litent le tra­vail en équipe. Elles ajoutent des fonc­tion­na­li­tés comme les demandes de fusion (pull requests) ou le sui­vi de bugs. 

Dans quels métiers utilise-t-on le versionning ?

Le ver­sion­ning avec Git est deve­nu un réflexe stan­dard dans les métiers qui pro­duisent du code ou des fichiers texte ame­nés à évo­luer dans le temps. Les dév. web, qu’ils ou elles tra­vaillent côté front-end ou back-end, sont les pre­mières per­sonnes concer­nées. Tout comme celles qui déve­loppent des appli­ca­tions mobiles ou desk­top et, plus lar­ge­ment, les ingé­nieurs logi­ciels de tous horizons.

Mais le ver­sion­ning est aus­si uti­li­sé par les data scien­tists mais aus­si par les ingé­nieurs DevOps en par­ti­cu­lier pour gérer les déploie­ments.

La docu­men­ta­tion tech­nique peut être éga­le­ment ver­sion­née avec Git, dès lors qu’elle est écrite sous forme de fichiers texte Mark­down par exemple, plu­tôt que dans un trai­te­ment de texte classique.

Ces dif­fé­rents métiers ont un point com­mun : dès qu’un tra­vail se com­pose de fichiers texte qui changent sou­vent, sont relus, cor­ri­gés, ou pro­duits à plu­sieurs mains, Git apporte une réponse adap­tée.

Pourquoi versionner son code ?

Les béné­fices du ver­sion­ning avec Git sont nombreux.

D’a­bord, Git offre un his­to­rique com­plet et tra­çable de chaque modi­fi­ca­tion. Chaque com­mit garde une trace de ce qui a chan­gé, quand, et si le mes­sage est bien écrit, pour­quoi. Ensuite, il per­met de reve­nir en arrière en cas de bug ou d’er­reur : plu­tôt que de cher­cher déses­pé­ré­ment ce qui a cas­sé le pro­jet, on peut com­pa­rer les ver­sions suc­ces­sives et iden­ti­fier pré­ci­sé­ment le com­mit fautif.

Git faci­lite éga­le­ment le tra­vail en équipe. Plu­sieurs per­sonnes peuvent tra­vailler sur le même pro­jet en paral­lèle, cha­cune sur sa propre branche, avant que leurs contri­bu­tions ne soient fusion­nées. Git gère lui-même la fusion dans la majo­ri­té des cas, et signale les conflits lorsque deux modi­fi­ca­tions se che­vauchent, pour qu’on puisse les résoudre à la main.

Le sys­tème de branches per­met aus­si d’ex­pé­ri­men­ter sans prendre de risque : on peut tes­ter une idée, une nou­velle fonc­tion­na­li­té, sans tou­cher au code prin­ci­pal qui fonc­tionne. Si l’ex­pé­ri­men­ta­tion échoue, il suf­fit d’a­ban­don­ner la branche, sans aucune consé­quence sur le reste du projet.

Enfin, dès lors que le dépôt est aus­si héber­gé en ligne, Git offre une forme de sau­ve­garde et de redon­dance : le code n’existe plus uni­que­ment sur une seule machine, ce qui pro­tège contre une panne de disque dur, un vol d’or­di­na­teur ou une simple fausse manipulation.

Pourquoi versionner même quand on travaille seul

On asso­cie sou­vent Git au tra­vail en équipe, au point d’en conclure, à tort, qu’il ne sert à rien quand on déve­loppe seul. C’est une erreur : les béné­fices du ver­sion­ning res­tent valables sur un pro­jet solo. Je tra­vaille la plu­part du temps seule et, depuis plu­sieurs années, je ver­sionne mon travail.

Pour moi c’est un filet de sécu­ri­té. Per­sonne n’est à l’a­bri d’une modi­fi­ca­tion mal­heu­reuse, une sup­pres­sion acci­den­telle : grâce à Git, il est tou­jours pos­sible de reve­nir à un état anté­rieur stable, sans avoir à tout recons­truire de mémoire. Cela per­met aus­si de savoir où on en était quand on a fer­mé l’or­di­na­teur, la veille.

Le ver­sion­ning sert aus­si à docu­men­ter ses propres choix. Un mes­sage de com­mit bien écrit explique, pour­quoi telle ou telle déci­sion a été prise. Six mois plus tard, en retom­bant sur une por­tion de code qu’on avait oubliée, l’his­to­rique des com­mits per­met de recons­ti­tuer le rai­son­ne­ment d’o­ri­gine, ce que le code seul ne dit pas toujours.

Les branches sont utiles en solo aus­si : elles per­mettent de tra­vailler sur plu­sieurs pistes en paral­lèle sans tout mélan­ger. Per­son­nel­le­ment je ne les uti­lise pas souvent.

Si le dépôt est pous­sé sur une pla­te­forme comme GitHub, Bit­Bu­cket ou Git­Lab il béné­fi­cie en outre d’une sau­ve­garde à dis­tance : on retrouve son code en cas de panne de disque, un vol d’or­di­na­teur, ou toute autre catas­trophe locale.

Enfin, ver­sion­ner dès le début, c’est pré­pa­rer l’a­ve­nir. Un pro­jet solo peut deve­nir col­la­bo­ra­tif à un moment ou un autre : on cherche de l’aide, on embauche un déve­lop­peur, on trans­met le pro­jet à quel­qu’un d’autre. Et même sans cela, on rede­vient soi-même, six mois plus tard. Un his­to­rique Git propre est un cadeau qu’on se fait à soi-même dans le futur.

Quels outils utiliser pour versionner avec Git

Le terminal

La ligne de com­mande est la façon la plus directe d’u­ti­li­ser Git. Elle demande un temps d’ap­pren­tis­sage, mais elle offre un contrôle total sur ce qu’on fait, et elle aide à vrai­ment com­prendre la logique de Git. En uti­li­sant une inter­face où on clique sur des bou­tons, on peut ne pas com­prendre ce qu’on fait exactement. 

Voi­ci les com­mandes de base à connaître pour démarrer :

- git init ini­tia­lise un nou­veau dépôt Git dans le dos­sier cou­rant. C’est la toute pre­mière com­mande à lan­cer pour com­men­cer à ver­sion­ner un projet.

- git clone <url> récu­père une copie com­plète d’un dépôt existant.

- git sta­tus affiche l’é­tat actuel du dépôt : quels fichiers ont été modi­fiés, les­quels sont prêts à être enre­gis­trés, les­quels ne sont pas sui­vis par Git.

- git add <fichier> ajoute un fichier modi­fié à la « zone de pré­pa­ra­tion » (sta­ging), c’est-à-dire à la liste des chan­ge­ments qui seront inclus dans le pro­chain com­mit. « git add .«  ajoute tous les fichiers modi­fiés d’un coup.

- git com­mit ‑m + votre mes­sage entre guille­mets enre­gistre un ins­tan­ta­né des chan­ge­ments ajou­tés, accom­pa­gné d’un mes­sage décri­vant ce qui a été fait.

- git push envoie les com­mits enre­gis­trés en local vers le dépôt dis­tant, pour les sau­ve­gar­der en ligne.

- git pull récu­père et intègre les der­niers chan­ge­ments pré­sents sur le dépôt dis­tant vers la copie locale.

- git log affiche l’his­to­rique des com­mits : qui a com­mi­té quoi, quand, avec quel message.

Ces huit com­mandes suf­fisent lar­ge­ment pour cou­vrir l’u­sage quo­ti­dien de Git sur un pro­jet, seul ou en petite équipe.

Vous pou­vez retrou­ver toutes les com­mandes sur le site offi­ciel Git

Les interfaces graphiques

Vous pré­fè­re­rez peut-être une approche plus visuelle, pour cela il existe des inter­faces gra­phiques dédiées à Git. Sour­ce­tree par exemple est gra­tuit : l’ou­til affiche l’arbre des branches sous forme de gra­phique et per­met de visua­li­ser les dif­fé­rences entre deux ver­sions d’un fichier. Il rend les opé­ra­tions de fusion ou de réso­lu­tion de conflits plus lisibles qu’en ligne de commande.

D’autres outils existent dans le même esprit : GitHub Desk­top, plus mini­ma­liste et pen­sé pour les débu­tants, Git­Kra­ken, plus riche visuel­le­ment, ou encore l’in­té­gra­tion Git direc­te­ment pré­sente dans des édi­teurs comme Visual Stu­dio Code, ce qui est pra­tique parce qu’elle évite de chan­ger d’application.

Une bonne pra­tique serait d’ap­prendre les bases en ligne de com­mande pour bien com­prendre ce que fait réel­le­ment Git, puis à uti­li­ser un outil gra­phique comme Sour­ce­tree au quo­ti­dien si vous pré­fé­rez le confort visuel. Un gra­phique est sou­vent plus par­lant qu’une série de lignes de texte.

J’ai appris à uti­li­ser Git sur le site Gra­fi­kart.

Bien nommer ses commits

Un his­to­rique de com­mits n’a de valeur que s’il est lisible. Un dépôt Git rem­pli de mes­sages comme « fix » ou « update » ne raconte rien : il faut rou­vrir chaque com­mit un par un pour com­prendre ce qui a réel­le­ment chan­gé. À l’in­verse, un his­to­rique bien écrit fonc­tionne comme une docu­men­ta­tion vivante du pro­jet, par­ti­cu­liè­re­ment utile en solo pour se relire des mois plus tard.

La règle la plus simple à adop­ter consiste à rédi­ger chaque mes­sage de com­mit comme une ins­truc­tion, à l’im­pé­ra­tif, sui­vie d’une des­crip­tion courte et pré­cise de ce qui a été fait. On écrit par exemple « Cor­rige l’af­fi­chage du hea­der sur mobile » plu­tôt que « fix hea­der », ou « Ajoute la vali­da­tion du for­mu­laire de contact » plu­tôt que « update ». L’i­dée est qu’en lisant le mes­sage seul, sans avoir à ouvrir le code, on com­prenne immé­dia­te­ment ce que ce com­mit a chan­gé. Mais ce n’est pas for­cé­ment évident !

Ain­si, le ver­sion­ning n’est pas réser­vé aux grosses équipes de déve­lop­pe­ment ni aux pro­jets com­plexes. Que l’on tra­vaille sur un site vitrine, une appli­ca­tion per­son­nelle ou un pro­jet pro­fes­sion­nel de grande ampleur, Git offre un filet de sécu­ri­té et un his­to­rique clair.

La meilleure façon de s’y mettre reste la plus simple : ini­tia­li­ser un dépôt Git dès le pro­chain pro­jet, même le plus modeste, avec un git init et un pre­mier com­mit. Le reste s’ap­prend en pra­ti­quant, com­mit après commit.