Mercurial pour nous les nuls, leçon 5 : commit, push

L’index des leçons :

  1. Leçon 1 : la gestion de version
  2. Leçon 2 : qu’est-ce qu’un dépôt ?
  3. Leçon 3 : les logiciels ”clients”
  4. Leçon 4 : création d’un dépôt
  5. Leçon 5 : enregistrement de révision
  6. Leçon 6 : synchronisation de dépôts, mise à jour du répertoire de travail
  7. Leçon 7 : identifier les différences
  8. Leçon 8 : la gestion des branches
  9. Leçon 9 : la fusion de branche
  10. Leçon 10 : retour vers le passé
  11. Leçon 11 : patch et collaboration indirecte

Maintenant que notre premier dépôt est créé, voyons comment enregistrer au fur et à mesure notre travail.

Enregistrement d’une révision : Commit

Pour illustrer cette leçon j’ai choisi de commencer le développement d’un thème Dotclear en créant, dans le dossier pointé par le dépôt local, un fichier _define.php ainsi qu’un dossier images contenant un fichier image. MacHg m’indique alors une liste de fichiers et de dossiers untracked, c’est à dire non suivis par le gestionnaire Mercurial. C’est tout à fait normal puisque je viens juste de les créer :

Répertoire de travail modifié

Ils apparaissent dans la représentation du répertoire précédés un point d’interrogation[1]. Il s’agit maintenant de faire prendre en compte par MacHg ces nouveaux éléments. Pour cela j’utilise la fonction d’ajout-suppression (AddRemove en anglais) qui me permet d’indiquer que dorénavant MacHg doit suivre l’évolution de ceux-ci :

Statut des nouveaux fichiers

La commande terminal correspondante est la suivante :

hg addremove

Cette commande parcourra tous le répertoire et ajoutera (ou supprimera) tous les fichiers nouveaux ou supprimés. Il est bien sûr possible de faire ça fichier par fichier, dossier par dossier avec les commandes :

hg add _define.php
hg add images

Vous pouvez constater sur la copie d’écran suivante que les fichiers (et dossiers) sont dorénavant dotés d’un symbole + (plus) ce qui indique qu’ils sont désormais pistés par MacHg :

Les fichiers ont été ajoutés

Arrivé à ce point de mes modifications j’estime que celles-ci sont susceptibles de former ce qu’on appelle une révision. L’intérêt d’enregistrer celles-ci est de pouvoir à tout moment revenir sur une révision précédemment enregistrée pour annuler une ou plusieurs modifications ou pour développer une autre version du projet. Chaque révision devrait normalement former un ensemble cohérent.

J’utilise, pour enregistrer une révision, la fonction commit. Celle-ci est généralement accompagnée d’un message librement défini par l’utilisateur :

Enregistrement de la révision

La commande terminal équivalente est la suivante :

hg commit -m 'message accompagnant la révision enregistrée'

Une fois l’enregistrement effectué MacHg m’indique le nouvel état de mon répertoire. Vous remarquez maintenant que les symboles + ont disparu et qu’une révision a été enregistrée (voir l’information cerclée en rouge) :

État du dépôt après le commit

Dorénavant j’ai une copie parfaite de ces fichiers et dossiers dans mon dépôt et je peux y revenir à tout moment. Je décide donc, l’esprit tranquille, de continuer mon travail. Je vais maintenant modifier le fichier _define.php pour changer le numéro de version qu’il contient. Une fois cette modification enregistrée avec mon éditeur de texte préféré (Textmate sur Mac OS X), MacHg m’indique que ce fichier a été modifié :

Fichier modifié dans le répertoire de travail

J’enregistre (avec un commit) cette seule modification comme une nouvelle révision, n’ayant rien de plus à faire pour le moment. J’indique l’objet de cette révision, ici un changement de version, et je confirme :

Enregistrement de la nouvelle révision

Vous savez maintenant comment, au fur et à mesure de vos travaux, enregistrer ces révisions successives à l’aide de la commande commit.

MacHg permet d’afficher la liste des révisions effectuées sur un dépôt, comme illustré ci-dessous :

Liste des révisions du dépôt

Vous retrouvez la liste des révisions enregistrées accompagnées de leur message et vous noterez au passage deux éléments, tip et default, représentant respectivement l’état le plus récent d’un dépôt (tip) et le nom de la branche (branch en anglais) sur laquelle vous travaillez. Nous reviendrons sur cette notion de branche dans une prochaine leçon.

Mise à jour du dépôt distant : Push

Jusqu’à maintenant j’ai travaillé uniquement sur mon répertoire de travail et mon dépôt local, sur ma machine. Si je souhaite partager mon travail avec d’autres, afin, par exemple, de travailler en équipe sur le développement d’un projet, il faut alors reporter sur le dépôt partagé (voyez la leçon précédente pour la création et l’utilisation d’un dépôt partagé) les révisions que j’ai enregistrées localement.

Vous pouvez constater ci-dessous que le dépôt distant n’est pas synchronisé avec le dépôt local. En effet le compteur indique un nombre 3 qui correspond au nombre de révisions qui manquent, une pour la création initiale du dépôt, une pour la création des fichiers et dossiers, une dernière pour la modification du numéro de version :

Dépôt distant désynchronisé

J’utilise alors la commande Push (envoi en anglais) pour transférer sur le dépôt distant toutes les révisions manquantes et qui sont présentes dans le dépôt local :

Push des révisions vers le dépôt distant

La commande terminal correspondante est la suivante :

hg push <url>

Une fois le transfert effectué, MacHg m’informe du résultat, 3 changesets (ou révisions) comportant 4 changements sur 3 fichiers. Il s’agit des 3 créations de la première révision et de la modification du numéro de version de la seconde :

Résultat du push

Les deux dépôts, local et distant, sont maintenant synchronisés comme l’indique le compteur affiché en regard du dépôt distant :

Le dépôt distant est synchronisé

Je peux également aller vérifier sur le site Bibucket où le dépôt distant est stocké. Un des affichages disponibles me permet de lister les révisions enregistrées, en tout point conforme avec les révisions enregistrées localement sur ma machine :

État du dépôt distant sur Bitbucket

Le cycle normal — mais incomplet nous le verrons dans la leçon suivante — est donc :

  1. Changement dans le répertoire de travail (création de nouveaux fichiers, modifications de certains d’entre eux, suppressions éventuelles, …) ;
  2. Commit pour enregistrer ces changements (ce qu’on appelle une révision) ;
  3. Push vers le dépôt distant[2] pour synchroniser la ou les révisions enregistrées localement.

Conclusion

Vous savez maintenant comment enregistrer (commit) le fruit de votre travail au fur et à mesure et comment faire en sorte que l’éventuel dépôt distant que vous utilisez soit également mis à jour (push). Nous verrons dans la leçon suivante comment récupérer les révisions enregistrées dans un dépôt et comment mettre à jour son répertoire de travail en conséquence.

Glossaire

Commit : Enregistrement des révisions (ajouts, suppressions, modifications) effectuées dans un répertoire de travail vers le dépôt dont il est issu.

Push : Mise à jour — on envoie, d’où le terme de push — d’un dépôt avec les révisions enregistrées dans un autre dépôt (local ou distant).


Leçon suivante

Notes

[1] Les signalements peuvent changer de forme et d’aspect d’un logiciel à l’autre, mais vous en aurez toujours un.

[2] Le push est également possible entre deux dépôts locaux.

Ajouter un commentaire

Les champs suivis d'un * sont obligatoires

Les commentaires peuvent être formatés en utilisant la syntaxe Markdown Extra.

Ajouter un rétrolien

URL de rétrolien : https://open-time.net/trackback/7058

Haut de page