Il y a maintenant quelques semaines, j’ai été frappé par le virus Git. Dans la foulée, j’ai migré la gestion de configuration de mes composants pour Talend Open Studio sous GitHub. Et depuis, pour mieux maitriser cet environnement, j’ai pris ProGit comme livre de chevet.

Plus récemment encore, j’ai décidé de passer également sous Git mon environnement de travail professionnel pour le développement Java. Mais cette fois, ce n’est plus aussi simple, car on ne peut pas remplacer comme ça le serveur SVN central utilisé par les différentes équipes de développement.

Mais Git et Subversion peuvent être utilisés ensemble. On travaille sous Git en local, profitant ainsi de tous ses avantages (passage rapide d’une branche à l’autre, pour bien découpler les différents travaux, etc.), et on synchronise ce travail sous Git avec le serveur SVN.

Ce mode de travail et ses avantages ont très bien été expliqués dans le dernier article de Nicolas de Loof. En particulier, ce qui m’intéresse, c’est la rapidité de mise en oeuvre sans avoir à faire évoluer la plate-forme de développement d’un iota.

Cet article expliquant tout ce qu’il y a à savoir pour débuter avec Git et SVN, je ne recommencerai pas. Je vais donc aborder l’étape suivante : l’intégration de cette nouvelle méthode de travail dans mon environnement de développement.

Professionnellement, nous travaillons sous Windows avec Eclipse (dans mon cas, c’est Oracle Enterprise Pack for Eclipse, que j’ai adopté). Personnellement, j’utilise aussi principalement Eclipse (c’est l’IDE auquel je suis le plus habitué), sous Windows ou sous Mac.

Git sous Windows

Sous Mac (et plus généralement sur les systèmes à base d’Unix, il n’y a rien à dire : Git s’installe sans aucun problème.

En revanche, Git est très mal supporté sous Windows, et il n’en existe pas à ma connaissance de version native : il faut passer par une « émulation » d’Unix : en installant le paquet pour Cygwin, ou en utilisant l’installeur dédié Msysgit.

J’ai opté pour ce dernier : il est bien maintenu, et a plutôt bonne presse. De plus, il me permet d’avoir un environnement en ligne de commande de type « sandbox », cloisonné à son répertoire d’installation et dédié à l’utilisation de Git. Ce qui me permet d’y appliquer ce tutoriel et de bénéficier automatiquement de l’auto-complétion des commandes lorsque j’ouvre cet environnement.

Anticipons dès à présent un problème que nous allons rencontrer sous Eclipse : certains plugins (M2Eclipse, par exemple) aiment avoir accès à la commande Git depuis n’importe où (c’est-à-dire dans le PATH). Moi aussi, soit dit en passant…

Pour cela, nous rajoutons dans le PATH la double entrée :

%MSYSGIT_HOME%\bin;%MSYSGIT_HOME%\mingw\bin

Un des défaut immédiats de ce système passant par une « émulation Unix » est qu’il est difficile sur Windows d’installer des add-ons pour Git, comme par exemple GitFlow (même si ce plugin est loin d’être indispensable).

Git sous Eclipse

SVN est très bien intégré dans Eclipse, via Subclipse ou Subversive. Pour Git, il y a EGit (la version adaptée pour Eclipse de la librairie JGit), mais qui est encore en phase d’incubation. Et effectivement, ce plugin est loin d’être mature. En particulier, au jour où j’écris ce post, il ne faut surtout pas utiliser la version stable du plugin mais un « nighty-build », en utilisant cette adresse pour le site de mise à jour. En effet, la version stable souffre d’un bug qui la rend inutilisable : le fichier « .gitignore » est ignoré (désolé pour ce mauvais jeu de mots), et à chaque commit, le plugin propose par défaut d’ajouter à la gestion de configuration tous les fichiers qui n’y sont pas, y compris ceux qu’on souhaite ignorer. [Edit le 22/09/2010]Une nouvelle version stable a été publiée : le plugin est donc maintenant utilisable dans sa version stable[/Edit]

Une fois la bonne version installée, le plugin est tout de même suffisant pour travailler dans de bonnes conditions (même s’il ne gère pas pour l’instant le lien avec les serveurs SVN) !

Effectuer la migration

Nous allons supposer que nous avons dans notre workspace Eclipse un projet nommé « ProjetSVN », qui utilise Maven.

Je vais présenter pas à pas les étapes à suivre pour travailler sur ce projet avec Git dans Eclipse, tout en maintenant le lien avec le serveur SVN (et donc le reste du monde).

On commence en dehors d’Eclipse : au niveau du workspace, nous créons un dossier « ProjetGit ». Dans ce dossier, nous récupérons les sources depuis le serveur SVN, en ligne de commande :

1

git svn clone -s https://serveursvn/projetsvn -r $REV:HEAD .
  • Le paramètre ‘-s’ indique que le projet respecte l’arborescence standard « trunk/branches/tags ». Si ce n’est pas le cas, il faut le remplacer par « -T trunkDir -b branchesDir -t tagsDir ».
  • Le paramètre ‘-r’ sert à limiter le nombre de révisions récupérées, ce qui peut être nécessaire sur un ancien projet contenant de très nombreux commits : $REV est à remplacer par un numéro de révision récent.
  • Enfin, le ‘.’ final précise le répertoire de destination (en l’absence de ce point, la commande aurait recréé un répertoire nommé « projetsvn » dans le répertoire « ProjetGit »).

Le projet est donc maintenu créé, ainsi que son repository Git (dans le répertoire « .git »), et celui-ci est connecté au serveur SVN (la commande « git svn clone » s’est déjà chargée de mettre à jour la configuration Git). Il ne manque plus que les fichiers de configuration Eclipse (s’ils n’étaient pas sur SVN).

Les préparatifs étant terminés, nous pouvons revenir sous Eclipse. Pour créer le nouveau projet (géré par Maven), j’utilise le plugin M2Eclipse, et plus particulièrement sa fonction d’import « Materialize Maven Projects » : j’indique l’emplacement du fichier pom à utiliser et le tour est joué.

Dernière étape : connecter ce nouveau projet dans Eclipse à la gestion de configuration par EGit :

Clic droit sur le projet > Team > Share Project

On choisit le gestionnaire « Git » : le plugin va immédiatement scanner le répertoire du projet, y trouver le répertoire « .git », et proposer d’établir le lien. On accepte : le projet est maintenant lié à la branche « master ».

Premiers pas avec EGit

Menu EGit

Menu Egit

Comme rien ne vaut un bon exemple, nous allons envisager un scénario élémentaire d’utilisation sur notre nouveau projet « ProjetGit ».

Première étape : on sélectionne les fichiers qui ne doivent pas être mis en gestion de configuration et on les ajoute au fichier « .gitignore », et commiter celui-ci :

Clic droit sur ces fichiers > Team > Ignore

Clic droit sur le projet > Commit > Sélection du fichier « .gitignore » et saisie d’un commentaire approprié avant le commit

Nous avons maintenant une évolution à effectuer. Le réflexe avec Git, c’est de créer une branche dédiée :

Clic droit sur le projet > Team > Branch… > New branch > « myFirstEvolution »

On fait immédiatement un checkout de cette branche, pour se positionner dessus. On effectue la (les) modification(s) voulue(s), en effectuant (comme pour le fichier « .gitignore ») un ou plusieurs commit, à chaque étape que l’on veut mémoriser.

Une fois l’évolution terminée et un commit effectué, on re-bascule sur la branche « master » (par un checkout). Dans cette branche principale, on effectue une fusion de la branche « evolution » pour en récupérer les modifications :

Clic droit sur le projet > Team > Merge… > « evolution » > bouton merge

A ce stade, la branche « evolution » n’a plus de raison d’être : elle pourra donc être supprimée quand on le souhaite dans le menu des branches.

Synchronisation avec SVN

L’évolution étant revenue sur la branche principale, il reste à la re-synchroniser avec SVN pour récupérer le travail des autres développeurs… et leur partager le nôtre.

On peut repasser par la ligne de commande, mais on va vite s’en lasser… une solution intégrée à Eclipse serait tout de même bien plus pratique. Pour cela, nous allons passer par les « External Tools« , comme le montre la capture suivante :

Commandes Git

Commandes Git

Note : utiliser la variable d’environnement « ${project_loc} » permet de rendre le script utilisable sur tous les projets Git de l’espace de travail.

Après avoir configuré ces commandes, on effectue dans l’ordre :

  1. Le « git svn rebase » qui va effectuer un « update » depuis SVN, puis rejouer les modifications locales après cette mise à jour.
  2. Le « git svn dcommit » qui va jouer sur SVN les modifications commitées localement sur la branche « master »

La boucle est maintenant bouclée.

Conclusion

Outre l’intégration avec SVN, il y a également la fonctionnalité « stash » de Git qui n’est pas supportée par EGit, alors qu’elle est pourtant des plus utiles. Donc, comme pour SVN, je ne saurai que trop vous conseiller de les intégrer via les « External Tools« .

Le plugin EGit n’étant pas complet, un bon complément (pour ceux qui ne sont pas fans de la ligne de commande) est TortoiseGit (gestion du »stash », etc.).

Mise à jour : la consultation de l’historique Git est supportée dans les « nighty builds », et elle permet de naviguer dans les commits successifs. Dans la version stable, elle ne fonctionnait que sur un fichier isolé, par le menu « Compare With ». [Edit le 22/09/2010]Egalement faux depuis la dernière version stable[/Edit]

Mise à jour : sitôt cet article mis en ligne, j’apprends que depuis cette nuit, grâce à une contribution de SAP, EGit (dans sa version « nighty build ») supporte toutes les fonctionnalités de fusion de Git. Jusqu’alors, seules les fusions « fast forward » étaient possibles.