Comprenez comment les branches et les règles de protection déterminent ce qui se passe lorsque vous publiez, et comment gérer l’ensemble du workflow de relecture et de déploiement.
L’éditeur web enregistre automatiquement tout ce que vous tapez, mais vos modifications ne sont mises en ligne que lorsque vous choisissez de les publier.Ce qui se passe lors de la publication dépend de deux choses : la branche sur laquelle vous vous trouvez et si cette branche exige des pull requests.
L’enregistrement est automatique. Mintlify stocke vos modifications sur ses serveurs et les conserve à travers les onglets du navigateur, les appareils et les coupures réseau.La publication valide vos modifications dans votre référentiel Git. Cliquez sur Publish dans la barre d’outils pour ouvrir le menu de publication, enregistrer vos modifications en tant que commit Git et créer une pull request.L’éditeur suit les éléments suivants comme modifications en attente :
Les actions disponibles lorsque vous cliquez sur le bouton de publication dépendent de votre branche actuelle et de la présence de règles de protection de branche imposant des pull requests.
Type de branche
Protection de branche
Actions disponibles
Aucune
Publish directement sur votre site en production
Branche de déploiement
Pull requests requises
Create branch pour déplacer les modifications vers une nouvelle branche
Aucune
Save in branch, Create pull request
Branche de fonctionnalité
Pull requests requises
Save in branch, Create pull request
Publish : Valide et déploie immédiatement vos modifications sur votre site en production.
Save in branch : Valide vos modifications sur la branche de fonctionnalité sans les fusionner dans votre branche de déploiement.
Create branch : Déplace vos modifications en attente vers une nouvelle branche de fonctionnalité lorsque vous êtes sur une branche de déploiement protégée.
Create pull request : Ouvre une pull request ciblant votre branche de déploiement.
S’il n’y a aucune modification en attente, l’éditeur désactive les actions de publication et d’enregistrement.
Votre site en production se met à jour après que Mintlify a généré et déployé vos modifications. Cela prend généralement de 30 secondes à quelques minutes. Vérifiez le statut du déploiement sur votre tableau de bord.
Modifiez directement sur votre branche de déploiement si vous n’utilisez pas de workflow basé sur Git.Créez une branche lorsque vous utilisez un workflow basé sur des branches dans lequel chaque modification de votre contenu se fait sur une branche distincte.
Cliquez sur le nom de la branche dans la barre d’outils.
Recherchez ou faites défiler jusqu’à la branche souhaitée.
Cliquez sur la branche pour y basculer.
Changer de branche alors que vous avez des modifications non publiées vous invite à transférer ces modifications vers la nouvelle branche ou à les laisser sur place. Les modifications laissées de côté restent sur votre branche d’origine.
Pour copier le nom d’une branche, survolez la branche dans la liste déroulante et cliquez sur l’icône de copie. Pratique pour partager la branche avec des coéquipiers ou la référencer dans une pull request.
Chaque fois que vous enregistrez des modifications sur une branche de fonctionnalité, Mintlify génère un déploiement de prévisualisation, une URL temporaire où vos modifications s’affichent exactement comme une fois publiées.
Les URL d’aperçu sont publiquement accessibles par défaut. Pour restreindre l’accès aux membres de votre organisation Mintlify, activez l’authentification d’aperçu sur la page Add-ons de votre tableau de bord.
Pour inviter un coéquipier sur une page spécifique d’une branche, copiez l’URL depuis la barre d’adresse de votre navigateur et partagez-la. Toute personne ayant accès à votre organisation Mintlify peut ouvrir le lien directement dans sa session de l’éditeur.Le format de l’URL est :
Lorsqu’une pull request est ouverte pour la branche actuelle, le menu de publication affiche un panneau de relecture avec :
Le titre de la pull request, sa description et si elle est en brouillon.
Les branches source et cible.
Le nombre de fichiers modifiés.
L’exigence d’approbation sur la branche de déploiement : Approval required, Code owner required, ou aucune exigence.
Le statut de relecture actuel : Approved, Changes requested ou Awaiting review.
Cliquez sur Open in GitHub ou Open in GitLab pour consulter la pull request dans votre fournisseur Git.Une fois qu’un relecteur a approuvé la pull request, cliquez sur Merge and publish pour la fusionner et la déployer directement depuis l’éditeur. L’éditeur bascule vers votre branche de déploiement après la fusion.
Pour les référentiels GitHub, les relecteurs peuvent approuver les pull requests ouvertes dans l’éditeur. Lorsqu’une pull request est ouverte, un bouton Approve pull request apparaît dans le panneau de relecture si votre compte a la permission de la relire. Cliquez sur Approve pull request lorsque les modifications sont prêtes à être fusionnées. Le statut de relecture passe à Approved et l’action Merge and publish devient disponible.L’action d’approbation n’est pas disponible pour les pull requests en brouillon, les pull requests que vous avez déjà approuvées, ou les merge requests GitLab. Cliquez sur Open in GitLab pour approuver une merge request dans GitLab.
Configurez les règles de protection de branche dans votre fournisseur Git pour exiger des pull requests. Voir About protected branches dans l’aide GitHub ou Protected branches dans l’aide GitLab.
Cliquez sur n’importe quel fichier modifié dans le menu de publication pour l’ouvrir en vue de comparaison et comparer votre branche à la version publiée. En mode visuel, vous voyez un diff visuel ; en mode source, vous voyez un diff textuel. Les fichiers qui ne peuvent pas afficher de diff, comme les images ou les fichiers supprimés, apparaissent dans la liste mais ne sont pas cliquables.
Une seule publication peut avoir lieu à la fois par branche. Si un autre membre de l’équipe publie sur la même branche, attendez que la publication en cours soit terminée avant de réessayer.
Lorsque vous publiez, vous pouvez saisir un message de commit avant de confirmer. Si vous le laissez vide, l’éditeur utilise un message par défaut listant les fichiers que vous avez créés, mis à jour, déplacés ou supprimés.
Des conflits surviennent lorsque votre branche et la branche de déploiement comportent des modifications incompatibles dans les mêmes fichiers. Par exemple, lorsque vous et un coéquipier avez modifié les mêmes lignes d’un fichier ou déplacé un fichier vers des emplacements différents.L’éditeur affiche un avertissement lorsque des conflits bloquent la publication. Suivez les invites pour choisir quelle version de chaque section en conflit conserver.
Lorsque plusieurs personnes ouvrent la même page sur la même branche, elles éditent ensemble en temps réel. Le curseur et les modifications de chaque personne sont visibles par tous, avec les avatars affichés dans la barre d’outils.
Les modifications de tous les collaborateurs fusionnent automatiquement. Deux personnes éditant la même section ne créeront pas de conflits.
L’annulation n’affecte que vos propres modifications.
Si vous perdez votre connexion, les modifications sont enregistrées localement et se synchronisent à la reconnexion.
Lorsque l’agent Mintlify modifie une page via l’API ou MCP, il apparaît dans l’éditeur comme n’importe quel autre collaborateur. Vous voyez l’avatar de l’agent dans la barre d’outils et un curseur en direct à son dernier emplacement d’édition. Le curseur disparaît automatiquement une fois que l’agent a terminé.
Lorsque quelqu’un pousse des modifications vers votre référentiel depuis l’extérieur de l’éditeur, l’éditeur intègre ces modifications automatiquement.Les modifications qui ne se chevauchent pas s’appliquent automatiquement. Si une modification distante et votre modification locale affectent la même partie d’une page, l’éditeur met en évidence le conflit pour que vous puissiez le résoudre.
Signez les commits avec votre compte GitHub en l’autorisant dans vos paramètres de compte. Sans autorisation, l’application GitHub Mintlify signe les commits effectués dans l’éditeur web.Pour une référence sur la correspondance entre les actions de l’éditeur et les opérations Git, consultez Notions essentielles de Git.
