URL: https://linuxfr.org/news/gitbuster-ii Title: Gitbuster II Authors: feth Date: 2011年05月31日T00:12:27+02:00 License: CC By-SA Tags: git, intéressant, scm, interface_graphique, vcs, dvcs et frontend Score: 45> « _If there’s something strange> In your history> Who you gonna call?> GitBuster!_ » Qui ne s’est jamais retrouvé au milieu d’un conflit de _merge_ cataclysmique, à ne plus savoir distinguer ciel et terre ? À moins d’être un utilisateur expérimenté, ce genre de situation a de quoi rebuter et faire passer à côté de toute la richesse de [[Git]]. | | | ------------|-----------| |  | Gitbuster, développé par [Julien Miotte](https://github.com/mike-perdide) est un frontal graphique à des outils comme `« git rebase »`, `« git cherry-pick »` et `« git filter-branch »`. Le projet est parti à l’origine d’un besoin très personnel de l’auteur de faciliter l’utilisation de `« git filter-branch »`, un outil très performant de réécriture des informations de _commit_. Le développement, guidé par les demandes de fonctionnalités, notamment de chefs de projet, s’est orienté vers d’autres fonctionnalités de Git, comme le _rebase_ et le _cherry-pick_. | Gitbuster offre les fonctionnalités suivantes : * **_cherry-pick_ par glisser‐déposer** d’une branche sur une autre ; * **résolution interactive** des conflits de _merge_ ; * **création d’une branche** à partir d’un _commit_ (`git checkout 1234567 -b new_branch`) ; * **modification des métadonnées** de n’importe quel _commit_ de l’historique ; * **_cherry-pick_** à partir d’un dépôt **distant** (qu’il soit sur le Web ou dans un autre répertoire) ; * **modification automatique des dates** de _commit_ d’une plage horaire vers une autre. ---- [Gitbuster sur GitHub](https://github.com/mike-perdide/gitbuster) [Gitbuster sur PyPI (Python package index)](http://pypi.python.org/pypi/gitbuster/) [Profil de Julien Miotte sur GitHub](https://github.com/mike-perdide) ---- Avec Git, un conflit se produit lorsque l’on essaye d’appliquer un _commit_ introduisant un changement à un certain endroit, alors que le _commit_ courant présente un autre changement. Par exemple, j’essaye d’appliquer le _patch_ suivant : ```diff - ernest + napoléon ``` sur un fichier contenant : ```text antoine ``` Ici, le conflit sera assez simple, et une solution probable sera de remplacer antoine par napoléon. Prenons maintenant le conflit suivant : ```python <<<<<<<<<< HEAD place = "mall" print "Let’s go to the", place ==================== if command == "go": place = "mall." print "Let’s go to the", place>>>>>>>>>>> [fix] Cosmit (message volontairement élusif) ``` Comment le résoudre ? La modification à appliquer porte‐t‐elle sur l’ajout du `« if command »` ou juste sur le « . » à la fin de « mall » ? Ce _commit_ peut en effet venir d’une branche où le développeur travaille en ce moment sur l’ajout d’une fonctionnalité de commande, mais veut uniquement appliquer ce _commit_, qui ne concerne en fait que le remplacement de « "mall" » par « "mall." ». Si le _commit_ est récent, ou si le message de _commit_ est suffisamment explicite, il y a des chances que le développeur se souvienne de la modification apportée. Mais que se passe‐t‐il si les souvenirs sont plus lointains, ou si le développeur qui _merge_ n’est pas l’auteur de la modification ? Parfois, les conflits s’étendent à plusieurs fichiers. Pas évident de déterminer la modification qu’on souhaitait apporter et comment fusionner « à la main » l’état actuel du fichier et la modification. Gitbuster propose, pour la résolution de conflits de _merge_, une interface de résolution explicite, présentant : * l’état du fichier avant le _merge_ (ou un message indiquant qu’il n’existait pas avant le _cherry-pick_) ; * le _patch_ sensé être appliqué (mais qui génère un conflit) ; * l’état « non-mergé » du fichier ; * les options de résolution possibles (ajouter le fichier tel quel, ajouter en éditant, supprimer le fichier).  Gitbuster peut aussi être lancé juste après un conflit lors d’un `« git rebase -i »`, il ne présente alors que la fenêtre de résolution pour ce conflit particulier.  Le _cherry-pick_ par glisser‐déposer :  #En coulisses Gitbuster est développé notamment grâce à lui‐même, sur GitHub, au moyen de [Python](http://www.python.org), GitPython et [PyQt](http://www.riverbankcomputing.co.uk/software/pyqt/intro). Il est constitué de deux projets : _gfbi-core_ pour l’accès aux données et _gitbuster_ pour l’interface graphique. #Pour tester / installer ```bash $ mkvirtualenv gitbuster # gitbuster recommande virtualenwrapper $ pip install gitbuster ``` L’utilisation d’autres interfaces entre Python et les systèmes de gestion de versions centralisés ou non est à l’étude (citons [_Dulwich_](http://www.samba.org/~jelmer/dulwich/), [_pygit2_](https://github.com/libgit2/pygit2) et évidemment [_Mercurial_](http://mercurial.selenic.com/)). Un mode démo est aussi disponible et permet de lancer Gitbuster dans un [_virtualenv_](http://www.virtualenv.org/), sans modifier son système. Pour lancer le mode démo, téléchargez les sources et lancez le script `« demo.sh »`. Gitbuster est installable via [_pip_](http://www.pip-installer.org/en/latest/index.html) et supporte _setuptools_, _distutils_ et _distutils2_. #_What’s next?_ Pour la suite, Gitbuster est un logiciel libre, et son avenir dépend avant tout du temps disponible de son auteur principal. Il est possible qu’il devienne agnostique par rapport au gestionnaire de version sous‐jacent. Parmi les évolutions prévues : * gérer les fonctionnalités de _push_ et de _pull_ de code ; * pouvoir éditer les paramètres de suivi (_branch tracking_) ; * mieux gérer les historiques non‐linéaires ; * prendre en compte Mercurial et Subversion ; * empaquetage dans une distribution GNU/Linux près de chez vous ; * « merger » le ciel et la terre, l’eau et le feu. _Encore merci aux relecteurs de la dépêche et aux testeurs qui se reconnaîtront._