mintlify__docs/fr/editor/publish.mdx

---
title: "Publier les modifications dans l’éditeur web"
sidebarTitle: "Publier"
description: "Enregistrez votre travail et publiez les modifications sur votre site de documentation."
keywords: ["éditeur", "publier", "modifications", "branches", "pull requests"]
---

<div id="publishing-workflows">
  ## Workflows de publication
</div>

L'éditeur prend en charge deux workflows pour publier des mises à jour de la documentation. Le workflow que vous utilisez dépend des règles de protection des branches de votre référentiel et de la branche sur laquelle vous travaillez.

* **Créer des pull requests** : Si votre référentiel comporte une règle de protection de branche qui impose des pull requests avant que les modifications puissent être fusionnées dans votre branche de déploiement, l'éditeur crée une pull request (demande de fusion) lorsque vous publiez des modifications.
* **Publier directement** : Si votre référentiel n'a aucune règle de protection de branche, vos modifications sont fusionnées dans la branche de déploiement et déployées immédiatement lorsque vous publiez.

| Type de branche | Protection de la branche | Workflow de publication |
|-------------|-------------------|------------------------------|
| <Tooltip headline="Branche de déploiement" tip="La branche qui publie sur votre site de documentation en production, généralement 'main'.">Branche de déploiement</Tooltip> | Aucune | Effectue des commits et déploie les modifications |
| Branche de déploiement | Pull requests requises | Crée une pull request (demande de fusion) |
| <Tooltip headline="Branche de fonctionnalité" tip="Une branche isolée sur laquelle vous travaillez sur des mises à jour avant de fusionner vers votre branche de déploiement.">Branche de fonctionnalité</Tooltip> | Aucune | Fusionne les modifications dans la branche de déploiement et les déploie |
| Branche de fonctionnalité | Pull requests requises | Crée une pull request (demande de fusion) |

<Tip>
  Configurez des règles de protection des branches dans votre fournisseur Git pour exiger des pull requests. Voir [À propos des branches protégées](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) dans la documentation GitHub ou [Branches protégées](https://docs.gitlab.com/user/project/repository/branches/protected/) dans la documentation GitLab.
</Tip>

<div id="save-changes">
  ## Enregistrer les modifications
</div>

Pendant que vous modifiez le contenu, l’éditeur suit vos changements.

- Nouveaux fichiers ou fichiers supprimés.
- Modifications de contenu dans les pages.
- Changements dans la structure de navigation.
- Téléversement et organisation des médias.
- Mises à jour de la configuration.

Lorsque vous travaillez sur votre branche de déploiement, les modifications sont enregistrées automatiquement.

<Frame caption="Modifications sur une branche de déploiement.">
  <img src="/images/editor/toolbar-light.png" alt="Barre d’outils de l’éditeur web affichant une modification en attente." className="block dark:hidden" />
  <img src="/images/editor/toolbar-dark.png" alt="Barre d’outils de l’éditeur web affichant une modification en attente." className="hidden dark:block" />
</Frame>

Lorsque vous travaillez sur une branche de fonctionnalité, enregistrez les modifications dans la branche.

<Frame caption="Modifications sur une branche de fonctionnalité.">
<img src="/images/editor/toolbar-branch-light.png" alt="Barre d’outils de l’éditeur web affichant une modification en attente et le bouton Save in branch sur une branche de fonctionnalité." className="block dark:hidden" />
<img src="/images/editor/toolbar-branch-dark.png" alt="Barre d’outils de l’éditeur web affichant une modification en attente et le bouton Save in branch sur une branche de fonctionnalité." className="hidden dark:block" />
</Frame>

Pour annuler des modifications, cliquez sur **Annuler les modifications** à côté d’un nom de fichier dans le menu déroulant des fichiers modifiés.

<div id="publish-your-changes">
  ### Publier vos modifications
</div>

Cliquez sur **Publier** dans la barre d’outils. Selon votre workflow, vos modifications sont déployées immédiatement ou créent une pull request à fusionner dans votre fournisseur Git. Si vous êtes sur une branche de fonctionnalité, enregistrez vos modifications avant de publier.

S’il n’y a aucune modification en attente ou si une pull request est déjà ouverte pour la branche actuelle, le bouton **Publier** n’est pas cliquable.

<Note>
  Votre site de documentation en production est mis à jour après que Mintlify a compilé et déployé vos modifications publiées. Cela prend généralement entre 30 secondes et quelques minutes. Vérifiez l’état du déploiement de vos modifications sur votre [dashboard](https://dashboard.mintlify.com).
</Note>

## Résoudre les conflits

Les conflits se produisent lorsque votre branche et la branche de déploiement comportent des modifications incompatibles dans les mêmes fichiers.

<div id="what-causes-conflicts">
  ### Quelles sont les causes des conflits ?
</div>

Les conflits surviennent lorsque vous essayez de fusionner des branches contenant des modifications incompatibles apportées aux mêmes fichiers.

* Vous et un autre membre de l&#39;équipe modifiez les mêmes lignes dans un fichier sur des branches différentes.
* Vous déplacez, renommez ou supprimez des fichiers dans une branche, mais les modifiez différemment dans une autre.

<div id="resolve-conflicts">
  ### Résoudre les conflits
</div>

L’éditeur affiche des avertissements lorsque des conflits empêchent d’effectuer des opérations comme la publication ou le changement de branche. Pour résoudre les conflits, suivez les instructions dans l’éditeur pour choisir les modifications à conserver.

<div id="commit-signing">
  ## Signature des commits
</div>

Signez vos commits avec votre compte GitHub en l’autorisant dans vos [paramètres de compte](https://dashboard.mintlify.com/settings/account). Sans cette autorisation, la GitHub App de Mintlify signe les commits effectués dans l’éditeur web.

Attribuer les commits à votre compte permet de conserver un historique précis des personnes ayant modifié votre documentation.