1er post : présentation et git (gestionaire de code decentraliser)

Mineurs, Mineuses, bonjour !
Les autres bonjour aussi.

L'origine de ce blog, c'était qu'on se disait que ça serait bien de savoir ce qu'on fait, de s'échanger des infos intéressantes autour de l'informatique au lieu de le faire bourré.

On invite donc tout le monde à parler de ce qu'il fait, de trucs chouette qu'il a apris, humeurs diverses etc. Le tout est de rester dans le vague nuage qu'est l'informatique.

Pour se lancer, je vais tenter de présenter Git, un outil que je ne maîtrise ni par les concepts, ni par la pratique, mais qui me semble très intéressant.

Gestion de version décentralisé

Vous connaissez tous CVS ou Subversion. Le but est de faciliter le travail collaboratif quand il s'agit de code, mais aussi de pouvoir voyager dans le temps pour voir les évolutions, trouver la source d'un bug etc. Ces deux sont centralisés : un serveur centralise toutes les contributions des utilisateur, et tous les utilisateurs vont y déposer leurs contributions et récupérer celles des autres.

Un gestionnaire décentralisé, vous l'aurez deviné, n'a pas de serveur central. L'idée derière c'est chaque développeur a son propre dépot, et tout le monde va chercher ce qu'il veut, chez qui il veut. Le but est de fluidifier le développement : on clone le dépot d'un logiciel qui nous intéresse et on code dessus.

Les plus connus sont Git et Mercurial, mais il y a également bazaar (utilisé par launchpad), Darcs (utilisé par ion), Bitkeeper (propriétaire, initialement utilisé par Linux).

Pour que ce soit un peu plus clair, je vais développer un peu plus Git qui est le seul que j'aie manipulé.

Git

Git a été développé lorsque Bitkeeper ne pouvait plus être utilisé gratuitement pour le développement Linux. Le développement a commencé en avril 2005 et la version 1.0 est sortie en décembre de la même année.

Preuve de sa robustesse, il est utilisé par Linux, xorg, bref de gros gros projets. Par contre Mozilla par exemple a finalement décidé de ne pas y passer au profit de Mercurial.

Travailler seul

• mkdir mon_projet; cd mon_projet; git init hop ! votre repository est fait
• Code code (ou pisse pisse pisse pisse pisse pour ceux en SSII)
• git add mes_fichier_modifiés; git commit et votre travail est commité

Rien d'exceptionnel venant de subversion ou cvs (peut-être à part le fait d'explicitement devoir ajouter les fichiers à commiter). Et si maintenant je veux mettre tout sur un serveur pour synchroniser mon travail entre deux PCs ou pour sauvegarder ?

• cd ..; git clone mon_projet mon_projet.bis J'ai cloné mon dépot. Tout l'historique est gardé etc.
• scp -r mon_projet.bis mon_serveur_ssh: Hop, j'ai mon dépot sur mon serveur ssh
• cd mon_projet pisse pisse pisse, commit, pisse pisse etc.
• git push ssh://mon_serveur_ssh/~/mon_projet.bis/ Et tout est mis à jour sur le serveur
• Sur l'autre ordinateur, la première fois git clone ssh://mon_serveur_ssh/~/mon_projet.bis
• Les fois suivantes : git pull ssh://mon_serveur_ssh/~/mon_projet.bis
  

Bon c'est chouette tout ça, mais tout le monde n'est pas un thésard autiste à faire son bout de code dans son coin; il y en a qui font de trucs utiles, et qui travaillent colaborativement !

Travailler à plusieurs

Imaginons que suite à trop d'alcool vous vouliez participer au développement de Linux. Il vous suffit de cloner le dépot de Linus (évidemment git fonctionne aussi au travers d'autres protocoles que le ssh). Vous codez, commitez, revenez sur vos modifications, faites des mini-branches pour tester etc. Vous finissez par avoir une amélioration que vous considerez comme pertinente. Vous envoyez un mail à Linus « hey, hey, hey, j'ai fait un truc super cool, tu devrais l'intégrer dans le noyau ! Voici mon dépôt git ». S'il pense la même chose, il fait un merge et c'est réglé.

Si on est dans le contexte d'une entreprise, on peut vouloir que tout soit centralisé dans un seul serveur. Il est parfaitement possible de gérer les droits pour un push, et imiter les accès en écriture d'un traditionnel Subversion.

Informations en vrac

• Performance en vitesse : c'est tout le temps mis en avant. J'imagine que pour projet comme Linux c'est important pour les gros merge
• Performance en place : il est dit que tout l'historique des modifications du noyau 2.6 fait la moitié de la taille de la version courante
• Git n'a pas de numéros de version (à la CVS) ou de commit (SVN), mais utilise un hash sur chaque objet pour l'identifier dans l'espace et dans le temps (un objet peut être un fichier, une arborescence etc.). Un hash permet donc d'identifier à la fois un fichier/arborescence à un commit particulier. Un corollaire est qu'il est possible de ne récupérer qu'une arborescence précise à un instant précis.
  
• Il existe de nombreux outil pour utiliser Git sur sa machine tout en travaillant avec un dépot central
• Je ne maîtrise pas l'outil, alors pardonez toute connerie que j'ai pu dire dessus
• Git est juste un exemple, les autres décentralisés sont également très bien d'après ce que j'en ai lu (et débatu avec Paul)
  

GitHub ou le Facebook du code

http://github.com/ est un dépot Git. Derrière c'est une entreprise privée, mais pour les dépôts open-source c'est totalement gratuit. Contrairement à la majorité des forges (sourceforge, berlios, google code etc.), le dépot est orienté utilisateur et non pas projet. Chaque utilisateur a sa liste de projets sur lesquels il travail. S'il veut collaborer sur un autre projet, il se contente de cloner le projet, et celui-ci apparait dans ses projets. Un simple click permet de notifier au développeur initial qu'il pourrait intégrer les modifications (pull request).

L'idée c'est de vraiment créer un réseau social de développeur. Chacun met son petit bout de code (comme des photos sur Facebook) embryonnaire qui ne mérite rien. Quelqu'un d'autre le récupère et tripatouille autour (tag la photo). Si jamais ça donne quelquechose d'utile on intègre les modifications. On peut également juste suivre un projet par curiosité.

Ma page github c'est https://github.com/Tristramg si ça intéresse quelqu'un.

Considération pseudo-métaphysique ou la philosophie informatique au vin rouge

Par rapport à la gestion de code centralisée, je dirais qu'il y a deux grands changements

1. C'est le développeur qui est au centre et non pas le code. On développe de la même manière qu'on travaille : on fait un truc dans son coin, on le montre au collègue qui prend que ce qui est bon à prendre, et quand tout est nickel on va voir le patron. Le fait de pouvoir cloner et commiter directement un projet aide aussi à se lancer directement dans un code existant.
   
2. Ça encourage beaucoup plus au bidouillage dans un sens positif. Dans un dépot central on a toujours un peu honte de commiter de la merde et que ce soit visible à tout le monde, donc on fait attention, on branche trop rarement. En décentralisé on branche plusieurs fois par jours. Si ça marche pas, on oublie la branche et personne ne se rendra compte qu'on a eu une idée débile. C'est idiot que de tels sentiments humains perturbent le dev, mais qui peut le nier ?

Merci d'avoir lu jusqu'au bout :) Pour la suite je parlerais bien un peu de ma thèse et de Qt. Peut-être un troll de bas étages pour dire que le java c'est nul...
En tout cas si vous voulez écrire quelque chose sur votre vie, surtout n'hésitez pas, c'est quand
même le but premier de ce blog. N'hésitez pas non plus à faire remarque les fautes diverses de français.