Après avoir utilisé pendant quelques années Subversion, qui me satisfaisait pour la gestion des sources de mes projets personnels (composants Talend, entre autres…), j’ai décidé par curiosité de tester Git, à cause des différents articles que j’ai pu lire récemment à ce sujet, dont la quasi-totalité vente les mérites.

Lorsque l’on a l’habitude d’un gestionnaire de configuration centralisé comme Subversion, la prise en main est rude… Les concepts ne sont pas les mêmes, et lorsqu’on essaye d’appliquer ceux dont on a l’habitude, on se retrouve face à quelques problèmes : mon premier réflexe a par exemple été de chercher comment lancer le « serveur Git » avant utilisation. #FAIL, comme on dirait sur Twitter…

Heureusement, vu la popularité croissante de ce système, je n’ai eu aucun mal à trouver des tutoriels qui m’ont ré-aiguillé sur la bonne voie. Je me suis ainsi rapidement mis à « la philosophie » de Git. Effectivement, j’approuve ce que j’ai pu lire : une fois qu’on l’a essayé, on a du mal à s’en passer. Je vais y revenir… Mais avant ça, voici ma liste de remerciements et des liens qui m’ont aidé à découvrir Git :

Avec toutes ces lectures, j’ai pu me mettre correctement à Git. Les liens ci-dessus contenant toute la littérature nécessaire pour prendre un bon départ, je vous épargnerai un n-ième tutoriel qui se contenterait de recopier ce qui existe déjà…

Le premier projet personnel qui est passé de SVN à Git, ce sont les composants Talend que je développe. Chaque composant étant dans un répertoire distinct, et constitué d’une quinzaine de fichiers maximum, j’ai jugé plus simple de les regrouper dans un unique projet.

Et c’est là que les mécanismes de Git vont m’aider. Car souvent, j’ai des idées d’amélioration (ou de création) pour plusieurs composants n’ayant rien à voir : finition du bcFileOutputOOSpreadsheet, possibilité de logs conditionnelles dans tLog4J, etc.

Il existe sur SVN un mécanisme de branches, mais passer d’une branche à l’autre et effectuer des fusions de branches une fois le travail terminé n’est pas aisé :

  • temps de switch relativement longs (surtout lorsque le projet a une taille conséquente). En développement Java sous Eclipse, quand je travaillais sur plusieurs évolutions fonctionnelles (branches) différentes, j’en suis venu à cloner mon projet en associant chaque projet à une branche différente pour pouvoir changer de branche en un temps acceptable.
  • de très fréquents « faux » dans les conflits remontés par SVN lors des fusions (principalement en cas de suppression, de renommage ou de déplacement d’un fichier). La gestion manuelle de ces conflits sous SVN est plus que pénible.

De ce fait, j’utilisais peu ce système, et la plupart de mes commits étaient effectués dans le trunk.

Dans Git, le mécanisme de branche est beaucoup mieux géré, et est donc au coeur du système. Le réflexe à avoir sous Git, c’est « une nouvelle idée = création d’une nouvelle branche ». Si cette idée aboutit, elle sera fusionnée dans la branche principale (master). Sinon, elle sera simplement supprimée. Voici pourquoi ça marche :

  • le repository Git, étant local, créer ou changer de branche est une opération très rapide, et on n’a plus besoin de cloner son projet. La « stash » (boite à idées), permet de garder en mémoire le travail en cours sur une branche avant d’en changer, sans pour autant devoir effectuer un commit
  • la fonctionnalité de fusion des branches fonctionne beaucoup mieux que sous SVN. Quand le travail sur une branche est terminé, on la fusionne dans le « master » (équivalent du « trunk »). Et les mécanismes utilisés par Git, avec ses différentes stratégies de fusion, font que ça marche vraiment bien.

Après un changement dans mes habitudes de travail, je m’y retrouve donc beaucoup plus facilement avec Git, avec une branche par évolution de composant.

Dernière étape : sauvegarder mon travail, voire synchroniser mon travail entre mes différents postes de développement. Pour cela, SVN tournait sur un serveur distant et gérait très bien ce double aspect sauvegarde/synchronisation. Jusqu’ici, Git est uniquement installé sur une de mes machines de développement.

Plusieurs solutions sont possibles :

  • installer git sur un serveur distant, avec un repository « bare » (cf. les nombreux tutoriels sur le travail collaboratif avec GIt que l’on trouve en ligne) et y accéder directement par le protocole Git+SSH.
  • installer Gitosis (cf. tutoriel sur Git-attitude), offrant une gestion plus fine des droits sur plusieurs projets. Cette solution a beaucoup d’intérêt dans le cadre de « l’urbanisation de Git » dans le système d’informations d’une entreprise
  • utiliser un hébergeur dédié, comme GitHub.

L’utilisation de GitHub est gratuite pour les projets Open Source, et payante pour les autres. Mes composants étant justement publiés en Open Source, j’ai opté pour cette dernière solution, beaucoup plus rapide à mettre en place (un formulaire de création de compte à remplir).

Outre le repository Git, la plate-forme GitHub, propose, comme SourceForge, un ensemble d’outils de suivi de projet : un historique du projet, des pages WIKI de documentation, un bugtracker…

J’ai apprécié cet aspect « Tout en un », qui manque (encore) à Talend Exchange. J’ai donc décidé de me servir de cette base pour créer le site du projet de mes composants Talend. Par rapport à Exchange, il ne contient que les composants encore vivants (dont les fonctionnalités n’ont pas été intégrées à la version de base du produit). Si vous avez des remarques (bugs) sur mes composants, ou envie de contribuer à ce projet, c’est maintenant par là-bas que ça se passe…

Il ne me reste plus qu’à éditer les liens des composants sur Exchange pour indiquer la nouvelle adresse du support…