perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.
Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des
perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.
Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des conflits avec Git et vous laisse gérer le reste.
Gitwand, c'est donc un client Git open source, sous licence MIT, qui classe chaque bloc conflictuel selon des règles fixes et ne résout automatiquement que ceux dont le résultat ne fait aucun doute.
Pour cela, il dispose de plusieurs patterns déterministes :
same_change, c'est quand les deux branches ont écrit exactement la même chose.
whitespace_only ne voit qu'une indentation qui a bougé,
reorder_only les mêmes lignes remises dans un autre ordre.
Un numéro de version qui change, lui, tombe dans value_only_change.
Et puis il y a complex, le fourre-tout des modifications qui se chevauchent pour de vrai. Celle-là n'est jamais tranchée toute seule.
git rerere rejoue les résolutions que vous avez déjà tranchées à la main,
et Mergiraf se branche directement dans git merge pour arbitrer en lisant l'arbre syntaxique de votre code.
Ce qui change ici, c'est que chaque décision est justifiée. En effet, chaque bloc reçoit un score de confiance ainsi qu'une trace qui nomme le motif retenu ligne par ligne.
Par exemple, si une branche écrit const theme = 'dark', et l'autre const theme = localStorage.getItem('theme') ?? 'dark', hé bien l'outil garde la seconde, étiquette sa décision prefer-theirs, et affiche 97 % de confiance à côté.
Sur la page d'accueil, l'outil annonce 95 % des conflits triviaux résolus automatiquement. Le moteur est aussi exposé aux agents IA via un serveur MCP, ce protocole qui branche des outils externes sur des assistants comme Claude Code ou Cursor. L'installation se fait comme ceci : claude mcp add gitwand -- npx -y @gitwand/mcp.
L'agent réclame un aperçu, récupère les blocs déjà réglés, et ne garde que les cas ambigus, avec les trois versions du code sous les yeux. Le modèle ne touche qu'à ce qu'aucune règle ne sait faire, soit l'inverse de ce qu'on voit d'habitude.
Le projet est jeune et ça se voit. Mais ça vaut le coup d'essayer parce que je pense que ça peut rendre de nombreux services. L'app existe pour macOS, Linux et Windows, l'interface est traduite en français, et elle se double d'une ligne de commande (npm i -g @gitwand/cli) et d'une extension VS Code.
Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé
thunderbird-patch-review
.
Il s'agit d'une extension pour
Thunderbird
qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.
Ensuite, si la sé
Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé
thunderbird-patch-review
.
Il s'agit d'une extension pour
Thunderbird
qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.
Ensuite, si la série des patchs vous convient, vous pouvez tous les approuver directement sur votre dépôt local avec la commande git-am sans jamais avoir à quitter votre client mail.
Pour lancer Git, l'extension utilise une API expérimentale maison qui embarque tout le nécessaire dans son paquet sans host de messagerie native à installer séparément. Ça fait un truc en moins à configurer et l'addon vérifie que tout est OK dans un worktree jetable, avant de valider la review.
Comme ça, s'il y a un conflit, le bouton Apply se grise et les erreurs remontent dans l'interface pour que vous puissiez toutes les revoir une par une et faire un retour propre à l'auteur.
Cet add-on a été vibe-codé avec GLM 5.2 et construit pour répondre aux besoins de son équipe. Il hésitait sincèrement à le partager parce que le monde n'est pas encore prêt pour le Vibe Coding, mais il explique sur son site qu'il y avait un sérieux manque d'outils dans l'écosystème pour pouvoir travailler sur des revues de patch directement dans son client mail.
Donc tant pis, yolo, il l'a publié quand même et je pense que ça devrait vous intéresser. Comme quoi
faire bosser un agent pour soi
n'oblige pas à le planquer.
Maintenant, les patches qui arrivent en pièce jointe ne sont pas encore gérés, les mails en HTML seul non plus, et la collecte d'une série ne cherche que dans le dossier du message ouvert. De plus, l'add-on n'est pas encore publié sur le store Thunderbird, donc vous devrez le packager vous-même en .xpi depuis la racine du projet :
Ensuite, vous chargez le fichier obtenu via le menu engrenage du gestionnaire de modules complémentaires (Installer un module depuis un fichier) et c'est réglé ! Rien de méchant si vous avez déjà bidouillé des extensions Thunderbird, genre
Send Later pour planifier vos envois
dont je vous parlais il y a un petit moment maintenant.
Voilà, si vous faites déjà du git par email, ça vaut le détour. Le code est en EUPL 1.2, et tout se passe ensuite sur la mailing list de Marc.
Branislav Đalić, un dev serbe basé à Belgrade, vient de balancer un projet plutôt original baptisé
GitLike
. Il s'agit d'un GitHub décentralisé qui stocke vos repos sur
IPFS
et remplace le mot de passe par votre clé Ethereum (votre wallet quoi...).
Vous connectez votre wallet via SIWE (le standard EIP-4361, signature dans MetaMask ou WalletConnect), vous créez un repo, et hop, chaque commit, chaque fichier, chaque arbre devient un objet IPFS adressé par son CID. Tout pareil que Git côté usage, s
Branislav Đalić, un dev serbe basé à Belgrade, vient de balancer un projet plutôt original baptisé
GitLike
. Il s'agit d'un GitHub décentralisé qui stocke vos repos sur
IPFS
et remplace le mot de passe par votre clé Ethereum (votre wallet quoi...).
Vous connectez votre wallet via SIWE (le standard EIP-4361, signature dans MetaMask ou WalletConnect), vous créez un repo, et hop, chaque commit, chaque fichier, chaque arbre devient un objet IPFS adressé par son CID. Tout pareil que Git côté usage, sauf que derrière y'a pas de serveur GitHub mais un simple Worker Cloudflare qui orchestre Pinata ou Filebase pour pinner vos données.
Côté install, la doc propose tout simplement de faire un npm install -g gitlike avec ensuite l'utiliser avec les commandes Git habituelles (init, clone, push, pull, branch), sauf que le package n'est pas encore publié sur npm public pour l'instant. Du coup, faudra patienter ou aller chercher le code directement dans le repo GitHub si vous voulez bricoler dès aujourd'hui.
La doc officielle mais l'install npm marche pas.
L'architecture tient en 3 étages bien séparés. Votre navigateur s'occupe de l'interface et de la signature avec le wallet, un petit serveur Cloudflare joue les videurs en backend (qui a le droit d'écrire, dans quel ordre, à quelle vitesse), et IPFS stocke tout le code en mode décentralisé via Pinata ou Filebase.
Et si vos repos doivent rester privés, vous pouvez activer un chiffrement qui se fait directement dans votre navigateur, comme ça personne d'autre ne lit vos fichiers en clair. En gros, votre onglet de navigateur fait office de vitrine, le Worker joue le mec de la sécu, et IPFS sert de coffre-fort distribué.
Le truc cool, c'est que GitLike peut importer votre code directement depuis GitHub ou GitLab, donc migrer un projet existant ne prend que quelques clics ! Et vous retrouvez tout le confort moderne, à savoir les pull requests avec gestion des conflits, des règles de protection sur les branches sensibles, et même un système pour déléguer l'écriture à un agent IA avec un périmètre limité dans le temps et l'espace (genre, commit uniquement sur telle branche, et seulement pendant 24h).
Sympa, donc, pour vibe coder avec un agent 100% autonome sans pour autant lui filer toutes vos clés et qu'il ne détruise tout dans une apocalypse nucléaire (Quoi, j'en fais trop ?)
Après même si l'idée semble sympa, je trouve que ça déplace le risque plutôt que de le faire disparaître. Parce que si vous paumez votre wallet, vous perdez l'accès en écriture (et possiblement en lecture si c'est chiffré) à tous vos repos, et y'a plus qu'à recommencer. Donc sauvegarder votre seed phrase (les 12 ou 24 mots de récupération du wallet, vous savez) est donc critique !
Côté concurrence, vous trouverez également
Radicle
qui fonctionne en peer-to-peer pur (mais demande un daemon local) ou l'ancien Mango (Ethereum + IPFS, mais plus trop maintenu). GitLike, lui, mise tout sur le navigateur et votre wallet, donc c'est plus simple !
Après c'est jeune et faut voir ça plus comme un proof of concept solide qu'un GitHub-killer. Mais ça tient bien la route et je trouve l'idée d'un Git contrôlé par un wallet ethereum plutôt classe. C'est peut-être ça le vrai web3 ;)))
Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.
En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <copilot@github.com> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement d
Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.
En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <copilot@github.com> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.
Et le résultat de tout ce bordel, vous pouvez le lire dans la
PR #310226
qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.
L'
issue de suivi #314311
, ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...
Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :
"git.addAICoAuthor": "off"
C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...
Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.
Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...
Et puis surtout il y a le
bug #313064
qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.
En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.
Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.
Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.
Windows Central
a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...
Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118 , le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la
PR #313931
, dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.
Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".
Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout a fait légitime.
VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.
En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même
jusque dans l'écosystème Apple via une extension Xcode
, dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.
Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur
VSCodium
ou
Zed
, deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez
Codeberg ou Forgejo
en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.
À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.
En ce moment, les développeurs s’extasiaient sur un truc appelé
Jujutsu
, ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.
Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contribut
En ce moment, les développeurs s’extasiaient sur un truc appelé Jujutsu, ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.
Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contributeur Mercurial, a décidé qu’on méritait mieux.
Du coup, il a créé Jujutsu, un système de contrôle de version qui garde tous les avantages de Git en supprimant ses complexités.
Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!
Pour installer jj, vous avez plusieurs options selon votre OS. Sur macOS avec Homebrew :
brew install jj
Sur Linux, utilisez le gestionnaire de paquets de votre distribution ou installez via Cargo :
# Via Cargo (nécessite Rust)
cargo install --locked jj
# Sur Arch Linux
pacman -S jujutsu
# Sur NixOS
nix-env -iA nixpkgs.jujutsu
Sur Windows, utilisez Winget ou Scoop :
# Via Winget
winget install --id martinvonz.jj
# Via Scoop
scoop bucket add extras
scoop install jujutsu
Une fois installé, configurez votre identité (comme avec Git) :
jj config set --user user.name "Votre Nom"
jj config set --user user.email "vous@example.com"
Premiers pas avec Jujutsu
Pour initialiser un nouveau repo jj ou coexister avec un repo Git existant :
# Créer un nouveau repo jj
jj git init myproject
# Coexister avec un repo Git existant
cd existing-git-repo
jj git init --git-repo=.
# Cloner un repo Git avec jj
jj git clone https://github.com/user/repo.git
Concrètement, ça change tout. Plus besoin de git add, plus de git stash avant de changer de contexte, plus de commits temporaires pour sauvegarder votre travail en cours. Jujutsu traite votre copie de travail comme n’importe quel autre commit dans l’historique, ce qui simplifie drastiquement le modèle mental.
Voici les commandes de base pour travailler avec jj :
# Voir l'état actuel (équivalent de git status + git log)
jj st
jj log
# Créer une nouvelle branche de travail
jj new -m "Début de ma nouvelle feature"
# Modifier des fichiers (pas besoin de git add !)
echo "Hello Jujutsu" > README.md
# Les changements sont automatiquement suivis
# Voir les modifications
jj diff
# Créer un nouveau commit basé sur le précédent
jj new -m "Ajout de la documentation"
# Revenir au commit précédent
jj edit @-
# Naviguer dans l'historique
jj edit <change-id></change-id>
Gestion des conflits façon Jujutsu
Le système gère aussi les conflits différemment car là où Git vous force à résoudre immédiatement,
jj peut sauvegarder les conflits directement dans l’arbre de commits
, sous forme de représentation logique plutôt que de marqueurs textuels. Vous pouvez donc reporter la résolution et vous en occuper quand vous avez le temps. Une fois résolu, jj propage automatiquement la solution aux commits descendants.
# Merger deux branches (les conflits sont sauvegardés si présents)
jj new branch1 branch2
# Voir les conflits
jj st
# Les conflits sont stockés dans le commit, vous pouvez continuer à travailler
jj new -m "Travail sur autre chose pendant que le conflit existe"
# Revenir résoudre le conflit plus tard
jj edit <conflict-commit-id>
# Après résolution manuelle
jj squash # Pour intégrer la résolution</conflict-commit-id>
Manipulation de l’historique
L’outil brille aussi par sa puissance d’annulation. L’operation log dépasse largement les reflogs de Git en gardant une trace atomique de toutes les modifications de références simultanément. Comme ça, vous pouvez expérimenter sans crainte, sachant qu’un simple jj undo peut rattraper n’importe quelle erreur.
# Voir l'historique des opérations
jj op log
# Annuler la dernière opération
jj undo
# Revenir à un état précédent spécifique
jj op restore <operation-id>
# Réorganiser des commits (équivalent de rebase interactif)
jj rebase -s <source> -d <destination>
# Éditer un commit ancien
jj edit <change-id>
# Faire vos modifications
jj squash # Pour intégrer dans le commit actuel
# Split un commit en plusieurs
jj split</change-id></destination></operation-id>
Workflow quotidien avec Jujutsu
Voici un exemple de workflow typique pour une journée de développement :
# Commencer une nouvelle feature
jj new main -m "feat: ajout authentification OAuth"
# Travailler sur les fichiers
vim auth.js
vim config.js
# Pas besoin de git add ! Les changements sont auto-trackés
jj diff # Voir ce qui a changé
# Créer un checkpoint pour continuer
jj new -m "wip: OAuth provider setup"
# Oh, un bug urgent à fix sur main !
# Pas besoin de stash, on switch directement
jj new main -m "fix: correction crash login"
# Fix le bug
vim login.js
# Revenir à notre feature OAuth
jj edit @- # Revient au commit précédent
# Finaliser la feature
jj describe -m "feat: authentification OAuth complète"
# Pusher vers Git
jj git push
Intégration avec Git
Côté compatibilité, c’est du 100% Git. Jujutsu utilise les dépôts Git comme backend de stockage, ce qui signifie que vos collègues peuvent continuer avec Git classique sans même savoir que vous utilisez jj. Et si vous changez d’avis, supprimez juste le dossier .jj et tout redevient normal.
# Synchroniser avec le remote Gitjjgitfetch# Pusher vos changementsjjgitpush# Créer une branche Git depuis un change jjjjbranchcreatema-featurejjgitpush--branchma-feature# Importer les changements depuis Gitjjgitimport# Exporter vers Git (automatique généralement)jjgitexport
Commandes avancées utiles
Selon les retours d’utilisateurs
, même les experts Git qui maîtrisent parfaitement les rebases complexes découvrent qu’ils n’ont plus peur de manipuler l’historique. Réordonner des commits, corriger une modification ancienne, jongler avec plusieurs branches non mergées… tout devient trivial avec jj.
# Voir l'historique en mode graphique
jj log --graph
# Chercher dans l'historique
jj log -r 'description(regex:"fix.*bug")'
# Travailler avec plusieurs parents (merge commits)
jj new parent1 parent2 parent3
# Abandonner des changements locaux
jj abandon <change-id>
# Dupliquer un commit ailleurs
jj duplicate <change-id> -d <destination>
# Voir les changements entre deux commits
jj diff -r <from> -r <to>
# Créer un alias pour une commande fréquente
jj config set --user alias.l 'log --graph -r "ancestors(., 10)"'
jj l # Utilise l'alias</to></from></destination></change-id></change-id>
Configuration et personnalisation
Pour personnaliser jj selon vos besoins :
# Définir votre éditeur préféré
jj config set --user ui.editor "code --wait"
# Activer les couleurs dans le terminal
jj config set --user ui.color "always"
# Configurer le format de log par défaut
jj config set --user ui.default-revset "@ | ancestors(@, 10)"
# Voir toute la configuration
jj config list --user
# Éditer directement le fichier de config
jj config edit --user
Le projet évolue rapidement et l’équipe travaille sur plusieurs backends, y compris un natif qui pourrait dépasser Git en performance sur de gros dépôts.
Évidemment, Jujutsu reste expérimental. L’écosystème est plus petit, les intégrations IDE limitées (bien qu’il y ait déjà des extensions VSCode et Vim), et la terminologie différente demande un temps d’adaptation. Mais pour ceux qui cherchent une approche plus intuitive du contrôle de version, ça vaut franchement le détour.
Pour aller plus loin, je vous conseille de parcourir le
tutoriel officiel
qui couvre des cas d’usage plus avancés, ou de rejoindre le
Discord de la communauté
où les développeurs sont très actifs et répondent aux questions.
Bref, vous l’aurez compris,
jj ne remplace pas Git dans l’immédiat
. Il le sublime en gardant la compatibilité totale. C’est une approche intelligente qui permet d’adopter progressivement un workflow plus fluide sans perturber les équipes de dev.
Vous en avez assez de jongler entre Git et YAML pour mettre à jour votre site Next.js, Astro, Hugo ou Nuxt ? Simplifiez-vous la vie en installant un CMS convivial directement sur GitHub à l’aide de Pages CMS, la nouvelle coqueluche des gestionnaires de contenu pour les sites statiques.
Avec cet outil, fini les prises de tête avec les fichiers de configuration et les commits laborieux puisqu’il s’intègre de manière transparente à votre dépôt GitHub, vous permettant de gérer votre contenu dir
Vous en avez assez de jongler entre Git et YAML pour mettre à jour votre site Next.js, Astro, Hugo ou Nuxt ? Simplifiez-vous la vie en installant un CMS convivial directement sur GitHub à l’aide de Pages CMS, la nouvelle coqueluche des gestionnaires de contenu pour les sites statiques.
Avec cet outil, fini les prises de tête avec les fichiers de configuration et les commits laborieux puisqu’il s’intègre de manière transparente à votre dépôt GitHub, vous permettant de gérer votre contenu directement depuis une interface intuitive. Ainsi, vous pourrez personnaliser vos types de contenu, vos vues, votre recherche… et côté édition, vous profiterez d’un éditeur de texte riche avec coloration syntaxique, d’un glisser-déposer pour vos fichiers, d’une recherche full-text hyper rapide… Le tout saupoudré de fonctionnalités bien pensées comme la planification de mises à jour ou le contrôle d’accès granulaire.
Pages CMS est 100% gratuit, open source et vous pouvez l’utiliser en ligne ou l’auto-héberger sans débourser un centime. En quelques clics, vous créez votre compte, connectez votre dépôt GitHub et hop, vous voilà paré pour dompter votre contenu comme un pro. C’est beau, la vie de développeur, non ? 🌈
Bon, je vous vois venir avec vos grands chevaux. « Mais est-ce que ça va pas transformer mon dépôt en usine à gaz ?« . Que nenni ! Pages CMS est une simple appli front-end avec des fonctionnalités backend limitées. Ça tourne sur Cloudflare Pages et ça n’interfère en rien avec votre code. Et si vous voulez garder la main, vous pouvez toujours passer par Git pour les modifications sensibles.
En parlant de Git justement, je vous rassure tout de suite : Pages CMS n’a pas accès à TOUS vos dépôts. Il utilise le flux OAuth de GitHub pour des autorisations ciblées. Et vos tokens d’accès ne sont jamais stockés côté serveur. Votre code reste votre précieux, comme dirait Gollum.
Pour l’installer, rendez-vous sur pagescms.org, créez votre compte en deux clics et connectez votre dépôt GitHub. Et voilà, vous êtes prêt à dompter votre contenu. Et pour les adeptes de l’auto-hébergement, comptez 10 petites minutes pour déployer Pages CMS sur votre compte Cloudflare.
Sur ce, je vous laisse, j’ai du contenu à publier moi. Allez, tchô la compagnie ! 👋
Je vais pas y aller par 4 chemins : Radicle, c’est comme Github mais en version totalement décentralisée et open source. C’est basé sur Git, le système de contrôle de version distribué par excellence, et l’outil y ajoute une couche peer-to-peer (P2P) qui permet aux utilisateurs de collaborer directement les uns avec les autres, sans passer par un intermédiaire.
Comme ça, terminé la dépendance à une plateforme unique qui peut censurer ou contrôler vos dépôts de code.
Niveau fonctionna
Je vais pas y aller par 4 chemins : Radicle, c’est comme Github mais en version totalement décentralisée et open source. C’est basé sur Git, le système de contrôle de version distribué par excellence, et l’outil y ajoute une couche peer-to-peer (P2P) qui permet aux utilisateurs de collaborer directement les uns avec les autres, sans passer par un intermédiaire.
Comme ça, terminé la dépendance à une plateforme unique qui peut censurer ou contrôler vos dépôts de code.
Niveau fonctionnalités, il propose des outils de collaboration avancées, comme un système d’issues et de pull requests lui aussi entièrement décentralisé, ce qui vous permettra d’ouvrir des tickets, proposer des modifications et discuter avec vos collaborateurs, sans jamais quitter Radicle. Puis c’est sécurisé avec du chiffrement intégré directement dans le protocole Radicle.
C’est un outil qui offre une résilience et une disponibilité accrues par rapport aux plateformes centralisées car même si certains nœuds du réseau tombent en panne, vos dépôts resteront accessibles et vos collaborations pourront se poursuivre sans interruption.
Pour l’installer chez vous :
curl -sSf https://radicle.xyz/install | sh
Pour résumer, ses points forts sont donc la :
Décentralisation : C’est entièrement décentralisé, ce qui signifie que vous n’êtes plus dépendant d’une plateforme centralisée unique. Vous collaborez directement avec vos pairs, sans intermédiaire.
Souveraineté : Vous avez le contrôle total sur vos données et vos interactions. Vous décidez avec qui vous partagez votre code et comment vous collaborez, sans subir de règles imposées.
Résilience : Grâce à son architecture peer-to-peer, il offre une grande résilience. Même si certains nœuds tombent en panne, vos dépôts restent accessibles et vos collaborations peuvent continuer.
Ouverture : C’est open source, ce qui signifie que son code est auditable et transparent. Vous pouvez avoir confiance dans la plateforme que vous utilisez.
Bien que Radicle soit encore un projet relativement jeune, il a déjà attiré l’attention de nombreux développeurs qui cherchent une alternative plus libre et plus résiliente aux plateformes centralisées, surtout depuis que Github a été racheté par Microsoft. Des outils d’intégration pour les principaux IDEs et éditeurs de code sont également en cours de développement, ce qui rendra l’adoption de Radicle encore plus facile et transparente.
Bref, si vous êtes un développeur soucieux de votre indépendance et de la pérennité de vos projets, Radicle est certainement une plateforme à considérer.
Vous êtes-vous déjà demandé ce qui se cache dans les profondeurs obscures des dépôts Git publics ? Eh bien, figurez-vous qu’il y a un outil en ligne qui permet de dénicher des trucs de dingue ! Ça s’appelle Grep.app et c’est un moteur de recherche qui va vous faire halluciner.
Concrètement, vous balancez votre recherche dans la barre et hop, ça vous sort tous les résultats où votre mot-clé apparaît dans les repos Git publics. Genre, vous tapez une adresse email et vous tombez sur tous les
Vous êtes-vous déjà demandé ce qui se cache dans les profondeurs obscures des dépôts Git publics ? Eh bien, figurez-vous qu’il y a un outil en ligne qui permet de dénicher des trucs de dingue ! Ça s’appelle Grep.app et c’est un moteur de recherche qui va vous faire halluciner.
Concrètement, vous balancez votre recherche dans la barre et hop, ça vous sort tous les résultats où votre mot-clé apparaît dans les repos Git publics. Genre, vous tapez une adresse email et vous tombez sur tous les endroits où elle est mentionnée. Mais attention, hein… Y a pas que des trucs anodins qui traînent dans ces dépôts. Si vous cherchez un peu, vous pouvez même tomber sur des clés d’API AWS ou Google !
Bon, après faut pas déconner non plus. Si vous tombez sur des clés dans un dépôt public, considérez-les comme grillées direct. Même si le dépôt est supprimé par la suite, y a plein de petits malins qui font ce genre de recherches régulièrement. Donc méfiance !
Cela dit, Github a quand même mis en place un système d’alerte pour les clés, mots de passe, etc qui se retrouvent dans le code. Du coup, y a des chances que la plupart soient invalidées assez vite, soit par le développeur qui change sa clé, soit direct par le fournisseur. Mais on n’est jamais trop prudent…
En parlant de Github, ils ont aussi leur propre outil de recherche de code qui est plutôt balèze. Ça s’appelle Github Code Search. Ça indexe environ 45 millions de dépôts, ce qui est déjà pas mal !
En gros, ils utilisent un moteur de recherche maison qui indexe le contenu avec une technique appelée « sparse ngrams ». D’après eux, ça permet d’exécuter les recherches plus rapidement, tout en étant un index plus petit. Si vous voulez en savoir plus sur la technologie derrière, ils ont publié un article de blog super intéressant.
Maintenant, est-ce que Grep.app est à la hauteur face à Github Code Search ? Difficile à dire… Une chose est sûre, c’est que Grep.app a l’air de se concentrer uniquement sur le code en lui-même. Donc si vous cherchez des chaînes de texte dans de la prose qui se retrouve dans des recherches de code, vous risquez de passer à côté avec Grep.app. Genre pour chercher dans des fichiers texte ou Markdown.
Et ça, c’est un peu dommage. Parce que des fois, on a besoin de chercher du code avec plein de caractères spéciaux vicieux. Et là, la recherche de code actuelle de Github nous laisse tomber. Mais bon, on peut pas tout avoir non plus… En attendant, Grep.app reste quand même un outil bien pratique pour dénicher des infos cachées dans les entrailles de Git. Et puis c’est gratuit et open-source en plus !
Connexion
