Archives pour avril, 2011

Comme vous avez été nombreux à apprécier mon article sur Maven et git, en voici la suite ! Il s’agit d’une solution alternative permettant de répondre à la même problématique, basée sur les subtree.

Rappel : mon but était de séparer la gestion de configuration de plusieurs modules Maven d’un même projet, tout en conservant un dépôt pour maintenir le projet (pom racine du projet, etc.).

La problématique étant la même, nous allons nous baser sur le même exemple : un projet créé à partir de l’archetype appfuse-modular-jsf. Pour sa mise en place de ce projet, je vous renvoie donc aux étapes Créer le projet de démonstration et Mise en place des dépôts distants.

Revenons à notre espace de travail

Maintenant que nous avons nos dépôts distants, la première chose à faire pour mettre en place les subtrees est de supprimer les répertoires des deux modules dans l’espace de travail. En effet, avec cette méthode, les modules n’ont pas de dépôt git locaux dédiés.

Déclarons ensuite les dépôts distants de notre espace de travail :

1
2
3

git remote add origin $BARE_REPOS/demo.git # S'il n'existe pas déjà
git remote add core $BARE_REPOS/demo-core.git
git remote add webapp $BARE_REPOS/demo-webapp.git

A ce stade, les habitués de git qui ne sont pas trop endormis doivent crier « KEUOUA ??? ». Effectivement, les démos distants sont normalement des clones du dépôt local. Or nous venons de déclarer trois dépôts distants qui n’ont pas un seul commit en commun.

Ce n’est pas une erreur, et c’est le mode de fonctionnement des subtrees. Contrairement aux submodules pour lesquels on avait trois dépôts locaux, avec les subtree, on a un unique dépôt local : le lien entre cet unique dépôt et les dépôts distants passe donc par les « remotes » du dépôt local.

Des branches locales pour travailler sur les modules

Nous allons maintenant créer des branches locales associées aux branches distantes afin de pouvoir travailler sur nos modules.

1
2
3
4

git fetch core
git fetch webapp
git branch localcore --track core/master
git branch localwebapp --track webapp/master

Il est maintenant possible de travailler sur les modules localcore et localwebapp dans leurs branches locales respectives. Le tracking étant défini, les push seront effectués vers les dépôts respectifs des deux modules.

Et l’arborescence globale de notre projet ?

Depuis notre unique dépôt local, nous avons vu comment travailler séparément sur nos différents modules. Mais à ce stade, nous n’avons pas reconstitué l’arborescence de notre projet Maven. C’est à ce stade qu’interviennent les subtrees.

On rebascule dans la branche master de notre projet, et on exécute :

git read-tree --prefix=core/ -u localcore
git read-tree --prefix=webapp/ -u localwebapp

Après cette étape, on n’oublie pas de commiter l’ensemble et nous avons récupéré l’arborescence globale de notre projet.

Mettre à jour le projet lorsque les modules évoluent

Notre module core a maintenant évolué dans sa branche. Ces modifications ne sont pas automatiquement reportées dans la branche master de notre projet.

Pour récupérer ces mises à jour, il suffit d’utiliser la commande :

1

git merge -s subtree localcore

Cette opération aura pour effet de fusionner dans la branche master les modules (ainsi que leurs historiques respectifs).

On peut juger que ces historiques sont « parasites » à ce niveau : on les a déjà dans la branche du module. On préfèrera dans ce cas la commande :

1

git merge -s subtree --squash --no-commit localcore

Cela aura pour effet d’agréger tous les commits en un seul et de préparer le message de commit (qui concatène les messages de tous les commits agrégés). Il ne reste plus qu’à corriger ce message et à valider le commit.

Submodules ou Subtrees ?

Nous avons donc deux méthodes permettant de traiter la même problématique. Il ne reste plus qu’à en choisir une. Les deux approches ont leurs avantages et leurs inconvénients.

Les subtrees sont plus faciles à manipuler : ils nécessitent moins d’opérations, et il est plus difficile de faire une erreur qu’avec les submodules (oubli d’un push par exemple).

Les submodules sont plus complexes à utiliser, mais plus structurés (il s’agit là d’un avis subjectif de ma part) : chaque dépôt distant est associé à un dépôt local.

Personnellement, ce sont les submodules que je préfère.

Comme vous avez été nombreux à apprécier sur Maven et git, en voici la suite ! Il s’agit d’une solution alternative permettant de répondre à la même problématique, basée sur...