Gestion de code pour les nuls
12/07/2008 08:02:00 PM
Les programmeurs qui travaillent en groupe ont l'habitude d'utiliser des outils pour contrôler l'évolution de leur code source. Ces outils peuvent en fait être utiles à quiconque travaille sur du texte. Par exemple, j'utilise SVN aussi bien pour développer savonet que pour rédiger des articles à plusieurs, ou ma thèse tout seul. Leur utilité est par contre grandement réduite pour des fichiers comme des images ou du son, mais aussi un document de traitement de texte: c'est un avantage quand on travaille avec LaTeX ou HTML, le document est du texte brut, contrairement aux divers Machin Office.
Un objectif clair quand on travaille à plusieurs est d'éviter les conflits. Monsieur Machin et Madame Bidule font des modifications en même temps, il faut que tout le monde puisse en profiter, si possible fusionner les modifications (si elles portent sur des morceaux de texte différents) et sinon signaler le conflit et permettre de le résoudre manuellement.
Même quand on travaille seul, ces outils sont très utiles car il permettent de suivre l'évolution d'un fichier ("Quand et pourquoi ai-je changé cette ligne?") de récupérer une version précédente, de visualiser les modifications entre plusieurs versions, et bien d'autres choses.
En ce moment, la gestion de version distribuée (DCVS) a le vent en poupe. C'est conceptuellement perturbant pour ceux qui connaissent la traditionelle gestion centralisée. Mais la décentralisation simplifie beaucoup de choses. Notamment, pour commencer à travailler avec un outil centralisé il faut (1) créer un dépôt central puis (2) obtenir une copie de travail de ce dépot. C'est souvent un peu fastidieux. Avec un outil distribué (décentralisé) les dépôts sont partout, attachés à chaque copie de travail. Créer un nouveau dépôt est une opération très naturelle et simple.
J'ai récemment commencé à utiliser Mercurial, ce qui m'a d'abord mené à l'observation ci-dessus. J'ai ensuite découvert d'autres avantages. Mais j'aimerais ici présenter à quel point il est aisé d'utiliser Mercurial pour un usage personnel. Comme pré-requis, il faut cependant savoir un petit peu utiliser le shell. Les personnes visées sont surtout celles qui n'ont jamais utilisé d'outil de gestion de code. Par la suite je présenterai peut être une utilisation plus avancée.
Vous avez un répertoire dans lequel vous développez un projet: un livre, quelques pages, des programmes, n'importe. Pour commencer à utiliser Mercurial, qu'on appelle hg pour faire court (c'est le code de l'élément Mercure en chimie), placez vous dans ce répertoire et commandez simplement:
Cette commande initialise, dans le sous-répertoire caché
Mercurial ne s'occupe pas de suivre un fichier si on ne lui demande pas. Sinon, il suivrait tout un tas de fichiers temporaires, ce qui serait gênant -- dans un contexte ou on partage un dépôt, on veut aussi éviter de tracer des fichiers secrets. Pour commencer à suivre un fichier, on utilise la commande:
Cette commande ne répond rien de spécial, elle prend note, c'est tout. Après cela, vous pouvez continuer de modifier vos fichiers comme avant.
Quand vous pensez avoir atteint un point critique dans votre travail, fini une partie important, ou sur le point de commencer quelque chose de délicat, ou tout simplement si vous avez envie de sauvegarder votre travail, il faut enregistrer vos modifications:
Cette commande va vous demander de saisir un message décrivant la modification. Cela peut paraitre ennuyant mais c'est bien pratique quand on revient plus tard, pour comprendre une modification.
Il est possible de n'enregistrer les modifications que sur certains fichiers:
Quand on veut supprimer un fichier, il faut aussi le dire à Mercurial:
Un premier avantage est la possibilité de visualiser rapidement les modifications apportées depuis la dernière sauvegarde (le dernier commit). Pour cela:
On peut aussi avoir un aperçu du statut de nos fichiers:
La commande
Souvent, on se rend compte d'une erreur, avec ou sans l'aide de Mercurial pour comparer aux versions précédentes. Parfois, il est facile de la corriger. Mais ce n'est pas toujours le cas, et on souhaite alors pouvoir tout simplement annuler un ensemble de modifications enregistrées. Pour cela il y a la commande
Il y aurait encore beaucoup à dire mais pour une utilisation simple c'est déja largement suffisant. En cas de doute au cours de votre apprentissage, n'hésitez pas à faire une copie sauvegarde de votre répertoire, le dépôt caché dedans sera sauvé aussi.
Un objectif clair quand on travaille à plusieurs est d'éviter les conflits. Monsieur Machin et Madame Bidule font des modifications en même temps, il faut que tout le monde puisse en profiter, si possible fusionner les modifications (si elles portent sur des morceaux de texte différents) et sinon signaler le conflit et permettre de le résoudre manuellement.
Même quand on travaille seul, ces outils sont très utiles car il permettent de suivre l'évolution d'un fichier ("Quand et pourquoi ai-je changé cette ligne?") de récupérer une version précédente, de visualiser les modifications entre plusieurs versions, et bien d'autres choses.
En ce moment, la gestion de version distribuée (DCVS) a le vent en poupe. C'est conceptuellement perturbant pour ceux qui connaissent la traditionelle gestion centralisée. Mais la décentralisation simplifie beaucoup de choses. Notamment, pour commencer à travailler avec un outil centralisé il faut (1) créer un dépôt central puis (2) obtenir une copie de travail de ce dépot. C'est souvent un peu fastidieux. Avec un outil distribué (décentralisé) les dépôts sont partout, attachés à chaque copie de travail. Créer un nouveau dépôt est une opération très naturelle et simple.
J'ai récemment commencé à utiliser Mercurial, ce qui m'a d'abord mené à l'observation ci-dessus. J'ai ensuite découvert d'autres avantages. Mais j'aimerais ici présenter à quel point il est aisé d'utiliser Mercurial pour un usage personnel. Comme pré-requis, il faut cependant savoir un petit peu utiliser le shell. Les personnes visées sont surtout celles qui n'ont jamais utilisé d'outil de gestion de code. Par la suite je présenterai peut être une utilisation plus avancée.
Créer un dépôt
Vous avez un répertoire dans lequel vous développez un projet: un livre, quelques pages, des programmes, n'importe. Pour commencer à utiliser Mercurial, qu'on appelle hg pour faire court (c'est le code de l'élément Mercure en chimie), placez vous dans ce répertoire et commandez simplement:
hg init
.Cette commande initialise, dans le sous-répertoire caché
.hg
, une quantité d'informations dont Mercurial a l'usage. Ce sous-répertoire incarne le dépot, qui va tracer toute l'histoire de (certains de) vos fichiers, et les fichiers avec lesquels vous travaillerez comme avant constituent votre copie de travail.Le travail comme d'habitude
Ajouter des fichiers au dépôt
Mercurial ne s'occupe pas de suivre un fichier si on ne lui demande pas. Sinon, il suivrait tout un tas de fichiers temporaires, ce qui serait gênant -- dans un contexte ou on partage un dépôt, on veut aussi éviter de tracer des fichiers secrets. Pour commencer à suivre un fichier, on utilise la commande:
hg add FICHIER_1 FICHIER_2 ...
.Cette commande ne répond rien de spécial, elle prend note, c'est tout. Après cela, vous pouvez continuer de modifier vos fichiers comme avant.
Enregistrer une modification
Quand vous pensez avoir atteint un point critique dans votre travail, fini une partie important, ou sur le point de commencer quelque chose de délicat, ou tout simplement si vous avez envie de sauvegarder votre travail, il faut enregistrer vos modifications:
hg commit
.Cette commande va vous demander de saisir un message décrivant la modification. Cela peut paraitre ennuyant mais c'est bien pratique quand on revient plus tard, pour comprendre une modification.
Il est possible de n'enregistrer les modifications que sur certains fichiers:
hg commit FICHIER_1 FICHIER_2
.Supprimer un fichier
Quand on veut supprimer un fichier, il faut aussi le dire à Mercurial:
hg remove FICHIER
. Au prochain commit
le fichier sera effacé et Mercurial arrêtera d'essayer de le suivre.Les nouvelles possibilités
Visualiser les modifications en cours
Un premier avantage est la possibilité de visualiser rapidement les modifications apportées depuis la dernière sauvegarde (le dernier commit). Pour cela:
hg diff
, ou hg diff FICHIERS
si on ne s'intéresse qu'à certains fichiers. Cette commande est bien pratique pour voir où on en est, vérifier que tout est propre avant d'enregistrer et de documenter une modification.On peut aussi avoir un aperçu du statut de nos fichiers:
hg stat
(parfois verbeux) ou hg stat -m
pour avoir la liste des fichiers modifiés.Visualiser, visuellement
La commande
diff
permet aussi de voir les différences entre des versions enregistrées dans le dépot, cf. hg help diff
. Il y a deux façons plus conviviales de faire cela, et plus encore. D'abord, hg view
qui permet de naviguer dans la liste des révisions et permet de voir les modifications associées à chacune. Plus agréable, hg serve
lance un serveur en local sur le port 8000: dans votre navigateur, à l'adresse http://localhost:8000
, vous pourrez naviguer dans les révisions et les fichiers, visualiser des différences et des versions passées.Annuler une modification
Souvent, on se rend compte d'une erreur, avec ou sans l'aide de Mercurial pour comparer aux versions précédentes. Parfois, il est facile de la corriger. Mais ce n'est pas toujours le cas, et on souhaite alors pouvoir tout simplement annuler un ensemble de modifications enregistrées. Pour cela il y a la commande
revert
.- Tout seul,
hg revert --all
annule les modifications non sauvergardées, et annule aussi les ajouts/suppressions de fichiers. On peut lui spécifier un ou plusieurs fichiers en particulier, au lieu de--all
. - On peut aussi faire
hg revert -r -2 [FICHIER ou --all]
pour revenir à la version précédente enregistrée,-3
encore un cran avant, etc. La version-1
est la dernière version enregistrée, c'est donc équivalent à ne pas passer d'option-r
. Attention, dans tous les cas on perd aussi les modifications non enregistrées. - Finalement on peut utiliser
-r REV
oùREV
est l'entier positif désignant une version, telle qu'on peut le lire viahg view/serve/log
. Par exemple la dénomination complète d'une version sera2:26e8052bce45
mais2
suffit pour la désigner. Même remarque qu'avant: attention, cela supprime les modifications en cours.
Fini
Il y aurait encore beaucoup à dire mais pour une utilisation simple c'est déja largement suffisant. En cas de doute au cours de votre apprentissage, n'hésitez pas à faire une copie sauvegarde de votre répertoire, le dépôt caché dedans sera sauvé aussi.
Libellés : code
3 commentaires:
Merci bien pour ce tuto. Si t'as le temps ça serait sympa de faire un second post pour les fonctionnalités plus évoluées de hg (notamment mq dont tu m'as parlé)...
Par Sam, Ã 8/12/08 09:55
hgview est un replacement gtk (ou qt) de "hg view" - il est plus rapide et plus beau. Il fait quelques trucs sympas en plus :
http://www.logilab.org/project/hgview
Par Anonyme, Ã 31/12/08 15:08
Avec quelle application
j’ouvre Ça ?
Par Anonyme, Ã 28/2/09 17:06
Un commentaire ?
< Accueil