Livrée avec Eclipse Indigo, la version 1.0 de EGit permet une intégration graphique de git au sein d’Eclipse. L’occasion de se lancer et d’essayer une « nouvelle » technologie.
Cela fait bien longtemps que je suis convaincu de l’intérêt des logiciels de gestion de versions distribués (DVCS) comme git. [Voir par exemple le podcast des CastCodeurs Episode 23]. Seulement voilà , quand on est habitué à subversion, et que git est réputé comme étant plus difficile à prendre en main, je n’avais, jusqu’à maintenant, jamais franchi le cap.
La sortie de EGit, le plugin d’intégration de git dans Eclipse (de manière visuelle) est pour moi l’occasion idéale pour essayer. L’installation se fait de la manière la plus simple possible dans Eclipse: avec le Marketplace. (menus > Help > Eclipse marketplace… > Rechercher « EGit » et cliquer sur installer)
Je dois dire que j’ai été bluffé par cette version 1.0. Les développeurs ont vraiment tout fait pour que la transition de SVN à git soit la plus simple possible. On retrouve dans Eclipse les mêmes fonctionnalités au même endroit. Les perspectives, les dialogues et les menus sont similaires : une perspective pour les répertoires (git repository), la perspective team synchronisation pour gérer ses contributions et une intégration sous forme de menu contextuel dans la vue Java.
Je ne suis pas un expert en git, mais j’ai l’impression que des petites facilités ont été ajoutées là où cela avait du sens. Avec l’option commit de Eclipse, en activant une option de plus, il va être possible de faire les deux opérations git add et git commit. On se rapproche de l’expérience que l’on avait avec SVN.
De manière plus générale, il me semble que l’interface graphique présente les fonctionnalités de git, là où il faut. Par exemple, j’ai trouvé de manière « naturelle » l’option « amend previous commit ». J’ai le sentiment que cela va me permettre de découvrir la richesse des fonctionnalités de git au fur et à mesure.
Pour le moment, je suis encore loin d’utiliser la puissance de git, mais l’utiliser à travers EGit me permet de partir sur de bonnes bases. Cela sera utile lorsque je voudrai passer à des outils avancés comme git bisect (pour exécuter un test unitaire sur toutes les revisions et débusquer une régression dans le code), ou git flow (pour organiser ses branches). Ce sera alors l’occasion de sortir la ligne de commande.
En conclusion, il me semble que cette intégration dans Eclipse masque bien la difficulté initiale de git et permet de faciliter sa prise en main. La barrière d’entrée est largement plus basse avec cet outil graphique. Utiliser git aujourd’hui, même de manière basique c’est partir sur de bonnes bases pour la suite. En effet si SVN est plus simple d’approche, les choses deviennent plus compliquées dès que l’on veut faire des opérations un peu plus complexes (transférer les révisions de quelques fichiers à un collègue pour analyse, jouer avec des développements sur plusieurs branches, avoir des sources dans deux serveurs en même temps, …). Dans ces cas-là , qui me demandent toujours pas mal d’effort dans SVN, j’espère être agréablement surpris par git en utilisant toute sa puissance.
Voir aussi:
- EGit: http://www.eclipse.org/egit/
- Git: http://git-scm.com/
- The Git Community Book: http://book.git-scm.com/ (une traduction française)
- Cet article donne un très bon aperçu: Des outils pour repenser la gestion du code…
C’est marrant on ne s’est pas consulté mais on a écrit quasiment les mêmes choses en même temps sur git
En très résumé pour git vs svn :
– git permet d’utiliser le dépôt hors ligne, car tu as une copie du dépôt entier sur ton poste. Du coup, tu peux faire des commit, revert, comparaisons etc. sans être en ligne; ce n’est que pour pousser tes modif ou récupérer celles des autres qu’il faut bien sûr être connecté
– git a une excellente gestion des branches, qui te permet d’appliquer des workflows très sympa, je ne citerai qu’un exemple : http://nvie.com/posts/a-successful-git-branching-model/
– git gère très bien les merges, les conflits sont plus rares qu’avec svn
– git est extrêmement puissant, mais son utilisation de base n’est pas plus difficile qu’un autre DVCS
jmini> merci pour le lien, je vais voir
A titre personnel je vois plusieurs avantages:
* Tout l’historique est disponible en local. Cela va très vite de retrouver une version passée dans n’importe quelle branche… Y compris lorsqu’on a pas accès au serveur… Il y a du coup des outils qui exploitent cette fonctionnalité (git bisect par exemple exécute un test sur les versions successives pour trouver où une régression à été induite)
* Autre avantage induit par ce fonctionnement: on peut faire beaucoup plus de branches (par fonctionnalité que l’on souhaite ajouter). Du coup on peut largement créer une branche par fonctionnalité à ajouter.
* Lié au fait qu’il est facile de créer des branches, il existe aussi la possibilité de faire un git stash (mettre ses modifications actuelles dans une sorte de tampon, pour faire un fix à un autre endroit du code).
* Le travail par petite équipe autour de nouvelle fonctionnalité est plus simple… Là ou l’on aurait envoyé une série de patchs en attendant de commiter dans le trunc, on travaille sur la branche créée pour la nouvelle fonctionnalité. Il est possible de collaborer entre deux personnes sur une branche sans que celle-ci soit publique.
* Il est possible de réorganiser ses commits de manière à les avoir organisés par fonctionnalité.
* Les fonctions de merge fonctionnent mieux: git ne fusionne pas deux états de fichiers, mais des modifications successives. Il y aura donc moins de conflits. (évidement ce n’est pas magique: dans le pire cas de la modification concurrente de la même ligne, il y aura conflit).
* Une caractéristique que j’exploite beaucoup moins: l’aspect communautaire. git est pensé pour l’open-source (il fait par exemple la distinction entre auteur et commiteur). GitHub est un portail de développement collaboratif qui utilise git. Sur les gros projets (là où tout le monde n’a pas le droit de commiter), le travail de relecture du code a été grandement amélioré avec des outils comme gerrit.
Je pense que ces quelques points sont loin d’être exhaustif… C’est ce qui me vient à l’idée comme ça… (J’ai réécouté le podcast des CastCodeur mentionné, beaucoup d’autres choses sont évoquées).
J’ai entendu parlé de Git mais je l’ai jamais utilisé. Quels sont ses principaux avantages sur Subversion?
Merci pour tes remarques… Je manque encore de recul et d’utilisation grandeur nature.
Les nouvelles fonctions sont listées ici:
http://wiki.eclipse.org/EGit/New_and_Noteworthy/1.0.0
Il y a un lien en bas avec les 40 Tickets Bugzilla résolus pour cette version… Je ne sais pas si le bug que tu mentionnes y est.
Je pense que la phase d’essuyage de plâtre est passée. Je suis assez confiant sur l’avenir de EGit (JGit la librairie git en Java est utilisé par plusieurs outils, la fondation Eclipse recommande git… Beaucoup de signaux qui vont dans le bon sens)
Attention les versions précédentes d’egit ont quelques bugs (par exemple le commit/add qui ignore certains fichiers) ! Je ne sais pas si ça été résolu dans la 1.0… (pas de changelog disponible, ou alors pas trouvé)
Personnellement, j’utilise egit uniquement pour ces features :
– push
– fetch
– gestion des conflits
– lecture seule : visualisation de l’historique, comparaison de fichiers…
Tout le reste je fais en ligne de commande (aussi bien sous linux que sous windows) : git add, git commit, git merge, git checkout, git branch… Ca m’a permis aussi de bien comprendre les bases de git et donc de mieux l’utiliser