A l'abri dans ma ''Git''-oune

D'après Wikipedia, le terme guitoune désigne une tente ou un abri de fortune.
Du coup, y a un petit côté camping au mieux ou au pire, un truc fait de bric et de broc.
Ce que j'aime bien avec la tente, c'est le petit côté communautaire si la tente est grande, un peu comme une yourte. En plus, la tente, c'est le truc où on a l'impression d'être à l'écart du monde[1] au milieu de nulle part à profiter de la nature, à s'inventer une existence hors des carcans de notre société uniformisante.
Il y a aussi la tente indienne dans laquelle les personnes importantes du clan se retrouvent autour du shaman qui prédit l'avenir et donne les grandes orientations après avoir bien tiré sur le calumet.
Finalement, tout ça représente assez bien ce dont je vais parler maintenant.
Je vous préviens, c'est dense et chiant à lire :D

Notes

[1] ok, sauf au mois d'août dans un camping des Landes ou de la Côte d'Azur :D

Je vous l'avais promis donc je le fais. Parlons de Git.

Lingua Franca!!

Quand on vit dans une grande tente avec tout pleins de copains ou dans un abri de fortune[1], il est normal de penser à créer une nouvelle société et à adopter de nouveaux rites.
Le mieux est même de prendre le contre-pied total de ce que l'on faisait dans sa vie d'avant.
De là à créer une nouvelle langue, il n'y a qu'un pas... Et ce pas, le créateur de Git l'a franchi[2].
Vous voulez des exemples ? Que dire, des preuves ???!!!
Histoire de rigoler, faisons un tour sur la page Wikipedia anglaise traitant de la gestion des versions dans sa partie sur le vocabulaire commun à ces outils. En effet, deux exemples très intéressants se cachent là-dedans.

  • Checkout
  • Update

A tout seigneur, tout honneur, commençons par Checkout qui se trouve être le premier dans l'alphabet. Que nous dit la définition ?

A check-out (or co) is the act of creating a local working copy from the repository. A user may specify a specific revision or obtain the latest. The term 'checkout' can also be used as a noun to describe the working copy.

Ce terme commun, que l'on retrouve dans moultes systèmes de gestion de version, est utilisé pour désigner l'action de récupérer une révision spécifique depuis le référentiel. Il se trouve que c'est effectivement ce que fait cette commande quand on utilise Subversion, Clearcase, CVS, bazaar[3] ou Monotone.
Par contre, avec Mercurial, Darcs et finalement le grand inspirateur Git, l'équivalent, c'est la commande clone. Pourquoi pas ?
Là où moi, ça me stresse, c'est quand on ré-utilise ce terme pour faire autre chose.
Ben, tiens, justement, en cherchant la commande revert, spécifique à Subversion, Monotone et Mercurial, je me suis rendu compte que sous Git, on utilise... Checkout. Là aussi, pourquoi pas ?
Le seul truc, c'est que cela permet de le faire sur un seul fichier à la fois donc en toute logique, on utilisera la commande reset pour l'ensemble des modifications non committées dans le référentiel.
Finalement, quand un truc a été committé, il y a moyen de réparer grâce à revert... Et oui, enfin, elle existe cette foutue commande !!!
Malgré la petite digression, continuons parce que ce mot Checkout vaut le coup !
Le switch et l'update de Subversion, Mercurial et Monotone, qui permettent de permuter sa copie de travail vers une autre branche, sont devenus, une fois encore, une autre utilisation de Checkout !!
Bon, pourquoi pas ?[4]
Voilà, c'est fini pour Checkout, passons au suivant update.
La définition, s'il vous plait ?

An update (or sync) merges changes made in the repository (by other people, for example) into the local working copy. Update is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see changelist).

Là, au moins, Git est totalement cohérent avec lui-même. Quand on invente une nouvelle langue, le mieux, c'est de retirer des pans entiers de la langue d'origine.
On aura bien vu que globalement, checkout fait ce que fait update fait chez les autres et même plus.

''Lingua Franca'' était donc un titre bien choisi, une langue faite d'emprunts et connaissant de multiples variations :D

J'ai comme une intuition!!

Vous aurez bien remarqué dans le paragraphe précédent à quel point l'utilisation de git est intuitive et constitue bien une évolution des outils l'ayant précédé. Comme c'est une évolution, regardons les seules nouveautés auxquelles j'ai eu à faire où dont j'ai entendu parler.
D'abord le stash, c'est quoi donc ? C'est un coin de git où on stocke temporairement ce qu'on était en train de faire pour attaquer autre chose C'est une sorte de brouillon que l'on met sur le bord de la table parce que Jean-Claude a un truc super urgent à nous faire faire sur la dernière version.
D'aucun diraient que ce n'est pas grave ils ont une deuxième working copy pointant justement sur la dernière version. Ben non, quand on fait du git, on fait tout au même endroit et on commence plein de trucs en même temps. En effet, l'être humain, il est super fort et il sait s'organiser donc il stashe et il dé-stashe comme un bête[5]. Et zou, voilà, après dé-stashe, le codeur il retourne faire ce qui lui plaisait tranquillement... Faut pas l'emmerder le codeur !!
Allez, un lien sur le stashing.

Le codeur, il est très fort mais des fois, malgré ses grandes capacités d'organisation, il fait des trucs pas jolis, jolis et il aimerait pas que ça se voit de trop. D'ailleurs, il aime bien aussi montrer qu'il est super fort et qu'il sait commencer des modifications avant que la fonctionnalité existe. Heureusement, git, il a pensé à son ego au codeur, il a la commande rebase.
Cette commande magnifique lui permet de montrer, comme dans l'exemple ici, qu'il a même pas eu besoin de faire de merge et ainsi il peut garder un bel historique bien linéaire avec le poil soyeux. Ben oui, on a beau faire du distribué et dire que on peut faire des branches comme on veut et forker comme des dingues, montrer qu'on a fait une branche qu'on a dû merger, c'est mal.
Si en plus, comble du sale, on a fait tout pleins de commits pas très bien ordonnés, ça va se voir ?
Et non, rebase est ton ami, toi codeur pas toujours très propre sur toi !!
Un petit coup de ''rebase -i'' et le tour est joué !!
Bon, certains verraient ça comme une modification de l'historique mais là, c'est une fonctionnalité... Au risque de choquer, y a guère que les révisionnistes qui ré-arrangent l'histoire... Enfin, bon, quand on lit que Linus regardait Monotone de très près pour finalement cracher dessus comme un goret[6] (voir , on se dit que la ré-écriture de l'histoire, c'est bien une fonctionnalité :-(

Je vais finir par un ou deux trucs auquels j'ai eu un peu de mal à me faire.
Si vous voulez committer quelque chose, il faut toujours faire un add avant. C'est con mais c'est comme ça, Git ne le tracera pas tout seul. Il faut placer vos changements dans le staging area[7] qui est au final une sorte d'index où vous préparez vos commits. Pour moi, le gros inconvénient de la chose est que si on committe plusieurs centaines de fichiers, on peut louper qu'un fichier n'a pas été ajouté. Pire, si vous modifiez puis ajouté puis re-modifiez, il faut refaire un add.

Et enfin, le ponpon pour la fin. CVS ne savait pas gérer les répertoires correctement dans l'historique et tracer les changements effectués sur ceux-ci ce qui a conduit à l'utilisation de Subversion. Et bien, sachez, mes chers amis, que git ne sait pas le faire non plus !!
Enfin, autant tout le monde hurlait quand CVS ne savait pas le faire, autant on n'entend plus personne là-dessus quand il s'agit de git...

Conclusion!!

Bon, mon expérience avec git, sans avoir été désagréable, n'a pas non plus été la révolution annoncé en termes de gestion de versions. Se familiariser avec la gestion de versions distribuée est déjà une étape en soi pour ce qui est de la compréhension de l'architecture donc si on doit rajouter à ça, l'apprentissage d'un outil qui, bien que très puissant, n'est absolument pas intuitif, bonjour les dégâts.
J'aurais pu parler de la complexité de l'outil vu que le nombre de commandes, d'options, de comportements différents pour une même commande est assez effarant mais je préfère mettre ça sur le compte des nombreuses fonctionnalités. Pour l'anecdote, j'ai un jour lu sur un blog que git ne se composait que de 3 exécutables[8] mais soyons un peu honnêtes, git comporte 21 sous-commandes dont les options peuvent modifier le comportement de façon drastique.
Enfin, il y a une mention spéciale pour les pages de manuel pour leur clarté toute relative mais qui heureusement sont truffées d'exemples.

Bon, quelques recommandations :

  • lisez le git book
  • faites des choses simples
  • utilisez l'outil pour ce qu'il est, une gestion de versions et donc un outil d'aide au développeur pas une fin en soi


Voilà, c'est fini, j'en suis crevé tiens !!

Notes

[1] Comme dans les babas-cool

[2] Vous remarquerez que pour éviter de rameuter un troupeau de zealot, je ne donne pas son nom :)

[3] A vérifier quand même tellement la doc est obscure sur ce point

[4] Vous remarquerez qu'on se rapproche de plus en plus du sketch de la chauve-souris de Bigard avec son Bon bah, admettons !!

[5] Ou K2R qui est bien connu pour être un grand destasheur

[6] Si Linus était fair-play, ça se saurait !

[7] qui n'a rien à voir avec le stash

[8] contre plus d'une centaines dans les premières versions !!

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs