Faire de la pull request la règle, et documenter la bifurcation

La page supposait partout que le contributeur a les droits d'écriture sur le
dépôt : l'option « créer une branche et ouvrir une pull request » de l'éditeur
Gitea n'apparaît que dans ce cas, et la procédure locale poussait une branche
directement sur le dépôt. Quelqu'un d'extérieur à l'équipe tombait sur une
bifurcation sans savoir ce que c'était.

Les deux parcours sont donc repris autour de la bifurcation, et la pull request
est présentée comme la règle pour tout le monde, mainteneurs compris — avec la
raison plutôt que l'injonction : relecture, trace des discussions, et le droit
de laisser un texte reposer sans qu'il soit déjà en ligne. Le push direct est
ramené à ce qu'il doit être, un geste d'urgence.

La procédure locale gagne les étapes qui manquaient : remote upstream, mise à
jour de main avant de créer une branche, build --strict avant de proposer. Et
pour Obsidian, se placer sur sa branche avant d'écrire, puisque la sauvegarde
automatique pousse sur la branche courante.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PcZ7hL9aVvMhRuzxXLT2DG

README.md

@@ -12,14 +12,17 @@ Construit avec **MkDocs Material**. Les sources sont des fichiers Markdown ; le
 | Ce que vous voulez faire | Ce que vous faites | Détail |
 |---|---|---|
 | Corriger une faute, mettre à jour une info | Éditer la page dans Gitea, ouvrir une **pull request** | [Contribuer](https://wiki.alpinux.org/contribuer/) |
-| Écrire un article, travailler hors ligne | Cloner le dépôt, **une branche par sujet**, pull request | [Rédiger depuis son ordinateur](https://wiki.alpinux.org/contribuer/#rediger-depuis-son-ordinateur) |
+| Écrire un article, travailler hors ligne | **Bifurquer**, cloner, une branche par sujet, pull request | [Rédiger depuis son ordinateur](https://wiki.alpinux.org/contribuer/#rediger-depuis-son-ordinateur) |
-| Rédiger dans Obsidian | Ouvrir ce dossier comme coffre — il est déjà configuré | idem |
+| Rédiger dans Obsidian | Ouvrir le clone comme coffre — il est déjà configuré — sur une branche | idem |
 | Relire et publier une contribution | Fusionner la pull request : la publication suit | ci-dessous |
 | Comprendre pourquoi ça n'est pas en ligne | Lire le journal de déploiement sur le serveur | [Déploiement du wiki](https://wiki.alpinux.org/technique/deploiement-wiki/) |
 
 **Personne n'a de build à lancer ni de fichier à copier sur le serveur.** Publier, c'est
-faire arriver du contenu sur la branche `main` de ce dépôt — que ce soit par une pull
+fusionner une pull request : le contenu arrive sur `main`, le reste est automatique.
-request fusionnée ou par un push direct.
+
+> **La pull request est la règle, pour tout le monde.** On ne modifie pas `main`
+> directement, même quand on en a le droit : c'est ce qui permet la relecture, garde une
+> trace des discussions, et laisse le temps à un texte de reposer avant d'être publié.
 
 ---
 
@@ -42,9 +45,10 @@ ligne intact plutôt que de le publier à moitié.
 
 ### Les deux pièges à connaître
 
-> **Un push sur `main` est une publication.** Pas de relecture, pas d'étape de validation :
+> **Un commit sur `main` est une publication.** Pas de relecture, pas d'étape de
-> le site est reconstruit dans la foulée. Les brouillons vont sur une branche. Cela vaut
+> validation : le site est reconstruit dans la foulée. D'où la règle ci-dessus — les
-> aussi pour la sauvegarde automatique d'Obsidian Git, qui commite et pousse toute seule.
+> brouillons vivent sur une branche. Attention en particulier à la sauvegarde automatique
+> d'Obsidian Git, qui commite et pousse toute seule sur la branche courante.
 
 > **Le webhook est attaché à ce dépôt.** Un push dans l'ancien monorepo
 > `alpinux.site.2026`, qui a longtemps hébergé le wiki, ne publie plus rien.

docs/contribuer.md

@@ -117,6 +117,19 @@ C'est la façon la plus simple de contribuer : corriger une faute, compléter un
 
 10. Cliquez sur **« Proposer la modification »**.
 
+!!! info "Si Gitea vous parle de « bifurcation »"
+    Selon vos droits sur le dépôt, deux situations :
+
+    - **Vous êtes membre de l'équipe du wiki** : l'éditeur s'ouvre directement et vous
+      créez une branche dans le dépôt, comme décrit ci-dessus.
+    - **Vous n'avez pas encore les droits d'écriture** : Gitea vous propose de créer une
+      **bifurcation** (*fork*), c'est-à-dire votre copie personnelle du dépôt. Acceptez :
+      votre modification y est enregistrée, et la pull request la propose au wiki. Le
+      résultat est le même, la copie sert juste de brouillon qui vous appartient.
+
+    Dans les deux cas, vous n'écrivez jamais directement sur le site en ligne : c'est la
+    fusion de la pull request par un mainteneur qui publie.
+
 ---
 
 ## Étape 3b — Proposer un nouvel article
@@ -252,17 +265,40 @@ Les mainteneurs peuvent consulter la [procédure de déploiement](technique/depl
 Pour un article long, une série de corrections ou un travail hors connexion, il est plus
 confortable de travailler sur une copie locale du wiki.
 
-### Récupérer le wiki
+La règle est la même que depuis le navigateur : **on ne modifie jamais `main`
+directement**. On travaille sur une branche, et on propose son travail par une pull
+request. Cela vaut pour tout le monde, mainteneurs compris.
+
+### 1. Bifurquer, puis cloner
+
+Créez votre **bifurcation** (*fork*) du wiki : sur
+[le dépôt](https://gitea.alpinux.org/alpinux.cedrica5l/alpinux-wiki), bouton
+**Bifurcation** en haut à droite. Vous obtenez votre propre copie, dans laquelle vous
+pouvez tout faire sans rien risquer.
+
+Clonez ensuite **votre** copie, et gardez un lien vers le dépôt d'origine pour pouvoir
+vous mettre à jour :
 
 ```bash
-git clone git@gitea.alpinux.org:alpinux.cedrica5l/alpinux-wiki.git
+git clone git@gitea.alpinux.org:VOTRE-COMPTE/alpinux-wiki.git
 cd alpinux-wiki
+git remote add upstream git@gitea.alpinux.org:alpinux.cedrica5l/alpinux-wiki.git
 ```
 
 Le dépôt contient les pages (`docs/`), les articles longs (`articles/`), les exemples de
 code cités dans le wiki (`code/`) et la configuration du site (`mkdocs.yml`).
 
-### Voir le rendu avant de publier
+### 2. Partir du wiki à jour, sur une branche
+
+Avant chaque nouveau sujet :
+
+```bash
+git switch main
+git pull upstream main              # récupérer ce qui a été publié entre-temps
+git switch -c sauvegarder-ses-photos   # une branche par sujet, au nom parlant
+```
+
+### 3. Voir le rendu avant de proposer
 
 ```bash
 python3 -m venv venv && source venv/bin/activate
@@ -271,27 +307,33 @@ mkdocs serve
 ```
 
 Ouvrez `http://localhost:8000` : la page se recharge à chaque enregistrement. C'est le
-meilleur moyen de vérifier un tableau, une image ou un bloc de code avant de proposer
+meilleur moyen de vérifier un tableau, une image ou un bloc de code. Pour s'assurer que
-quoi que ce soit.
+rien n'est cassé (lien mort, page absente de la navigation) :
-
-### Proposer vos modifications
-
-Comme depuis le navigateur, le travail passe par une branche et une pull request :
 
 ```bash
-git switch -c mon-article           # une branche par sujet
+mkdocs build --strict -d /tmp/wiki-build
-git add .
-git commit -m "Article : sauvegarder ses photos sur un disque externe"
-git push -u origin mon-article
 ```
 
-Gitea affiche alors un lien pour ouvrir la pull request. La suite est identique à
+### 4. Proposer la pull request
-l'[étape 4](#etape-4-ouvrir-la-pull-request).
 
-!!! warning "Pousser sur `main` publie immédiatement"
+```bash
-    Les mainteneurs peuvent pousser directement sur `main`. Dans ce cas il n'y a ni
+git add .
-    relecture, ni filet : le site est reconstruit dans la minute. Pour un brouillon,
+git commit -m "Article : sauvegarder ses photos sur un disque externe"
-    utilisez une branche.
+git push -u origin sauvegarder-ses-photos
+```
+
+Gitea affiche alors un lien pour ouvrir la pull request vers le wiki. La suite est
+identique à l'[étape 4](#etape-4-ouvrir-la-pull-request) : un mainteneur relit, fusionne,
+et la publication se fait toute seule.
+
+!!! warning "Pourquoi ne pas pousser sur `main`"
+    Un commit qui arrive sur `main` est publié dans la minute, sans relecture et sans
+    retour en arrière possible autre qu'un nouveau commit. Même quand on en a le droit,
+    passer par une branche et une pull request donne trois choses : un regard extérieur,
+    une trace de la discussion, et la possibilité de laisser un texte reposer sans qu'il
+    soit en ligne.
+
+    Réservez le push direct aux urgences — une information fausse à retirer tout de suite.
 
 ### Avec Obsidian
 
@@ -299,11 +341,13 @@ Le dépôt est aussi un coffre [Obsidian](https://obsidian.md) : ouvrez le dossi
 comme coffre, les réglages et extensions sont déjà versionnés (mise à jour automatique
 des liens internes, et *Linter* pour la mise en forme).
 
-L'extension **Obsidian Git** y est installée. Si vous activez sa sauvegarde automatique,
+L'extension **Obsidian Git** y est installée. Elle commite et pousse sur la branche
-retenez bien ce qu'elle implique : chaque sauvegarde est un commit poussé sur la branche
+courante — donc :
-courante — donc, sur `main`, une publication en ligne. Rédigez vos brouillons sur une
+
-branche, ou laissez la sauvegarde automatique désactivée et poussez quand le texte est
+- **placez-vous sur votre branche de travail** avant d'écrire (`git switch -c mon-sujet`,
-prêt.
+  ou le sélecteur de branche dans le panneau *Source Control* d'Obsidian) ;
+- si vous activez la sauvegarde automatique, elle poussera vos brouillons au fil de la
+  frappe : c'est confortable sur une branche, et à proscrire sur `main`.
 
 ---