215 lines
18 KiB
HTML
215 lines
18 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="fr">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<title>YBlog - Usages non dits de Git</title>
|
||
<meta name="keywords" content="git, dcvs, programming" />
|
||
|
||
<link rel="shortcut icon" type="image/x-icon" href="../../../../Scratch/img/favicon.ico" />
|
||
<link rel="stylesheet" type="text/css" href="../../../../css/y.css" />
|
||
<link rel="stylesheet" type="text/css" href="/css/legacy.css" />
|
||
<link rel="alternate" type="application/rss+xml" title="RSS" href="/rss.xml" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<link rel="apple-touch-icon" href="../../../../Scratch/img/about/FlatAvatar@2x.png" />
|
||
<!--[if lt IE 9]>
|
||
<script src="http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE9.js"></script>
|
||
<![endif]-->
|
||
<!-- IndieAuth -->
|
||
<link href="https://twitter.com/yogsototh" rel="me">
|
||
<link href="https://github.com/yogsototh" rel="me">
|
||
<link href="mailto:yann.esposito@gmail.com" rel="me">
|
||
<link rel="pgpkey" href="../../../../pubkey.txt">
|
||
</head>
|
||
<body lang="fr" class="article">
|
||
<div id="content">
|
||
<div id="header">
|
||
<div id="choix">
|
||
<span id="choixlang">
|
||
<a href="../../../../Scratch/en/blog/2009-10-untaught-git-usage/">Anglais</a>
|
||
</span>
|
||
<span class="tomenu"><a href="#navigation">↓ Menu ↓</a></span>
|
||
<span class="flush"></span>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="titre">
|
||
<h1>Usages non dits de Git</h1>
|
||
|
||
</div>
|
||
<div class="flush"></div>
|
||
<div id="afterheader" class="article">
|
||
<div class="corps">
|
||
<p><small> <em>Je décris pourquoi j’ai eu tant de mal à me faire à Git. Il y a en effet une partie “non dite” qui m’a bloqué pendant un bon moment. Jusqu’à ce que je découvre le bon document. </em></small></p>
|
||
<p><small> <em> Le fait est que les <em>branches légères</em> ne sont pas destinée à être des branches isolées. Ainsi, il y a un </em>“workflow standard”<em> qui s’il n’est pas suivi rend l’utilisation de Git inappropriée. </em> </small></p>
|
||
<hr />
|
||
<h1 id="la-décentralisation-en-action">La décentralisation en action</h1>
|
||
<h3 id="de-svn-à-bazaar">De SVN à Bazaar</h3>
|
||
<p>J’étais un fervent utilisateur de <a href="http://subversion.tigris.org">subversion (svn)</a>. Lorsqu’un jour, comme beaucoup de gens je découvris ce qu’en pensais <a href="http://www.youtube.com/watch?v=4XpnKHJAok8">Linus Torvald sur une vidéo</a>. Ventant les mérites d’un <em>système de versions concurrentes décentralisé</em>.</p>
|
||
<p>En effet une fois qu’on s’y intéresse un peu, on voit tous les avantages pratiques qu’apporteraient en théorie un tel système.</p>
|
||
<p>J’ai alors eu besoin d’un système de version dans mon équipe. Ils n’étaient pas familier avec les systèmes de versions. À par ceux possédant une <abbr title="Interface Utilisateur">GUI</abbr>, qui sont lourds et administrés par un responsable<sup><a href="#note1">†</a></sup>.</p>
|
||
<p>Après quelques recherches trois choix se dessinent :</p>
|
||
<ul>
|
||
<li><a href="http://git-scm.com">Git</a></li>
|
||
<li><a href="http://bazaar-vcs.org">Bazaar</a></li>
|
||
<li><a href="http://selenic.com/mercurial">Mercurial</a></li>
|
||
</ul>
|
||
<p>En me renseignant un peu sur les forums et en essayant les trois, je me suis vite rendu compte que celui possédant l’interface utilisateur la plus simple était Bazaar<sup><a href="#note2">*</a></sup>. Mon choix était fait.</p>
|
||
<h3 id="de-bazaar-à-git">De bazaar à Git</h3>
|
||
<p>Je me suis alors familiarisé avec Bazaar. Et je dois dire que c’était vraiment naturel en venant de subversion. La commande <code>pull</code> correspond au <code>update</code>, la commande <code>push</code> correspond au <code>commit</code>. Puis les commandes <code>commit</code> et <code>update</code> existent toujours si on en a besoin et qu’on veut utiliser un <em>workflow</em> identique à celui de subversion.</p>
|
||
<p>Mais plus le temps passe et plus de partout sur les blog, c’est surtout Git qui a le vent en poupe.</p>
|
||
<p>Je décide alors d’utiliser Git en particulier pour <em>versionner</em> le site que vous êtes en train de lire. Sauf que je le trouve vraiment difficile d’utilisation et surtout complètement contre intuitif (j’y reviendrai plus tard).</p>
|
||
<p>Alors que j’essaye de trouver de l’aide et que je dis qu’il est plus difficile à utiliser que Bazaar, beaucoup me répliquent que c’est :</p>
|
||
<blockquote>
|
||
<p>— <em>Super-tellement-trop-simple que même ma fille de 12 ans qui n’y comprend rien en informatique l’utilise pour versionner ses documents. Elle s’en sert très facilement en créant des branches et tout et tout…</em></p>
|
||
</blockquote>
|
||
<p>Bon alors si une gamine 12 ans trouve ça très naturel et que moi (avec mon Doctorat en informatique) j’ai du mal à faire ce que je veux, c’est un peu frustrant et humiliant. Mais qu’est-ce qui fait que Git est naturel aux uns (comme pour <a href="http://cocoasamurai.blogspot.com">CocoaSamurai</a> ) et très confus pour moi ?</p>
|
||
<p>C’est en lisant un article j’ai enfin compris ce qu’il me manquait. C’est la partie <strong>non dite</strong> de la conception. Celle que tous les développeurs et les concepteurs trouvaient comme <em>aller de soi</em>. Sauf que pour moi, ce n’était pas du tout le cas.</p>
|
||
<p><small><a name="note1">†</a> - Je parle de <em>ClearCase(c)</em>. Et oui, je sais qu’il existe des commandes en lignes pour ClearCase(c), mais ce n’est pas comme ça qu’ils étaient habitués à travailler avec des systèmes de “versionning”.</small></p>
|
||
<p><small><a name="note2">*</a> - Je n’ai pas vraiment donné sa chance à Mercurial, la terminologie qu’ils utilisaient était trop éloignée de celle de svn à laquelle je m’étais habituée.</small></p>
|
||
<hr />
|
||
<p>Lorsqu’on voit les présentations autour de la notion de <em>branche</em> et de <abbr title="Système de Version Concurentes Décentralisé"><sc>dcvs</sc></abbr>, on s’imagine dans un monde où chaque branche est totalement isolée des autres sauf au moment de “merger” les différences les unes des autres. Tout est magique. C’est la façon de voir “<em>Mondes Parallèles</em>”. Cette façon de voir est expliquée dans le <a href="http://betterexplained.com/articles/a-visual-guide-to-version-control/">très bon article sur les branches</a> sur betterexplained.</p>
|
||
<p>Sauf que les concepteurs de Git (conçu pour le noyau Linux) ont plutôt imaginé un système basé non pas autour des mondes parallèles, mais sur la notion de <em>Patch</em>.</p>
|
||
<p>D’un côté <em>Mondes Parallèles</em>, de l’autre <em>Patchs</em>. Il y a beaucoup de notions équivalentes dans les deux cas, mais aussi quelques différences.</p>
|
||
<ul>
|
||
<li>Bazaar est complètement basé sur la notion de <em>Mondes Parallèles</em> qui va impliquer un phénomène de <em>Patch</em>.</li>
|
||
<li>Alors que Git est basé sur la notion de <em>Patch</em> qui va impliquer la création de <em>Mondes Parallèles</em>.</li>
|
||
</ul>
|
||
<p>Je ne vais pas argumenté pour savoir si une façon de voir est meilleure que l’autre. Disons simplement que ma façon d’entrer dans l’explication des DCVS était par le biais des <em>Mondes Parallèles</em> alors que Git est conçut selon l’autre notion<sup><a href="#note3">‡</a></sup>.</p>
|
||
<h2 id="de-la-théorie-à-la-pratique">De la théorie à la pratique</h2>
|
||
<p>Bien que je pense avoir bien compris les mécanismes conceptuels de Git, la mise en pratique posait problème. Et le point noir, celui qui m’empêchait de comprendre Git comme je le souhaitais était dû à la notion de <em>branche légère</em>.</p>
|
||
<p>Une <em>branche légère</em> qu’est-ce que c’est me demanderez-vous ? Si comme moi on vient de Bazaar, c’est une notion complètement nouvelle. Il s’agit simplement de la capacité de créer une nouvelle branche en réutilisant le répertoire dans lequel on se trouve.</p>
|
||
<p>En pratique pour changer de branche, il faut lancer une commande. Tous les fichiers locaux non modifiés depuis le dernier commit seront alors modifiés pour correspondre à la version de la branche.</p>
|
||
<p>En théorie, les <em>branches légères</em> sont des branches tout comme avec bazaar. D’ailleurs le mot utilisé n’est pas <em>branche légère</em> mais <em>branche</em> tout court.</p>
|
||
<p>Sauf que contrairement à une branche standard résidant dans son propre répertoire, une branche légère est destinée à n’être qu’un <strong>patch</strong> de la branche principale du répertoire dans lequel elle réside.</p>
|
||
<p>Bien entendu on pourra m’objecter que l’on peut tout à fait utiliser ces branches légères comme des branches normales. Mais elles n’ont pas été conçues pour ça. Et donc, en pratique, c’est gênant de les utiliser de la sorte.</p>
|
||
<p>Voici comment Git est censé être utilisé (pour plus de détails vous pouvez lire <a href="http://hoth.entp.com/output/git_for_designers.html">Git for Designers</a> en anglais) :</p>
|
||
<ul>
|
||
<li>récupération ou création d’un “repository” central <strong><sc>Le Grand Repository</sc></strong></li>
|
||
<li>Création d’un <em>branche légère</em> locale qui contient les différences qui vont devoir être “patché” dans <strong><sc>LE GRAND REPOSITORY</sc></strong>.</li>
|
||
</ul>
|
||
<p>Voici comment n’est <strong><sc>pas</sc></strong> censé être utilisé Git :</p>
|
||
<ul>
|
||
<li>Récupération ou création d’un “repository” quelconque</li>
|
||
<li>Création d’un <em>branche légère</em> locale qui n’a pas pour vocation de mettre à jour le “repository” d’origine, mais de vivre sa vie de façon autonome et de récupérer les mises à jour des autres du “repository” d’origine.</li>
|
||
</ul>
|
||
<p>En effet cette petite notion m’a empêché de fonctionner correctement.</p>
|
||
<h3 id="en-pratique">En pratique</h3>
|
||
<p>Maintenant que j’ai compris ça, je peux enfin comprendre pourquoi Git a tant de défenseurs qui continue de trouver que Git est meilleur que les autres.</p>
|
||
<p>La notion de branche légère est essentielle à Git et vraiment utile en pratique. Notamment pour la gestion de ce site. Par contre, elle m’empêche d’utiliser les branches comme je le souhaiterai.</p>
|
||
<p>Mais dans ce cas-là, je n’ai qu’à utiliser des <em>clônes</em> et pas des <em>branches légères</em>.</p>
|
||
<h3 id="des-exemples">Des exemples</h3>
|
||
<p>Je trouve toujours que les terminologies de bazaar sont plus claires et plus concises.</p>
|
||
<div>
|
||
<code class="zsh">bzr revert</code>
|
||
</div>
|
||
<p>est quand même plus clair que</p>
|
||
<div>
|
||
<code class="zsh">git reset –hard HEAD</code>
|
||
</div>
|
||
<p>De la même façon</p>
|
||
<div>
|
||
<code class="zsh">bzr revert -r -3</code>
|
||
</div>
|
||
<p>je trouve ça mieux que</p>
|
||
<div>
|
||
<code class="zsh">git reset –hard HEAD~3</code>
|
||
</div>
|
||
<p>Là ça va commencer à se compliquer. Si on veut revenir dans le temps sur toute l’arborescence, avec Git on utilise <code>reset</code>.</p>
|
||
<center>
|
||
OK
|
||
</center>
|
||
<p>Maintenant si je veux revenir dans le temps sur un seul fichier. Naturellement on se dit :</p>
|
||
<div>
|
||
<code class="zsh">git reset –hard FILE</code>
|
||
</div>
|
||
<center>
|
||
<strong>ET BIEN NON !</strong>
|
||
</center>
|
||
<p>La solution c’est :</p>
|
||
<div>
|
||
<code class="zsh">git checkout FILE</code>
|
||
</div>
|
||
<p>Quoi ? <strong><code>checkout</code></strong> !? Bon, d’accord, j’accepte, pourquoi pas après tout ? En plus quand on est habitué à Bazaar c’est :</p>
|
||
<div>
|
||
<code class="zsh">git revert FILE</code>
|
||
</div>
|
||
<p>Ce que je trouve quand même bien plus naturel.</p>
|
||
<p>Mais là où ça devient vraiment difficile de s’y faire c’est pour changer de branche.<br />
|
||
Avec Bazaar ça donne :</p>
|
||
<div>
|
||
<code class="zsh">cd ../branch</code>
|
||
</div>
|
||
<p>Bon ok, il faut changer de répertoire, un répertoire par branche. Ça consomme de l’espace disque mais au moins on voit où on est. Avec Git voilà comment on change de branche (<em>branche légère</em>) :</p>
|
||
<div>
|
||
<code class="zsh">git checkout branch</code>
|
||
</div>
|
||
<p>Alors là, on se dit “<abbr title="What the Fuck?">WTF?</abbr>” ; en français : mais qu’est-ce que c’est que ça ? Je croyais que <code>checkout</code> c’était pour récupérer l’état d’un fichier ?</p>
|
||
<p>En fait le mot <code>checkout</code> sert à la fois à revenir en arrière sur un fichier (MAIS PAS TOUTE UNE ARBORESCENCE où là ça sera <code>reset --hard</code>) et à <strong>changer de branche</strong> !</p>
|
||
<p>Je trouve ça carrément contre nature. Même si c’est totalement justifié du point de vue théorique voir le très bon article (en anglais) <a href="http://eagain.net/articles/git-for-computer-scientists/">Git for Computer Scientist</a>. Du point de vue interface utilisateur, on peut difficilement faire pire. On dirait que les mots clés sont utilisés pour piéger l’utilisateur.</p>
|
||
<blockquote>
|
||
<ul>
|
||
<li>— Alors, essaye de deviner ce qu’il va falloir écrire pour faire cette opération ?</li>
|
||
<li>— Perdu. Essaye encore, cherche sur Internet (blaireau).</li>
|
||
<li>— Non, c’est toujours pas bon, recommence (sale nul).</li>
|
||
</ul>
|
||
</blockquote>
|
||
<p>Bon alors, voilà, les défauts de Git. Mais, il a par contre beaucoup d’avantages. Une fois qu’on a compris le principe des branches légères. Tout devient plus clair. Même si en pratique, l’édition du fichier <code>.git/config</code> peut s’avérer un peu fastidieuse et surtout contre intuitive.</p>
|
||
<p><small><a name="note3">‡</a> - Il faut aussi préciser qu’ayant travaillé sur les logiques multi-modales et en particulier sur les logiques temporelles (linéaires ou non), j’étais plus enclin à adhérer à cette vision des choses. “Ah mes premiers amours dans la recherche scientifique !”</small></p>
|
||
<hr />
|
||
<h1 id="conclusion">Conclusion</h1>
|
||
<h3 id="dcvs-vs.-cvs">DCVS vs. CVS ?</h3>
|
||
<p>Est-ce que ça valait la peine d’utiliser un système de “versionning” décentralisé ? Indéniablement la réponse est oui. On peut très bien vivre avec des systèmes de versions centralisés, mais la souplesse apportée par la facilité de “merger” différentes branches. De travailler de façon autonomes sur différentes parties d’un projets sont vraiment des plus appréciables. J’aurai vraiment du mal à revenir en arrière.</p>
|
||
<h3 id="est-ce-que-git-est-meilleurs-que-bazaar">Est-ce que Git est meilleurs que Bazaar ?</h3>
|
||
<p>En terme de <em>fonctionnalités</em> je dirai que Git est meilleurs. Par contre, je dois avouer qu’il s’agit d’un CVS qui s’est mis dans mes pattes. Or c’est exactement ce que je ne souhaitait pas lors de mon premier choix.</p>
|
||
<p>Je n’aurai pas dû avoir du mal à comprendre cette notion de <em>branche légère</em> qui doit être un patch sinon tu reçois des messages t’expliquant que tu es en retard. En réalité, Git différencie la notion d’arbre de la notion de branche. Ce qui n’est pas le cas dans Bazaar. Conceptuellement, c’est beaucoup plus simple de comprendre avec Bazaar.</p>
|
||
<h3 id="finalement">Finalement ?</h3>
|
||
<p>Pour conclure, j’utilise plus souvent Git que Bazaar et je dois dire que je préfère utiliser Git. Cependant, les commandes comme <code>revert</code> manquent cruellement avec Git. Pour l’instant je n’ai pas encore fait d’alias pour renommer les commandes Git comme je le souhaite.</p>
|
||
</div>
|
||
<div id="afterarticle">
|
||
<div id="social">
|
||
<a href="/rss.xml" target="_blank" rel="noopener noreferrer nofollow" class="social">RSS</a>
|
||
·
|
||
<a href="https://twitter.com/home?status=http%3A%2F%2Fyannesposito.com/Scratch/fr/blog/2009-10-untaught-git-usage/%20via%20@yogsototh" target="_blank" rel="noopener noreferrer nofollow" class="social">Tweet</a>
|
||
·
|
||
<a href="http://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fyannesposito.com/Scratch/fr/blog/2009-10-untaught-git-usage/" target="_blank" rel="noopener noreferrer nofollow" class="social">FB</a>
|
||
<br />
|
||
<a class="message" href="../../../../Scratch/fr/blog/Social-link-the-right-way/">Ces liens sociaux préservent votre vie privée</a>
|
||
</div>
|
||
<div id="navigation">
|
||
<a href="../../../../">Accueil</a>
|
||
<span class="sep">¦</span>
|
||
<a href="../../../../Scratch/fr/blog">Blog</a>
|
||
<span class="sep">¦</span>
|
||
<a href="../../../../Scratch/fr/softwares">Logiciels</a>
|
||
<span class="sep">¦</span>
|
||
<a href="../../../../Scratch/fr/about">Auteur</a>
|
||
</div>
|
||
<div id="totop"><a href="#header">↑ Top ↑</a></div>
|
||
<div id="bottom">
|
||
<div>
|
||
Published on 2009-10-13
|
||
</div>
|
||
<div>
|
||
<a href="https://twitter.com/yogsototh">Follow @yogsototh</a>
|
||
</div>
|
||
<div>
|
||
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/deed.en_US">Yann Esposito©</a>
|
||
</div>
|
||
|
||
<div>
|
||
Done with
|
||
<a href="http://www.vim.org" target="_blank" rel="noopener noreferrer nofollow"><strike>Vim</strike></a>
|
||
<a href="http://spacemacs.org" target="_blank" rel="noopener noreferrer nofollow">spacemacs</a>
|
||
<span class="pala">&</span>
|
||
<a href="http://nanoc.ws" target="_blank" rel="noopener noreferrer nofollow"><strike>nanoc</strike></a>
|
||
<a href="http://jaspervdj.be/hakyll" target="_blank" rel="noopener noreferrer nofollow">Hakyll</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
</body>
|
||
</html>
|