URL: https://linuxfr.org/users/rewind/journaux/git-malgr%C3%A9-moi Title: Git malgré moi Authors: rewind Date: 2010年09月24日T17:21:40+02:00 Tags: Score: 25 Ça faisait un moment que je voulais regarder git, histoire de ne pas mourir idiot, et bien que je n'apprécie pas du tout les DVCS (j'y reviens). Mais bon, quand on voit que dès qu'un projet commence, une des premières requêtes est : "why not git?" si le projet utilise un bon vieux Subversion, je me dis que ça ne vaut pas le coup de perdre du temps à argumenter et démarrer directement par git (oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouve). Donc voilà, je vais d'abord vous dire pourquoi je n'aime pas les DVCS (Distributed Version Control System), donc git en particulier, et au final, ce que j'aime dans git après avoir lu pas mal de tuto et fait quelques expériences. Tout d'abord, je pense que les DVCS induisent un comportement malsain en terme de développement par rapport au VCS genre Subversion. C'est une thèse que je tiens depuis un moment (j'ai la flemme d'aller rechercher dans mes anciens commentaires mais j'ai déjà dû y faire allusion ici même). Pourquoi ? Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS. Version longue : je nuance. Il existe des [[workflow]]s avec un DVCS qui ne sont pas très satisfaisants pour un développement open-source. Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert. Je ne dis pas que tout le monde fait ça, je dis que c'est un comportement possible. C'est un peu comme en C, on peut faire n'importe quoi, mais on peut aussi très bien s'en servir. Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être. Alors après, oui, on peut très bien avoir un workflows plus ouvert, et les sites tels github ou gitorious aide aussi énormément à cela. Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ? Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste. Maintenant, certains me vanteront les avantages techniques, et me diront que c'est un super outil, toussa toussa. Mais ce que je veux dire là n'a rien de technique, c'est plus une raison philosophique qui me pousse à fuir les DVCS. Mais bon, comme je l'ai dit, je ne veux pas mourir idiot et à l'occasion d'une idée de projet que je commence, je me suis dit : essayons. Alors, j'ai commencé à lire quelques tutoriels pour git, de qualité assez inégale. J'ai d'abord lu [Git - SVN Crash Course](http://git-scm.com/course/svn.html) qui permet à des gens habitués à SVN de se familiariser avec Git. Je dois dire que c'était assez obscur à la sortie et qu'il me restait plein de zones d'ombre sur la manière dont git fonctionne. J'ai jeté un oeil à [gittutorial(7)](http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html) mais je dois dire que j'ai vite abandonné, vu la rapidité des explications. J'ai continué avec [Git Reference](http://gitref.org/index.html) (écrit par les gars de github) et là, ça a éclairé ma lanterne mieux que tous les autres réunis. Je trouve les explications bien faites, progressive, didactique, avec des exemples simples mais éclairants. Donc je conseille ce dernier à tous ceux qui veulent s'y mettre. Du coup, maintenant que j'ai une assez bonne idée de git et de son fonctionnement, voilà ce que je trouve sympa dans git. Tout d'abord, cette idée d'avoir une "staging area" (concept totalement inconnu dans SVN, lisez Git Reference pour comprendre ce que c'est) qui permet de sélectionner les fichiers à commiter et les autres. Je me suis retrouvé si souvent dans cette situation avec Subversion où je ne voulais commiter qu'une partie des fichiers modifiés et que je ne pouvais pas, à moins de pratiquer des acrobaties. Ensuite, j'aime bien la manière de gérer les changements de nom de fichier comme n'étant justement pas un changement de nom (puisqu'en fait, ce ne sont pas les fichiers qui sont versionnés mais leur contenu). Je ne me suis pas risqué à faire quelques tests un peu tordus mais je me demande ce qu'il se passe si on a un gros fichier plein de code et qu'on le coupe en deux fichiers, est-ce que git est capable de repérer la source commune pour ces deux fichiers ? En tout cas, si c'est le cas, j'aime encore plus cette fonctionnalité. Enfin, j'aime bien la gestion simplifié des branches et de les voir comme des contextes de travail plutôt que comme des trucs lourds auxquels on ne touche plus une fois que la branche est crée (rares sont les branches mergées dans Subversion, ça tient en partie à la difficulté technique de merger mais aussi au ressenti des développeurs avec l'utilisation des branches). Ici, avec git, pas de problème, on saute de branche en branche. On sent bien qu'avec git, on peut procéder de 40 manières différentes pour le worflow. Je pense que c'est ce qui fait sa force. Mais sa faiblesse également selon moi. En tout cas, je vais continuer à l'utiliser pour mon projet, histoire de voir si à l'usage, ça marche. Jusqu'à présent, j'ai surtout essayé de comprendre le fonctionnement et je vais passer à l'utilisation dans un cas réel. Je reviendrai peut-être te revoir, cher journal, pour partager cette expérience.

AltStyle によって変換されたページ (->オリジナル) /