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 (205 clics)
- Dépôt Github (143 clics)
- Téléchargement de la version 1.6.1 (44 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 3 (+1/-0).
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: submodules
Posté par betonniere (site web personnel) . Évalué à 2 (+1/-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.
[^] # Re: submodules
Posté par Philippe F (site web personnel) . Évalué à 7 (+5/-0).
J'ai essayé les sous-modules ainsi qu'une ou deux autres solutions mais je les ai rapidement rejetées par rapport à mon contexte. En effet :
mes collègues utilisent exclusivement une interface graphique pour interagir avec git (TortoiseGit majoritairement). A l'époque où j'ai écrit Multigit, aucun client git graphique ne fournissait une gestion des sous-modules. Pour eux, ça n'auraient pas été utilisable.
les sous-modules demandent un apprentissage nouveau au dessus de git. Les commandes n'ont pas les mêmes noms, et il y a des opérations en plus à effectuer. Une grande partie de mes collègues (surtout il y a 4 ans) étaient déjà à la peine avec l'utilisation de git toute simple. Mon objectif est de leur simplifier la vie, pas de la leur rendre plus complexe.
comme le décrit si bien AncalagonTotof, avec les sous-modules, on peut se rater. Ça offre encore plus de façon de se planter avant d'arriver à un résultat attendu. Notamment, il faut être très attentif au répertoire dans lequel on lance sa commande car le résultat peut n'avoir rien à voir.
Mon objectif en écrivant Multigit était vraiment la simplicité pour tout le monde:
pouvoir d'un coup d'oeil identifier les 7 dépôts modifiés parmi les 67 dépôts du projet et prendre quelques secondes pour vérifier le diff sur chacun
pouvoir faire les opérations du quotidien sur tous les dépôts ou un sous-ensemble de dépôt de façon très simple
utiliser uniquement des commandes git standard, visibles dans le log, de façon à ce que tout le monde comprenne ce qui se passe
D'après mes collègues, j'ai plutôt réussi ma mission. Et je suis tout fier quand je vois qu'il est sur tous les écrans des développeurs de mon boulot.
Cela dit, si les sous-modules marchent bien pour vous, continuez avec. J'ai aussi deux collègues (sur 300) qui en sont très contents et m'ont demandé d'en rajouter le support dans Multigit. J'attends d'avoir plus de demande avant de me lancer
Un truc que les sous-modules font de façon élégante, c'est l'atomicité: un changement sur plusieurs dépôts n'est réellement publié qu'après la mise à jour de dépôt parent. C'est cool, sauf que dans nos projets, on a jamais eu de problème d'atomicité. Par contre, on a très souvent eu des modifs oubliées parce qu'elles étaient dans un dépôt profond que le développeur avait oublié qu'il avait modifié. Et pas mal d'autres problématiques liées uniquement au fait que quand on manipule beaucoup de dépôts, on a vite fait d'en rater un.
[^] # Re: submodules
Posté par cosmocat . Évalué à 5 (+3/-0).
Je me permet quand même de remettre en cause cette affirmation (pas les autres arguments) : GitExtensions ( un client graphique pour Windows) possède le support des sous-modules depuis plus de 13 ans.
Note: pour l'exhaustivité de la discussion, l'autre solution (que certains disent plus facile que les sous-modules -mais que j'ai jamais testé--):
git subtreePar contre, l'intérêt des sous-modules, c'est que le commit est ajouté à un commit du dépôt parent comme cela tu garantie que la dépendance est dans la bonne version. Comment tu fais avec Multigit?
[^] # Re: submodules
Posté par Philippe F (site web personnel) . Évalué à 4 (+2/-0).
Merci, je trouvais plus le nom de l'autre solution que j'avais regardé. Je l'ai rejetée pour les mêmes raisons, elle introduit de la complexité par rapport aux commandes git classiques et ne permet pas d'interaction graphique simple.
On fonctionne plutôt avec des conventions: l'ensemble des dépôts doit être fonctionnel et stable sur la branche principale (dev chez nous) à sa dernière version. Pour introduire des changements, on va passer par des "features branch" (le git flow quoi) et quand elle est stable, on va merger toute ces branches dans dev. Et au moment où on appuie sur le bouton
git push, on publie.Il y a bien quelques secondes par jour où tu risques de tomber sur une dépendance désynchronisée, mais notre niveau d'activité est suffisamment faible pour que ça n'arrive jamais en pratique. Et même si ça arrivait, tu relances un
git pullet tout retombe dans l'ordre.C'est pas tellement distinct de la façon font fonctionne n'importe quel dépôt git, la branche principale doit être stable
[^] # Re: submodules
Posté par Vlobulle . Évalué à 3 (+1/-0). Dernière modification le 08 février 2025 à 16:57.
Pour avoir été dans la situation de l'op, à plusieurs reprises.
La problématique souvent rencontré, c'est que plusieurs équipes d'une même entreprise développent des outils ou librairies qui s'utilisent les unes les autres.
Donc à la fois, les process et les pratiques développement sont indépendantes, et il n'y a aucun "projet unique" qui regroupe tout (et surtout qui pourrait donner des directives). Et personne ne veut qu'une autre équipe puisse commiter sur le projet de son équipe, sauf à être explicitement autorisée. Des fois certaines équipes ne souhaitent même pas utiliser Git par exemple.
Et en même temps, il faut que tout le monde puisse accéder à toutes les versions du code de toute le monde, et ce rapidement.
Typiquement, utiliser les submodules, ben une équipe peut faire ce choix. J'ai essayé une fois. Personne n'a rien compris. On a continué à utiliser notre script qui récupérait les multiples repo git (et TFS, et les copies de fichiers en dur) nécessaires.
Un outil comme multi-git, chiadé et visuel aurait peut être pu prendre pour le coup.
[^] # Re: submodules
Posté par Philippe F (site web personnel) . Évalué à 2 (+0/-0).
Merci, ça fait plaisir de voir que l'outil a un sens dans d'autres organisations que la mienne!
Sur les interdépendances de librairies auxquelles tu dois pas toucher parce que tu risques de casser le projet d'un autre, mais que tu dois quand même modifier parce que t'en a besoin dans ton projet… on a exactement la même.
En théorie, on a résolu ça avec du gitflow, et des branches stables. Sauf que la définition de "stable" est très subjective. Stable, ça veut dire que ça casse pas mon projet. Mais j'ai aucun moyen de savoir si ça a cassé un des deux autres projets qui utilisent la même lib. Les trois projets sont bien sûrs en pression temporelle max, sans aucune marge de manoeuvre pour débugger un truc qui ne concerne pas directement le client.
On a proposé au management de mettre de la CI sur des projets de référence qu'on ne doit jamais casser mais ils ont refusé: ça coût trop cher d'avoir des intégrateurs qui feraient juste ça. Mieux vaut casser les projets de façon aveugle et les réparer à l'arrache, ça marche déjà très bien comme ça.
(je forcis un peu le trait, dans faits, on s'en sort mais il y a toujours un moment où tu es dans une zone aveugle en terme de modifications)
[^] # Re: submodules
Posté par AnthonyRabine (site web personnel) . Évalué à 0 (+0/-1).
La notion de submodules n'a rien à voir avec les multiples dépôts Git. Ça peut être des projets différents.
Oui pour le partage de ton script !!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2 (+0/-0).
Ce commentaire a été supprimé par l’équipe de modération.
# Et pour l'initialisation ?
Posté par claudix . Évalué à 3 (+3/-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.
[^] # Re: Et pour l'initialisation ?
Posté par Philippe F (site web personnel) . Évalué à 4 (+2/-0).
Oui, depuis quelques années, il y a pas mal d'outils qui fleurissent en ligne de commande pour gérer tout cela. Il y en avait un déjà quand j'ai commencé, c'était repo fourni par google pour Android.
De mon côté, j'ai peu développé l'aspect ligne de commande parce que c'est pas là où il y avait des besoins. Cela dit, ça revient lentement.
Pour le "bootstrap" d'un projet, deux approches possibles:
la plus simple : un développeur crée l'arborescence de dépôt dont il a besoin sur son poste. Multigit va découvrir tous les dépôts et il pourra exporter le fichier multigit pour ses camarades
le plus geek: tu prépares à la main le bon fichier multigit en JSON que tu refiles à tes camarades.
Dans les deux cas, chaque projet est défini par un fichier multigit que nous partageons dans un lieu central. Chacun va ensuite faire "clone from multigit file" et se retrouver avec un projet prêt à l'emploi.
Une autre fonction qui a été demandée et qui est bien pratique, c'est de mettre l'ensemble des dépôts dans le même état exact que celui de son voison, ou celui qui est sorti de la CI. C'est "Apply multigit file"
Pour ton segfault, c'est pas cool. Tu peux me contacter en privé stp à phil.fremy at free.fr ?
# En ligne de commande
Posté par Xavier Poinsard . Évalué à 3 (+2/-0).
Pour les adeptes de la ligne de commande, moi j'utilise https://github.com/tkrajina/git-plus qui permet des commandes genre "git multi pull".
[^] # Re: En ligne de commande
Posté par pushmepullme . Évalué à 1 (+0/-0).
Celui-ci également : https://github.com/mnagel/clustergit
Fait le job.
# Repo
Posté par Ochrin . Évalué à 3 (+3/-0).
Et par rapport a repo (l'outil de Google), cela apporte quoi de plus ?
[^] # Re: Repo
Posté par Philippe F (site web personnel) . Évalué à 5 (+3/-0).
Je dirais pas que ça apporte en plus, c'est une approche différente:
on continue à utiliser des commandes git contrairement à repo qui utilise une nomenclature différente: sync, upload, … . Pas besoin d'apprendre un nouvel outil et une nouvelle façon de fonctionner
il y a une interface graphique qui permet de repérer visuellement plus facilement l'état global d'un projet et d'agir facilement sur un sous-ensemble de dépôts
[^] # Re: Repo
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Est-ce que tu peux définir un "top niveau" qui peut résider dans un git qui contient la liste des repo git utiles ou est-ce du fichier local ?
"La première sécurité est la liberté"
[^] # Re: Repo
Posté par Philippe F (site web personnel) . Évalué à 3 (+1/-0).
C'est possible de définir un "top repo" qui contiendra tous les autres dépôts, y compris par exemple le fichier multigit décrivant la liste de tous les autres dépôts du projet. Ca te donne un workflow un tu clones le top dépôt avec git naturellement, puis tu récupères le fichier multigit pour cloner tous les sous-dépôts.
D'un point de vue multigit pur, il n'y a pas de notion de "top repo", il y a juste un répertoire qui contient un paquet de dépôt multigit avec un niveau d'imbrication quelconque. Notamment, tu peux tout à fait avoir une hiérarchie complexe:
Multigit va scanner le répertoire project recursivement pour identifier tous les dépôts git qu'il contient.
[^] # Re: Repo
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
ou est la doc qui explique tout ça ?
"La première sécurité est la liberté"
[^] # Re: Repo
Posté par Philippe F (site web personnel) . Évalué à 3 (+1/-0).
J'accepte les PR !
Mais c'est une bonne remarque, j'avais pas imaginé que ce point ne serait pas clair. Je rajouterai quelque chose dans le README au moins, voire dans un semblant de documentation un jour.
# Excellent
Posté par AnthonyRabine (site web personnel) . Évalué à 2 (+1/-0).
Bravo pour l'outil, qui semble bien fini et ergonomique (j'aime bien le popup du double click qui t'invite à configurer le comportement).
J'ai toujours voulu coder un outil similaire mais flemme, là très bien c'est fait.
J'ai une soixantaines de repos git donc c'est bien pratique en un coup d'oeil on voit le statut.
J'ai eu un popup d'erreur concernant l'objet HEAD sur quelques repositories mais ça n'a pas crashé.
# sympa
Posté par Selso (site web personnel) . Évalué à 1 (+0/-0).
Nous avons un dépot git avec (beaucoup) de sous-modules.
Même si la cohésion des répos est gérée par le système de sous modules, on partage des besoins sur notre workflow que cet outil semble vouloir résoudre.
La création de branche features du top projet et des sous-modules de travail.
Je verrais bien même la possibilité de raisonner à partir de l'ajout d'une feature qui automatise la création des branches et la creation d'une PR.
Même s'il doit être possible d'avoir la même vu en CLI sur les Repos, celle-ci est bien sympa.
S'il est en plus possible de partager la conf sur laquelle on bosse c'est bingo.
J'ai connu repo via Yocto, mais je n'ai pas l'impression qu'il gère un workflow de dev. Je peux me tromper cela dit.
Merci pour ce partage.
[^] # Re: sympa
Posté par Philippe F (site web personnel) . Évalué à 2 (+0/-0).
Oui, l'outil est très orienté "dev au quotidien" et couvre des aspects très pratiques comme créer une branche identique sur 10 dépôts différents répartis au hasard de ta hiérarchie de dépôt.
Il est envisageable de gérer également les sous-modules dans le futur dans Multigit. Voire de permettre la transition entre l'un et l'autre mode. On verra si la demande se concrétise un peu plus.
[^] # Re: sympa
Posté par Tangi Colin . Évalué à 3 (+2/-0).
Repo permet bien de gérer des worklow,
par example https://source.android.com/docs/setup/reference/repo?hl=fr#forall
Ou repo start pour crée le même nom de branche dans tout tes git.
Après côté yocto on utilise pas ces fonctions là parce que yocto n'ai pas un environnement de dev, c'est un environnement de génération de distribution.
# Repo manifest ou kas
Posté par Tangi Colin . Évalué à 1 (+0/-0).
Pour faire du multi git/git forest,tu as repo manifest coté Android ou kas coté yocto.
Pour gérer les droits d'accès dans git lui même,tu peux tout a fait faire ça dans le même git dans une branche dédié (et dans un refspec dédié) avec quelques git hook, c'est fait comme ça dans gerrit.
[^] # Re: Repo manifest ou kas
Posté par Philippe F (site web personnel) . Évalué à 2 (+0/-0).
Quand je parle de droits d'accès, je parle d'interdiction de lecture. Il ne me semble pas que ta proposition résolve ce problème, j'ai l'impression que tu me parles plus de protected branch.
Surtout que les git hooks, ça doit être installé manuellement pour fonctionner, donc tu n'as pas de garantie que tout le monde aie la même configuration de githook.
[^] # Re: Repo manifest ou kas
Posté par Tangi Colin . Évalué à 1 (+0/-0).
Git hook peut très bien être implémenté côté serveur. Et pour diffuser des githook côté client tu peux très bien aussi utiliser repo manifest (ou kas) pour ça, un repo qui contient tes githook dans ton manifest de gits avec une petite règle d'installation.
Pour les droits en lecture pas sur de comprendre, ça ce gère côté serveur pour moi, si le git est déjà descendu côté client tu pourras toujours le lire en utilisant pas ton outil non ?
[^] # Re: Repo manifest ou kas
Posté par Philippe F (site web personnel) . Évalué à 2 (+0/-0).
Sous git, je ne sais pas comment on peut autoriser la lecture d'un certain répertoire d'un dépôt à une équipe seulement et interdire à toutes les autres personnes d'y accéder. Sachant que ledit répertoire doit rester sous git pour être géré dans le projet comme le reste.
Peux-tu expliciter ta solution ? Pour moi, c'est impossible, git n'a pas été conçu pour interdire des accès à une partie d'un dépôt.
[^] # Re: Repo manifest ou kas
Posté par Tangi Colin . Évalué à 2 (+1/-0).
Si tu es sur une approche multi gît je comprends pas l'idée de vouloir interdire la lecture à un bout (un dossier) d'un git. Dans ce cas la je mettrais justement ce dossier dans son propre git dédié (avec donc ces propres droits d'accès)
Sur une approche mono git je pourrais comprendre l'envie d'avoir une ségrégation au niveau dossier mais sur une approche multi git j'ai du mal à saisir l'intérêt puisque n'importe quel dossier peu être un git dédié. Après effectivement gît dédié veut dire aussi son propre historique gît.
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.