Bonne année + git
Laurent Caillette
Et ceci étant dit j'en profite pour raconter ma dernière découverte : git.
Git, que le Harraps traduit comme "con" (tournure argotique, même pas
du vocabulaire anatomique). C'est aussi le nom du projet sur lequel
Linus Torvalds a travaillé ces dernières années, suite au besoin de
remplacer BitKeeper, l'outil de gestion de versions utilisé
précédemment pour le développement du kernel de Linux.
http://git.or.cz
Vu de loin, git n'est qu'un outil de gestion de version de plus parmi
des douzaines (rien que de mémoire je peux citer : CVS, Subversion,
darcs, StarTeam, Perforce, ClearCase, PVCS, SourceSafe, BitKeeper).
CVS et Subversion sont gratuits, éprouvés, et disposent d'une bonne
intégration à des outils tiers, alors pourquoi s'exciter sur un outil
de geek de plus ?
Réponse : à cause de la présentation de Linus Torvalds.
http://www.youtube.com/watch?v=4XpnKHJAok8
En plus d'être hilarante avec des vannes dévastatrices sur CVS et
Subversion, cette présentation est monumentale car elle remet en
perspective l'utilisation des outils de gestion de version et le
travail collaboratif à coup de vérités bien senties -- mais comment
n'y a-t-on pas pensé plus tôt ? Comme il est dit dans l'intro "git va
vous faire sentir moins intelligent que ce que vous avez crû".
D'abord, Linus explique la supériorité des VCS (Version Control
System) distribués (comme git, darcs, Mercurial et BitKeeper) face aux
VCS centralisés (CVS, Subversion, StarTeam...). Le modèle distribué
laisse chacun administrer son propre référentiel local, y créer toutes
les branches qu'il veut et récupérer des morceaux chez les copains,
tandis que le modèle centralisé nécessite de "committer" de gros
morceaux de code dans le référentiel central avec les risques de
destabilisation qui vont avec (désynchronisation avec d'autres
développeurs qui travaillaient parallèlement). De plus un VCS
centralisé nécessite un travail d'administration (attribution de
droits).
D'après Linus "les patches et des tarballs fournissent un meilleur
support au travail collaboratif que CVS". Scandaleux ! Mais je
reconnais que sur des projets de grande taille comme AceTP ou IDEA,
les gens en viennent immanquablement à s'échanger des fichiers "sous
le radar" du référentiel centralisé, au moins parce qu'il y a des cas
où il faut travailler sur des fichiers issus de différentes branches
et au pire parce que créer une branche prend un quart d'heure. Donc
d'accord pour utiliser un outil qui ne soit pas fâché avec le monde
réel et qui reflète l'organisation humaine. De toutes façons, un VCS
distribué permet de reproduire le fonctionnement d'un VCS centralisé
avec un référentiel "principal" pour les livrables et un responsable
des livraisons, rôle qui émerge toujours dans la pratique.
Ensuite, Linus présente les fonctionnalités-clés de git.
Git est particulièrement optimisé pour la fusion des branches (>20k
fichiers en moins d'une seconde sur un PC de bureau !). Git se
souvient de certains choix opérés manuellement de façon à ce que les
choix humains n'aient pas à être répétés. Comme le dit Linus : ce
n'est pas la création de branches qu'il faut rendre ultra-rapide,
c'est leur fusion !
Git est extrêmement rapide et sur de très gros volumes (on parle de
millions de fichiers) il ratatine la concurrence. Il est optimisé pour
minimiser le trafic réseau. Réaliser quasi-instantanément des
opérations qui prendraient des minutes entières avec d'autres outils
change radicalement la façon de travailler.
Git versionne le contenu des projets au lieu d'essayer de tracer la
vie de chaque fichier individuellement. Donc on peut renommer dans
tous les sens, git n'est jamais perdu et peut tracer la vie d'un
fragment de fichier à travers plusieurs fichiers.
Un effet de ce mode de versionnage (par le contenu) est qu'il ne sème
pas des répertoire "cvs" ou ".svn" partout, juste un ".git" à la
racine.
Git signe toutes les versions avec une clé cryptographique (SHA-1, 160
bits, soit 40 digits hexadécimaux). Ainsi, quand on récupère une
ancienne version, git s'assure de son intégrité. Encore mieux : dans
un environnement collaboratif ouvert il sert à s'assurer que la
version qu'on récupère chez un inconnu ("untrusted person") n'a pas
été altérée.
Pour avoir parcouru quelques docs j'ajouterai que git est mûr pour
l'utilisation par des gens normaux. J'ai mis 30' pour l'installer sur
Mac et à commencer à jouer à synchroniser des référentiels. Des ponts
permettent de faire apparaître un référentiel git comme un référentiel
CVS, ce qui fournit une intégration quasi-immédiate avec les IDE
existants. Il y a des façades graphiques pour visualiser les branches
et les diffs.
L'architecture de git est également un régal dans le plus pur style
Unix. Git est un filesystem exposant une structure de donnée très
simple qui peut être accédée directement à travers des commandes de
bas niveau.
Enjoy !
c.
Dominique JOCAL
Merci pour cet exposé très intéressant ! Je sais plus où j'ai eu des
retours sur Mercurial, aussi...
Et ça me rappelle aussi une discussion entre collègues récemment : la
feature des "activités" de Clearcase - sortes de branches individuelles
- que l'intégrateur "intègre" (=> fusionne) une à une pour "fabriquer
une version", cette feature donc, est totalement absente des CVS ou SVN.
Or combien de fois chez nos clients, quand on a installé du build
automatisé et promu l'industrialisation de la release, combien de fois
donc le débat est lancé sur la manière de gérer les livraisons de
corrections et de versions mineures, comment brancher, etc etc! Et les
"activités" de CC semblent bien répondre;
Corrige moi peut être, mais j'ai l'impression que Git répond itou, et
certainement avec 1000 fois plus d'agilité et de légèreté que papy CC !
doj
Laurent Caillette a écrit :
Laurent Caillette
fossile de mammouth mais je n'ai pas eu le bonheur de voir les
Activités en action. Vu le reste de l'outil je crois qu'aucune raison
honnête ne puisse justifier l'utilisation de ClearCase.
> la feature des "activités" de Clearcase - sortes de branches individuelles
> - que l'intégrateur "intègre" (=> fusionne) une à une pour "fabriquer
> une version", cette feature donc, est totalement absente des CVS ou SVN.
La doc de git évoque également ce rôle d'Intégrateur :
http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Integrator
Disons que dans ClearCase, s'il y a des branches de développement
"individuelles" ce doit être une vision ultra-rigide (style je crée
une nouvelle Activité en cliquant sur "New Activity..." et que si j'ai
les droits). Dans l'esprit git ressemble plutôt à une façon
d'automatiser l'échange de patches par email et de recopie de
répertoire "test-25-withchangesfrombob-old-2". Après ce qui est
marrant c'est que tu peux faire des mises à jour de repo en mode pull
(je vais chercher la branche xxx sur la machine de Bob) ou en mode
push (il faut alors avoir lancé le git-daemon sur la machine cible).
Un fonctionnement plausible serait que l'Intégrateur aille moissonner
ce qui l'intéresse chez ses collègues, via des git-pull ou en
demandant à git d'appliquer des patches directement sortis d'une
mailbox (si l'auteur est parti en laissant sa machine éteinte).
D'ailleurs dans ses metadonnées git différencie bien l'auteur du patch
du committer. Ensuite notre Intégrateur fait un push vers un repo sur
lequel un hook déclenche un tour de build continu.
Pour construire une version on peut imaginer que l'Intégrateur fignole
sa version comme s'il était seul au monde, et lorsqu'il est content il
opère une sauvegarde par synchronisation entre son repo local et un
repo sur un serveur backupé périodiquement.
On peut aussi imaginer tous les développeurs effectuant des push dans
le même repo et on revient à un VCS centralisateur (plus quelques
avantages mineurs). Là oui on peut parler d'agilité car l'outil peut
supporter des modes d'organisation presque antagonistes, ceci grâce à
quelques propriétés simples et sans sacrifier à la sécurité.
Autre sujet d'émerveillement qui n'a rien à voir : avoir un repo qui
soit juste qu'un répertoire .git quelque part permet de s'amuser
follement. On peut cloner les repos comme des lapins (voire des
cellules de levure ;-) et bricoler dans tous les sens sans rien
casser. Pédagogiquement c'est un régal.
c.