Synchroniser son vault Obsidian sans conflits
Vos notes Obsidian vivent en plusieurs exemplaires : la machine du bureau, le portable, peut-être un serveur. Chaque copie diverge un peu, et le jour où deux versions se croisent, l'une écrase l'autre sans prévenir. C'est le conflit silencieux : une note disparaît, et vous ne le découvrez que des semaines plus tard, quand vous en avez besoin.
Cette masterclass vous donne la méthode git en cinq étapes pour synchroniser votre vault entre vos machines, GitHub et éventuellement un serveur : mettre le vault sous git, exclure les fichiers propres à chaque machine, envoyer sur un dépôt privé, automatiser l'envoi, savoir résoudre un conflit. Sans jamais écraser une version ni perdre une note.
Ce que cet exercice ne peut pas casser
L'exercice du jour se fait sur une feuille : vous ne tapez aucune commande, rien ne touche à vos notes. Et le prompt lui-même est verrouillé : il ne s'appuie que sur ce que vous lui donnez, vous demande ce qui lui manque au lieu de l'inventer, et vous prévient avant toute commande capable d'écraser des données.
Ce que vous saurez faire à la fin
- Mettre votre vault Obsidian sous git et l'envoyer sur un dépôt GitHub privé, dans le bon ordre.
- Exclure avant le premier envoi les fichiers propres à chaque machine, ceux qui créent des conflits en boucle.
- Automatiser l'envoi avec un script lançable d'un seul mot, testé à la main avant d'être mis en automatique.
- Faire suivre le vault par un serveur en lecture seule, qui ne risque jamais d'écrire dessus.
- Niveau membre· le prompt prêt à coller qui écrit votre .gitignore, vos commandes git dans le bon ordre et votre script de synchronisation, adaptés à votre système et à l'emplacement réel de votre vault.
- Niveau Pro· je monte la synchronisation avec vous, du premier envoi au serveur, et je débloque vos conflits en direct.
L'ordre protège vos notes : les exclusions avant le premier envoi, le test à la main avant l'automatique.
Cinq étapes, et pourquoi l'ordre compte
Synchroniser un vault sans perdre de note, ce n'est pas une affaire de talent technique : c'est une affaire d'ordre. Les exclusions s'écrivent avant le premier envoi, l'automatisme se teste à la main avant d'être lâché, le serveur ne reçoit que la lecture. Voici les cinq étapes, et le doute que chacune neutralise.
1Mettre le vault sous gitdoute : « git va-t-il toucher à mes notes ? »
Git transforme votre dossier de notes en dépôt : chaque version de chaque note est conservée, rien ne s'écrase plus jamais en silence. À ce stade, rien ne quitte votre machine. La règle d'or de toute la méthode : une commande par ligne, et au-dessus une phrase qui dit ce qu'elle fait et ce que vous devez voir si ça marche. Une commande approximative peut détruire des notes, donc on ne devine jamais : ce qui manque, on le demande.
2Exclure les fichiers propres à chaque machinedoute : « pourquoi ne pas tout synchroniser ? »
Trois familles de fichiers n'ont rien à faire dans la synchronisation : la disposition de votre espace de travail, les réglages internes des plugins, et les fichiers système de votre OS. Ils changent sur chaque machine, et si vous les envoyez, ils reviennent en boucle et fabriquent des conflits artificiels. C'est le rôle du fichier .gitignore, écrit AVANT le premier envoi, avec une ligne d'explication par exclusion.
3Envoyer sur un dépôt GitHub privédoute : « mes notes seront-elles visibles ? »
Le dépôt se crée en privé : vous seul y avez accès. Premier envoi, puis vérification à l'œil nu : vos notes doivent apparaître sur GitHub. À partir de là, votre vault a une copie hors de chez vous, avec tout son historique.
4Automatiser l'envoidoute : « et si l'automatisme casse quelque chose ? »
Un script lançable d'un seul mot fait le cycle complet : il récupère les dernières modifications, ajoute les vôtres, les envoie, et ne casse rien si vous n'avez rien changé. On le rend exécutable, puis on le lance à intervalle régulier. Mais d'abord, la note d'usage qui sauve : lancez-le à la main une première fois et vérifiez que vos notes apparaissent bien sur GitHub avant de le mettre en automatique. On fait confiance à un automatisme seulement après l'avoir vu marcher une fois sous ses yeux.
5Savoir résoudre un conflitdoute : « et si deux machines modifient la même note ? »
Avec cette méthode, le conflit cesse d'être silencieux : git s'arrête et vous demande de trancher, aucune version n'écrase l'autre dans votre dos. Et si vous avez un serveur, il récupère le vault en lecture seule, sans jamais écrire dessus : une machine qui ne fait que lire ne crée jamais de conflit. Restent trois pannes classiques, que le prompt vous apprend à régler en une ligne chacune : clé d'accès refusée, conflit après récupération, fichiers de configuration qui reviennent en boucle.
À vous de jouer : votre fiche de préparation
Prenez une feuille : vous réunissez les quatre informations dont le prompt a besoin pour tout générer sans rien inventer. Cochez à mesure.
Le résultat, en 30 secondes
À partir de vos quatre informations (système, chemin du vault, dépôt, serveur ou non), le prompt génère tout dans l'ordre : le .gitignore commenté, les commandes une par une avec ce que vous devez voir si ça marche, le script de synchronisation et sa mise en automatique.
Section 1, votre .gitignore : le bloc à coller, puis une ligne d'explication par exclusion (disposition de l'espace de travail, réglages internes des plugins, fichiers système). Section 3, votre script de synchronisation : le script complet, la commande pour le rendre exécutable, la commande pour l'automatiser. Section 5, si ça coince : clé d'accès refusée, conflit après récupération, fichiers de configuration qui reviennent en boucle, et la solution en une ligne chacune.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur qui accompagne des débutants complets en ligne de commande. Tu es pédagogue, précis, et tu ne fais jamais perdre de données. Tu ne t'appuies QUE sur ce que je te donne. Si une information te manque pour produire une commande correcte (chemin du vault, système d'exploitation, adresse du dépôt), tu me la demandes au lieu de l'inventer. Une commande approximative peut détruire des notes : tu préfères poser une question de plus plutôt que deviner. # CONTEXTE Je veux synchroniser mon vault Obsidian entre mes machines, GitHub, et éventuellement un serveur, sans jamais écraser une version ni perdre une note dans un conflit silencieux. Je pars de la méthode en 5 étapes : mettre le vault sous git, exclure les fichiers propres à chaque machine, envoyer sur un dépôt GitHub privé, automatiser l'envoi, savoir résoudre un conflit. Mes informations (si je les ai) :
Le prompt vous écrit votre .gitignore, vos commandes git dans le bon ordre et votre script de synchronisation, adaptés à votre système d'exploitation et à l'emplacement réel de votre vault. Et si un détail vous manque, il passe en mode interview et vous pose les questions une par une. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Votre script de synchronisation vient d'être généré et il a l'air parfait. Que faites-vous en premier ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui synchronise ses notes en copiant des dossiers à la main : pourquoi un conflit git vaut-il mieux qu'un conflit silencieux ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Dérouler les cinq étapes dans le bon ordre : git, exclusions, dépôt privé, automatisation, conflits.
- Tester tout automatisme à la main une fois avant de lui faire confiance.
- Donner au prompt les quatre informations qui lui évitent d'inventer un chemin ou une adresse.
On fait confiance à un automatisme seulement après l'avoir vu marcher une fois sous ses yeux.
Faites-le avec moi
Je monte la synchronisation avec vous, de la mise sous git au serveur en lecture seule, et nous réglons vos premiers conflits en direct. Vos notes cessent de dépendre d'un copier-coller.