Les logiciels de gestion de version décentralisés
La réponse DVCS
Introduction
Il faut savoir que les logiciels de gestion de version décentralisés ne sont pas nés avec Git (2005), Mercurial (2005) ou Bazaar (2007). En effet, les logiciels de gestion de version BitKeeper(2001), GNU Arch(2001), Darcs(2002), Fossil ou encore Monotone(2005) fonctionnent aussi en mode décentralisé.
L'accès au dépôt
Les DVCS fonctionnent en mode déconnecté. Lors de la première opération de récupération des sources du projet, c'est l'intégralité du projet qui est rapatriée dans l'espace de travail du développeur. Par conséquent, chacun possède un historique complet du projet. Il peut donc à loisir effectuer la quasi-totalité des opérations qui lui sont proposées par l'outil. Ainsi, les opérations de commit, diff, etc. sont disponibles peu importe l'état du réseau.
Etant donné que les opérations se font en locales, celles-ci sont donc plus rapides. Utile lorsqu'on manipule un grand volume de données.
Ces outils introduisent du nouveau vocabulaire dans les pratiques, quelques exemples :
- clone. Récupérer l'intégralité des sources d'un dépôt.
- pull. Rapatrier les modifications enregistrées sur un dépôt vers le sien.
- push. Rendre ses modifications publiques vers un dépôt.
Mais plus important, avec ce mode de fonctionnement, versionner et partager deviennent deux actions bien distinctes. Par conséquent, les seuls raisons pour lesquelles on souhaiterait se synchroniser sur un dépôt seraient :
- On en a envie
- On en a besoin
On peut donc à loisir, choisir de versionner du code source ou non.
La gestion des révisions
On l'a vu précédemment, les logiciels de versioning classiques fonctionnent avec une représentation linéaire de l'historique du projet. En mode décentralisé et déconnecté, la numérotation linéaire est impossible puisque théoriquement il n'y a pas de serveur central qui maintient un compteur du prochain numéro de révision. Pour palier ce problème, les DVCS identifient les révisions par un hash. Git par exemple, applique la fonction de hachage cryptographique SHA-1 sur le contenu des fichiers, les messages et le commit précédent afin de générer cet identifiant unique qui va nous permettre de retrouver une révision particulière.
Au lieu donc d'avoir des numéros de révisions séquentiels, on manipule des identifiants de hash de type 621ff6759414e2a723f61b6d8fc04b9805eb0c20. Afin de simplifier l'utilisation au quotidien, seuls quelques chiffres sont réellement utiles pour travailler 621ff67. Mercurial et Bazaar préservent la numérotation séquentielle en plus du hash mais uniquement pour un usage local. On se retrouve donc avec des identifiants de révisions comme suit: [3]:[ff5d7b70a2a9] où 3 représente le troisième commit et ff5d7b70a2a9, le hash associé.
On comprend vite que la relation entre ces contenus dans un environnement distribué ne forme pas non pas une seule ligne de développement mais plutôt un graphe. Plus précisément, il s'agit d'un graphe orienté acyclique (ou DAG = Directed acyclic graph).
Dans ce graphe, une révision est un noeud, elle peut avoir 0 ou n parents. Une branche est une référence sur un noeud du graphe. Ici, il n'est pas question de manipuler les chemins d'accès des fichiers comme dans SVN ou de copier l'intégralité du projet dans un autre répertoire pour créer une branche. Une branche étant une référence vers un noeud du graphe, l'opération de branchage est donc triviale et est même encouragée.
On comprend donc que ces nouveaux outils avec cette facilité de créer et manipuler des branches apportent de nouvelles méthodes de travail qui nous étaient difficilement accessibles jusqu'alors.
Comment travailler ?
Plusieurs façon d'organiser notre travail organisation s'offrent à nous avec ces outils. On peut les regrouper en 3 workflows : le workflow personnel, inter-personnel et organisationnel. (© Sébastien Douche ©)
Personnel
Il s'agit de la façon dont on organise son travail seul. Avec SVN il était facile d'empiéter sur le travail des autres étant donné que partage et versioning représente la même opération. Ici on peut choisir non seulement la fréquence de ces commits mais en plus la méthode : une branche par fonctionnalités, une branche par correction de bugs...
Inter-personnel
Il s'agit de la façon dont on organise son travail avec les autres développeurs de l'équipe projet. Les DVCS rendent possibles l'envoi des changements effectués sur le code source en spécifiant n'importe quel dépôt (en tenant compte des droits d'accès bien evidemment). On peut ainsi envoyer du code source sur le dépôt d'un développeur en particulier sans impliquer les autres membres de l'équipe qui ne sont pas concernés. En tant que chef de projet, on peut avoir besoin de regrouper les équipes de développeurs par ensembles fonctionnels y compris au niveau de la gestion du code source.
Organisationnel
Cette méthode de travail concerne l'organisation dans laquelle on évolue, que ce soit une entreprise, un projet académique ou un projet open-source. Quelques exemples d'organisation :
- Le mode centralisé. Rien n'empêche de fonctionner en mode centralisé avec un DVCS, on gagne alors à garder un référentiel du projet connu de tous et une facilité à manipuler les branches.
- Le mode intégrateur. Avec des développeurs qui envoient leur modifications sur un dépôt sur lesquelles seront déroulés des tests.
- Le mode dictateur que l'on retrouve souvent dans les projets open-source. "Des lieutenants" font un premier tri du code qui leur est envoyé avant de le transmettre "dictateur" qui choisit le code à garder pour l'environnement de production. C'est sous ce modèle là qu'est géré le code source du noyau linux fonctionne.
- Le mode international pour les équipes multi-pays et multi-sites.
Il s'agit là de visions "dépôts". On peut trouver ici (en anglais), la description d'un modèle réussi d'organisation avec une vision "branche". L'auteur y détaille avec précision le rôle de chaque branches (développements, livraisons, hotfix, master... ) et surtout les règles qui s'appliquent à sur chacune d'entre elles.
Fiches d'identités
Ci-dessous une brève description des 3 DVCS les plus cités : Git, Mercurial et Bazaar.
| Critères | Git | Mercurial | Bazaar |
|---|---|---|---|
| Auteur original | Linus Torvalds | Matt Mackall | Martin Pool |
| Date de création | Avril 2005 | Avril 2005 | Mars 2005 |
| Surnom | git | hg (symbole du mercure) | bzr |
| Licence | GPLv2 | GNU GPL | GPLv2 |
| Prise en main | Puissance (+145 commandes) | Bon rapport puissance/facilité d'utilisation | Facilité d'utilisation |
| Plateformes d'hébergement | GitHub, Gitorious, SourceForge... | Bibucket, Google Code... | Launchpad, Sourceforge... |
| Multiplate-forme | C ¦ Perl ¦ Shell | Python | Python |
| Outils (IDE, GUI) | TortoiseGit, outils très riches | TortoiseHG, outils très riches... | TortoiseBzr, plugins pour IDE (Eclipse, IntelliJ), etc. |
| Projets références | Android, Noyau Linux, Ruby on Rails... | NetBeans, OpenJDK, OpenOffice, Python... | Debian, Ubuntu, MySQL... |
Conclusion >>>