Git et les branches : super pratique !

Introduction

Pour un projet d'application WEB, j'avais besoin d'utiliser un éditeur HTML en ligne WYSIWYG en lieu et place d'un TextArea :

Après une petite recherche sur internet, j'ai trouvé 4-5 librairies et j'en ai retenu 3 d'après les premières informations collectées (licence, rendu, intégration, ...). Restait alors à les tester pour vérifier l'intégration technique dans mon application et les résultats visuels dans mes pages.

La solution est venue immédiatement : faire des branches avec Git, surtout que j'avais déjà mis mon projet sous Git !

Déroulement

Voilà en résumé l'enchainement des opérations réalisées ...

Je vérifie mes branches actuelles :

$ git branch
* master

Aucune branche, donc j'en crée une pour tester la librairie "truc" et je bascule dessus :

$ git branch html_editor_truc
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'

J'installe la librairie, je modifie mon application, je mets au point, et je vérifie le résultat (rendu et utilisabilité de l'éditeur HTML). Une fois que j'ai pu évaluer la librairie "truc", je peux ajouter les nouveaux fichiers à Git et je commit :

$ git add libs/
...
$ git commit -a -m "Essaie avec l'editeur HTML truc"
...

Je reviens à ma branche principale :

$ git checkout master
Switched to branch 'master'

Et je vérifie l'état courant :

$ git status
# On branch master
nothing to commit (working directory clean)

Rien ... bon ...
Je regarde dans mon arborescence de fichiers et le répertoire que j'avais ajouté avec la librairie "truc" a disparu : magique !

Je refais les mêmes opérations pour la librairie "toto". Le résultat est moins satisfaisant, au final, je préfère la librairie "truc" : mon choix est fait ! En étant sur la branche "master", je commence par supprimer la branche pour les tests avec la librairie "toto", je n'en ai plus besoin (mais je pourrais la garder) :

$ git branch -D html_editor_toto
Deleted branch html_editor_toto (was fa84cec).

Ensuite, je demande la fusion avec la branche d'essai de la librairie "truc" :

$ git merge html_editor_truc
Updating 77cd7dc..7c0a0f6
Fast-forward
...
 21 files changed, 19 insertions(+), 2 deletions(-)

Et voilà ! La librairie précédemment testée est intégrée à la branche principal.

Play! framework

J'en ai déjà parlé, et l'article est toujours en prévision : pour ce projet, j'utilise Play! Framework,un framework de développement WEB écrit en Java : on écrit les contrôleurs et les beans de données en Java, et les template de vue en Groovy. Ce framework est très simple d'utilisation, et extrêmement productif, notamment par sa compilation en ligne : pas besoin de recompiler ou de relancer le serveur à chaque modifications, un simple rafraichissement dans la page WEB suffit pour voir les modifications apportées aussi bien dans le modèle de données, dans les contrôleurs ou dans les vues.

Donc, en utilisant Git et les branches, il suffit de basculer d'une branche à l'autre, et là encore, un simple rafraichissement de la page suffit à nous remettre dans le contexte de la branche choisie.

Dans mon cas, ça m'a permis de tester les différentes librairies pour mon éditeur HTML très rapidement. Sans compter la facilité pour comparer chaque solution en basculant de l'une à l'autre par une simple ligne de commande (git checkout ...) !

Seul bémol : j'ai été un peu embêté par la base de donnée H2, de type file, utilisé pour ma version test de mon appli sur mon poste. Par défaut, j'ai initialement ajouté à Git tous les fichiers de Play!, y compris la base de données :

$ git add .

Du coup, à chaque changement de branche, Git me signale un problème car la base a été modifiée. Il suffira donc que je l'enlève de la gestion par Git.

Corrections sur la branche principale

Même si mes tests pour choisir ma librairie ont été rapides, j'ai été interrompue pendant ces tests pour une correction mineure sur la branche principale. Qu'à cela ne tienne, je suis revenu sur cette branche, j'ai fait mes modifications (+tests bien sûr), j'ai commité et livré, et je suis revenu à ma branche de test :

$ git checkout master
Switched to branch 'master'
... // modifications
$ git commit -a -m "..."
... // livraison
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'

Aucune interférence entre les 2, vraiment super pratique !

Une galère

Durant cette expérimentation, j'ai eu essentiellement une galère. Lors de mes opérations avec Git, il me signalait un problème, assez incompréhensible, sur un dossier d'un plug-in d'une des librairies testées. J'ai longtemps pensé que j'avais raté ou mal fait quelque chose. Je me suis retrouvé bloqué !

Au final, pas de chance, mais en fait, c'est l'archive de la librairie qui contenait, dans ce dossier là, un fichier .gitignore et un dosser .git : Git était perdu, y'avait de quoi ... J'ai signalé le problème aux développeurs de la librairie, bien contents de ce feedback !

Conclusion

J'avais pas mal entendu parler de Git, et notamment pour ses avantages pour les (nombreux) commits "locaux", mais aussi pour sa gestion des branches permettant de travailler sur plusieurs sujets à la fois.

L'idée en utilisant Git est de faire une branche pour chaque modification entamée.

Lorsque j'avais lu cela, avec mon expérience Subversion (et la gestion des branches parfois lourde), j'avais été surpris. Mais l'expérience, même de faible ampleur (pas énormément de modifications sur plusieurs branches à la fois), est vraiment concluante : ces possibilités offerte par Git et sa gestion des branches est vraiment génial !

Et vous ?

Quelle est votre point de vue, expérimenté ou non, sur Git ?
Qu'en pensez-vous ?