Multigit est un outil graphique conçu pour simplifier la gestion de projets composés de beaucoup de dépôts git.
Une image et une vidéo valant mieux qu'un long discours, voici à quoi ça ressemble:
Je l'ai développé dans le cadre de mon travail chez IDEMIA où nous sommes souvent confrontés à plus de trente (voire plus de soixante) dépôts à gérer conjointement sur un projet. Dans ce contexte, la moindre opération git devient un mini-défi qu'il fallait relever quotidiennement.
Multigit est abouti et stable, il est utilisé au quotidien par plus d'une centaine de personnes (sous Windows), depuis plusieurs années. Mon employeur m'a aimablement autorisé à le publier en Open Source, ce dont je lui sais gré. Il est publié sous licence Apache 2.0
La problématique de gestion de plusieurs dépôts git conjoints pour un projet est assez peu répandue dans le monde du logiciel libre. Mais beaucoup plus dans le monde de l'entreprise. En effet, git ne gère pas la notion de droit d'accès à une partie d'un dépôt. La seule façon de restreindre l'accès à certains parties d'un projet est donc de créer un dépôt spécifique pour les y stocker, avec des droits d'accès au niveau du dépôt. Ajoutons à cela beaucoup de personnes, beaucoup de projets parfois complexes, beaucoup de sous-projets, beaucoup d'historique et on se retrouve avec une gestion des sources particulièrement complexe. Complexe … avant l'arrivée de Multigit en tout cas.
Installation
Sous Linux, la seule option d'installation disponible à l'heure actuelle est Python + pip, ou encore mieux avec pipx:
$ sudo apt install python-pipx
$ pipx install multigit_gx
$ multigit
Sous Windows, un installeur graphique click-and-play vous permettra d'arriver au même résultat.
J'ai bien tenté de fournir un snap pour Linux mais snap est conçu pour empêcher à peu près tout ce que veut faire Multigit: accèder à tous vos fichiers et lancer des programmes de votre distribution (git, gitk, …)
Je ferai mieux dans la prochaine version. D'ailleurs, si vous avez des recommandations pour un packaging moderne, simple, facile à maintenir et couvrant toutes les distributions Linux, je suis preneur.
Contribution
Le projet est géré sous GitHub, les contributions ou les retours sont les bienvenus.
Aller plus loin
- Vidéo de l'utilisation de Multigit (47 clics)
- Dépôt Github (32 clics)
- Téléchargement de la version 1.6.1 (7 clics)
# submodules
Posté par AncalagonTotof . Évalué à 2 (+0/-0).
Cool ! Très intéressant.
Question : est-ce que vous avez tenté les git submodules ?
J'ai joué un peu avec pendant un temps. Mais ça me rapportait, si ce n'est plus de pépins que de solutions, au moins beaucoup de … Zut, le terme de l'erreur la plus fréquente sur laquelle je tombais m'échappe. Mais ça se produisait souvent, et c'était plus une question de "quand", et pas "si" ça va se produire.
En tout cas, je me rappelle vaguement avoir à :
- soit virer le submodule et le "tirer" à nouveau du repo
- soit "tricoter" avec des branches pour le remettre d'aplomb
- et parfois, je foirais la gestion des submodules à partir du répertoire de base quand je tentais de résoudre les pépins dans les sous répertoires …
Ça vous parle ? C'est moi qui ne sais pas m'y prendre ?
En tout, il va falloir que j'essaye cette appli !
Là, tout ce que j'ai automatisé, c'est la liste des repos dans une arborescence, avec branche courante, remote repos, et status (et options pour masquer l'un ou l'autre. Avec en plus la génération d'un script pour tout recréer dans un autre répertoire, à l'identique (même branche, même liste de remote). C'est pas rocket science, mais ça intéresse du monde ?
[^] # Re: submodules
Posté par betonniere (site web personnel) . Évalué à 1 (+0/-0).
J'ai vraiment l'impression de pouvoir faire la même chose avec les submodules. J'ai pas de difficulté particulière à les utiliser, je dirais même qu'à l'usage c'est une solution plutôt bien pensée.
# Et pour l'initialisation ?
Posté par claudix . Évalué à 1 (+1/-0).
Bonjour et merci pour ce partage !
J'ai exactement la même problématique au boulot pour 2 grosses applications maison composée chacune de multiples repo git.
On a développé un outil maison qui gère les git clone/pull/… un peu comme multigit. On se base sur un fichier de config qui ressemble furieusement à celui de multigit.
Les principales différences, c'est qu'on n'a pas d'IHM, et que notre outil gère en plus l'aspect installation via npm (tous nos modules sont en NodeJS), plus quelques subtilités liées à l'architecture de nos 2 applis.
Je me demandais : comment gérez-vous le deploiement initial ? Est-ce que chacun de vos développeurs gère lui-même ses propres git clone pour chacun de ses repositories ? Ou bien avez-vous des fichiers de config prêts à l'emploi que vous vous partagez selon le périmètre de travail de chacun ?
De notre côté, on a intégré 2 listes de modules pré-configurés, ce qui permet d'avoir rapidement un environnement prêt à l'emploi selon que l'on travaille sur l'une ou l'autre de nos 2 applications.
En tous cas, c'est intéressant de voir qu'à l'heure où les monorepos sont à la mode, le multirepos a toujours son mot à dire.
PS : j'ai tenté l'installation sous Ubuntu 24.04 via pipx. Malheureusement multigit renvoie une erreur de segmentation au démarrage.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.