Je pense être arrivé à une solution plus ou moins satisfaisante pour le Projet 19 - "Documenter une méthode pour synchroniser un monorepo vers des multirepos qui fonctionne dans les deux sens".

Voici-ci, ci-dessous, les étapes de la démonstration qui sont détaillées dans le README.md du repository poc-git-monorepo-multirepos-sync.

Je crée deux repositories : frontend et backend (multi repositories) ;
J'utilise le script tomono pour les intégrer dans un monorepo nommé monorepo ;
J'ajoute deux fichiers à la racine de monorepo : README.md et .mise.toml ;
J'effectue des changements dans le repository frontend, je commit ;
Je pull les changements du repository frontend vers monorepo ;
Dans monorepo, j'effectue des changements dans le dossier frontend/, je commit ;
J'utilise cd frontend/; git format-patch --relative -1 HEAD pour générer un patch qui contient les changements que j'ai effectués dans le dossier frontend/ ;
Je vais dans le repository frontend et j'applique les changements contenus dans ce patch avec la command git apply monpatch.patch ou avec git am monptach.patch.

Pour le moment, j'ai privilégié l'option git patch, parce que je souhaite suivre la méthode la plus "manuelle" que j'ai pu trouver lorsque je dois intervenir sur les repositories upstream, parce que je ne veux prendre aucun risque de perturber mes collègues avec mon initiative de monorepo.

Le repository GitHub suivant contient le résultat final du monorepo : https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync-result-example/.

Est-ce que je suis satisfait du résultat de cette démo ?

La réponse est oui, bien que je ne sois pas satisfait de quelques éléments.
Par exemple, les fichiers de frontend présents dans ce commit ne sont pas dans le dossier frontend. J'aimerais que ces titres de commits contiennent un prefix [frontend] ... et [backend].... Je pense que cela doit être possible à implémenter en modifiant le script tomono.

Est-ce que c'est pénible à utiliser ? Pour le moment, ma réponse est « je ne sais pas ».

Je vais tester cette méthode avec deux projets. Je pense écrire une note de bilan de cette expérience d'ici à quelques semaines.

En travaillant sur Projet 19, #JaiDécouvert le projet git-branchless (https://github.com/arxanas/git-branchless).

High-velocity, monorepo-scale workflow for Git.

Je n'ai pas encore compris à quoi cela sert.

#JaiDécouvert Sourcebot (from) :

Sourcebot is an open-source code search tool that allows you to quickly search across many large codebases.

C'est une alternative à Sourcegraph.

Je suis ravi de voir qu'il existe de plus en plus d'alternatives communautaires à GitHub ou GitLab, comme Forgejo, Weblate, Woodpecker CI et maintenant Sourcebot.

#JaiDécouvert Radicle (from).

Depuis des années, j'essaie de suivre avec rigueur la doctrine suivante dans les projets utilisant le workflow Trunk-Based Development.

La branche trunk doit toujours être stable et contenir uniquement du code fonctionnel.
Le code obsolète ou inutilisé doit être supprimé de la branche trunk.
Aucun code commenté ne doit figurer dans la branche trunk.
La branche trunk ne contient pas de tests qui échouent.

Pourquoi ?

Pour éviter qu'un développeur perde du temps à essayer de faire fonctionner quelque chose qui n'est pas en état de marche.
Pour éviter qu'un développeur refactore du code mort — j'ai observé à nouveau cela, il n'y a pas longtemps 😔. Quand le développeur fini par le découvrir, il est généralement très frustré.
Pour éviter l'installation et la mise à jour de bibliothèques qui alourdissent inutilement le projet.
Pour prévenir une perte de confiance dans le projet (voir l'hypothèse de la vitre brisée).

Et si j'ai besoin de ce code plus tard ?

Tout d'abord, je vous réponds "YAGNI" 🙂.

Plus sérieusement, ma réponse est que votre code ne sera pas perdu étant donné qu'il est versionné dans votre repository.

Si le code commenté est en cours de développement, alors je suggère d'extraire ce code en préparation dans une Merge Request et de la merger quand elle sera prête.

Trouvez le bon équilibre

Un morceau de code commenté ou un test qui échouent peut tout à fait rester dans trunk sur une courte période. Dans ce cas, je conseille d'ajouter en commentaire un lien vers l'issue de dette technique qui détaille l'action prévue.

Après avoir rédigé la note Commit Cavalier, #JaiDécouvert le concept de des projets de loi omnibus.

« Depuis les années 1980, cependant, les projets de loi omnibus sont devenus plus courants : ces projets de loi contiennent des dispositions, parfois importantes, sur un éventail de domaines politiques. »

-- from

Ceci m'a fait penser aux Merge Requests qui contiennent de nombreux petits commits, souvent de refactoring, qu'il serait fastidieux de passer en revue individuellement.

Je pense que je vais nommer ces Merge Request, des Merge Request Omnibus, ce néologisme sera une de mes marques idiosyncrasiques 😉.

J'ai donc décidé de baptiser ces Merge Requests des Merge Requests Omnibus. Ce néologisme deviendra l'une de mes marques idiosyncrasiques 😉.

Je tente ici de présenter la notion de Git Commit dit "cavalier" en la reliant au concept de Cavalier Législatif.

Un cavalier législatif est un article de loi qui introduit des dispositions qui n'ont rien à voir avec le sujet traité par le projet de loi.

Ces articles sont souvent utilisés afin de faire passer des dispositions législatives sans éveiller l'attention de ceux qui pourraient s'y opposer.

-- from

Dans le contexte de développement logiciel, un Commit Cavalier désigne un commit inséré dans une Pull Request ou Merge Request qui n’a aucun lien direct avec l’objectif principal de celle-ci.

Cette pratique pose les problèmes suivants :

Cela rend la Merge Request plus difficile à review ;
Cela rend la Merge Request plus longue à review ;
Cela lance des discussions sans lien avec l'objectif de la Merge Request ;
Le Commit Cavalier devient "invisible" au reste de l'équipe ;
L'auteur peut mettre la pression au reviewer pour merger son Commit Cavalier sous prétexe que la Merge Request doit être mergé rapidement.

Il va sans dire que cette pratique a le don de m'irriter profondément. Par respect pour mon reviewer et mon équipe, je veille scrupuleusement à ne jamais soumettre de commit cavalier.

Depuis 2012, je pratique exclusivement le Git Rebase Workflow pour tous mes projets de développement.

Concrètement :

J'utilise git pull --rebase quand je travaille dans une branche, généralement une Pull Request ou Merge Request ;
Je pousse régulièrement des commits en "work in progress" au fil de l'avancée de mon travail dans ma branche de développement avec la commande git commit -m "WIP"; git push ;
Une fois le travail terminé, je squash mes commits à l'aide de git rebase -i HEAD~[NUMBER OF COMMITS] ;
Ensuite, je rédige un commit message qui contient la description du changement et le numéro de l'issue ou de la merge request git commit --amend ;
Enfin, j'effectue un Merge en Fast-Forward en utilisant l'interface de GitHub ou GitLab.

Pour cela, je paramètre GitLab de la façon suivante (navigation "Settings" => "General") :

Ou alors je paramètre GitHub de la façon suivante (navigation "Settings" => "General")

Les avantages de cette pratique

L'approche Rebase + Squash + Merge Fast-Forard permet de maintenir l'historique de changements linéaire, rendant celui-ci plus facile à lire et à comprendre.

L'historique ne contient aucun commit de fusion inutile.

Cela facilite la mise en place d'Intégration Continue.

Tous les problèmes, bugs, et conflits sont traités dans les branches, dans les Merge Request et jamais dans la branche main qui se doit d'être toujours stable, ce qui améliore grandement le travail en équipe.

Ce workflow est particulièrement puissant lorsque l'historique linéaire ne contient que des commit dit "atomic", c’est-à-dire : 1 issue = 1 merge request = 1 commit. Un commit est considéré comme "atomic" lorsqu'il ne contient qu'un seul type de changement cohérent, tel qu'une correction de bug, un refactoring ou l'implémentation d'une seule fonctionnalité.

À de rares exceptions près, le code source de la branche main doit rester stable et cohérent tout au long de l'historique des commits.

Cette discipline favorise un travail collaboratif de qualité, rendant plus compréhensible l'évolution du projet.

De plus, l'atomicité des commits facilite la revue des Merge Request et permet d'éviter les Commits Cavaliers.

Généralement je couple ce Git workflow au workflow nommé Trunk-Based Development.

#JaiDécouvert un article très intéressant qui répertorie les difficultés classiques rencontrées par les développeurs avec git rebase, ainsi que des solutions pour y remédier :git rebase: what can go wrong?.

#JaiDécouvert ce guide pour Git : Flight rules for Git.

Je le trouve excellent 👌.

Et voici une autre article intéressant au sujet de Git rebase : git rebase in depth.

Article que je trouve intéressant au sujet du le découpage des commit #git When to split patches for PostgreSQL | Peter Eisentraut

Ce mois de janvier est riche en article au sujet des Monorepo !

#JaiLu le contre pied du l'article "Monorepos: Please don’t" : Monorepo: please do! !

As a leader, I’ll pick the monorepo every time: because tools must reinforce the culture I want, and culture comes from the tiny decisions and behaviors of a team every day.

source

👌

Son thread Hacker News : 161 commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos and the Fallacy of Scale | Hacker News".

J'ai trouvé l'article très intéressant ainsi que les commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos: Please don’t".

Il contient de très bons commentaires biens argumentés qui expliquent les avantages des Monorepo, j'ai trouvé cela passionnant 🙂.

#JaiDécouvert le site "Advantages of monorepos" (https://danluu.com/monorepo/).

Avantages :

« Simplified organization » 👌
« Simplified dependency management » 👌
« atomic changes » 👌
« Extensive code sharing and reuse » 👌
« Unified versioning, one source of truth » 👌
« Code visibility and clear tree structure providing implicit team namespacing » 👌
« Large-scale refactoring » 👌
« Collaboration across teams » 👌

J'ai été perturbé par le contenu des slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos (voir 2017-12-03_1217).

J'ai continué à étudier le sujet des Monorepo et j'ai commencé à migrer un side project vers ce pattern. Pour le moment, l'expérience est très agréable. Je pense que je vais continuer dans cette direction.

#JaiLu les slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos.

#JaiDécouvert l'outil Git Subtree Splitter (https://github.com/splitsh/lite).

https://trunkbaseddevelopment.com/

Ma définition dans 2024-08-20_2326.

Voir aussi Multirepos.

https://github.com/splitsh/lite

Voir aussi Monorepo.

https://github.com/hraban/tomono

Date de la création de cette note : 6 décembre 2024.

Quel est l'objectif de ce projet ?

En décembre 2017, convaincu par les avantages du modèle Monorepo, j'ai effectué un véritable changement de paradigme en abandonnant le modèle Multirepos.

Depuis, je n'ai eu aucun regret. J'utilise le modèle Monorepo dans tous mes projets, car il simplifie énormément la plutpart des workflow, notamment l'onboarding, grâce à des kits de développement simplifiés.

Cependant, le modèle Multirepos est très populaire, je le rencontre partout où j'interviens.
Cela me perturbe beaucoup, car je constate à chaque fois que ce modèle complique tout. L'onboarding, le flux de travail, de déploiement, la documentation…

L'objectif de ce projet est de documenter une méthode et des outils qui me permettent de maintenir en douceur, sans rien imposer, un monorepo qui contient un development kit de qualité, agréable à utiliser.

Je souhaite pouvoir travailler dans ce monorepo tout en envoyant mon travail dans des branches sur les multi repositories d'origine.

Je souhaite aussi pouvoir pull les changements des multi repositories vers mon monorepo.

Ces deux user stories me permettront d'améliorer le monorepo sans modifier le workflow de développement des autres membres de l'équipe.

Une fois le kit de développement du monorepo opérationnel, je pourrai présenter ce projet à l'équipe pour leur en montrer le fonctionnement, les avantages, ainsi que sa simplicité d'utilisation et d'onboarding.

Au final, il reviendra à l'équipe de décider si elle souhaite adopter ce paradigme ou non.

Repository de ce projet :

https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync

Ressources :