Mercurial et Bitbucket – Workflow default & stable

Ce document est un mémento des commandes et de leurs enchainements lors de l’utilisation d’un dépôt local et d’un dépôt central hébergé sur Bitbucket. Le principe de travail est basé sur un fonctionnement avec 2 branches : default et stable.

La branche « default » est la branche de développement qui est toujours la plus à jour (HEAD dans le monde svn).

La branche « stable » est la branche contenant uniquement des versions stables. Le contenu de la branche « stable » correspond à la dernière release officielle. On utilise cette branche pour la correction de bugs urgents (hotfix).

Les actions Mercurial sont réalisées au moyen de la commande « hg ». Certaines actions concernent le dépôt local (interactions entre les sources et le dépôt local),  d’autres concernent le dépôt central (interactions entre le dépôt local et le dépôt central). Les commandes locales seront indiquées en bleu et les autres en rouge.

Pour l’exemple, le projet s’appelle « HelloWorld ». Le but est de commencer avec les 2 dépôt (local et central) synchronisés.

Cas 1 : le projet est totalement nouveau, il n’y a ni dépôt local, ni dépôt central

Créer un dépôts « HelloWord » central sur Bitbucket

On obtient l’url d’accès au dépot : ssh://hg@bitbucket.org/bejean/helloworld

Créer un dépôt local

Cas 2 : le projet existe dans un dépôt central

Créer un dépôt local et récupérer les sources du dépot central.

(cette commande met à jour à la fois le dépôt local et les sources, elle devrait être bleue et rouge)

Cas 3 : le projet existe dans un dépôt local

Créer un dépôt central.
On obtient l’url d’accès au dépôt : ssh://hg@bitbucket.org/bejean/helloworld

Se placer dans le dépôt local et envoyer les sources dans le dépôt central.

Pour la suite de cet article, nous supposons que l’on est dans le cas 1. On a alors nos dépôts créés mais vides.

Configuration

Afin de ne pas devoir spécifier l’url du dépôt central pour toutes les commandes qui interagissent entre le dépôt local et le dépôt central (en rouge), nous allons commencer par configurer notre dépôt local.

On édite le fichier « hgrc » du dépôt.

et on ajoute la section suivante :

Début de développement

Commençons à travailler dans notre environnent local. On créer un fichier en local

hg status indique que le fichier est inconnu dans le dépôt local

On ajoute le fichier dans le dépôt local

hg status indique que le fichier est connu dans le dépôt local mais pas à jour

On met a jour le fichier dans le dépôt local

hg status n’indique plus de fichier inconnus ou non à jour.

hg branches indique maintenant qu’il existe une branche « default »

Le dépôt central n’est toujours pas au courant du contenu du dépôt local. On envoi nos modifications dans le dépôt central.

La copie d’écran si dessous montre que le dépot central est à jour avec une branche « default »

Publication d’une première version stable (v1.0) : branches et tags

On considère que cette version des sources du projet est la première version stable. Il faut donc maintenant :

1/ tagger la version

2/ créer une branche « stable » qui soit le reflet de la branche « default »

Afficher les tags, les branches et la branche active.

On met à jour le dépôt central avec la nouvelle branche.

Voici un schéma qui récapitule les différentes actions et les différents flux.

Attention, à cette étape, la branche active est « stable ». Il faut revenir à la branche « default », pour coder de nouvelles fonctionnalités.

Le développement continu …

On modifie le fichier readme.txt et la commande hg status nous le confirme.

on commit les modifications dans le dépôt local

On peut vérifier les modifications locales transférables dans le dépôt central.

Si ces modifications sont terminées, on peut les mettre à disposition des autres développeurs dans le dépôt central

De même on peut vérifier les modifications faites dans le dépôt central (par d’autres développeurs) et pouvant être récurées. Dans notre cas, il n’y en a pas.

Régulièrement, on récupère dans notre dépôt local les modifications faites par les autres développeurs et disponibles dans le dépôt central.

Publication d’un nouvelle version (v2.0)

La publication d’une nouvelle version implique de :

1/ tagger la branche active (default)

2/ mettre à jour la stable (merger default dans stable)

(gérer les conflits. il ne devrait pas y en avoir si les hotfixs fait dans stable ont systématiquement été mergés dans default)

3/ revenir dans la branche de développement

Le diagramme suivant illustre les séquences de commandes durant le cycle de production d’une nouvelle version :

 

Correction d’un bug dans la version stable

1/ se placer dans la version stable

2/ corriger le bug

3/ commiter la correction

4/ revenir à la branche default

5/ merger la correction de la branche stable et résoudre les potentiels conflits

 

Comme référence, on trouve les 2 diagrammes suivants sur le site ivy.fr (licence Creative Commons Attribution 3.0 Unported).

Un autre diagramme (trouvé sur le site secretGeek) qui indique un workflow basic. Le point 6 (qui n’est pas systématique) doit être suivi d’un « hg up ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *