Comprenda cómo las branches y las reglas de protección determinan lo que sucede al publicar, y cómo gestionar el flujo completo de revisión y despliegue.
El editor web guarda todo automáticamente mientras escribe, pero sus cambios solo están en producción cuando decide publicarlos.Lo que sucede al publicar depende de dos cosas: en qué branch se encuentre y si esa branch requiere pull requests.
Guardar ocurre automáticamente. Mintlify almacena sus ediciones en sus servidores y las conserva entre pestañas del navegador, dispositivos e interrupciones de red.Publicar confirma sus cambios en su repositorio de Git. Haga clic en Publish en la barra de herramientas para abrir el menú de publicación, guardar sus cambios como un commit de Git y crear una pull request.El editor registra lo siguiente como cambios pendientes:
Las acciones disponibles al hacer clic en el botón de publicar dependen de la branch actual y de si tiene reglas de protección de branch que exigen pull requests.
Tipo de branch
Protección de branch
Acciones disponibles
Ninguna
Publish directamente en su sitio en producción
Deployment branch
Se requieren pull requests
Create branch para mover los cambios a una nueva branch
Ninguna
Save in branch, Create pull request
Feature branch
Se requieren pull requests
Save in branch, Create pull request
Publish: Confirma y despliega sus cambios en su sitio en producción de inmediato.
Save in branch: Confirma sus cambios en la feature branch sin fusionarlos con su deployment branch.
Create branch: Mueve sus cambios pendientes a una nueva feature branch cuando se encuentra en una deployment branch protegida.
Create pull request: Abre una pull request dirigida a su deployment branch.
Si no hay cambios pendientes, el editor desactiva las acciones de publicar y guardar.
Su sitio en producción se actualiza después de que Mintlify compile y despliegue sus cambios. Esto suele tardar de 30 segundos a unos pocos minutos. Compruebe el estado del despliegue en su panel.
Edite directamente en su deployment branch si no utiliza un flujo de trabajo basado en Git.Cree una branch cuando utilice un flujo de trabajo basado en branches en el que realiza cada cambio en su contenido en una branch separada.
Haga clic en el nombre de la branch en la barra de herramientas.
Busque o desplácese hasta la branch que desee.
Haga clic en la branch para cambiar a ella.
Si cambia de branch cuando tiene cambios sin publicar, se le pedirá que lleve esos cambios a la nueva branch o que los deje atrás. Los cambios dejados atrás permanecen en su branch original.
Para copiar el nombre de una branch, pase el cursor sobre la branch en el menú desplegable y haga clic en el icono de copiar. Esto resulta útil al compartir la branch con sus compañeros de equipo o al referenciarla en una pull request.
Cada vez que guarda cambios en una feature branch, Mintlify compila un despliegue de vista previa, una URL temporal donde sus cambios se renderizan exactamente como cuando se publican.
Las URLs de vista previa son públicamente accesibles por defecto. Para restringir el acceso a los miembros de su organización en Mintlify, habilite la autenticación de vista previa en la página Add-ons de su panel.
Para invitar a un compañero de equipo a una página específica en una branch, copie la URL de la barra de direcciones de su navegador y compártala. Cualquier persona con acceso a su organización de Mintlify puede abrir el enlace directamente en su sesión del editor.El formato de la URL es:
Cuando hay una pull request abierta para la branch actual, el menú de publicación muestra un panel de revisión con:
El título y la descripción de la pull request, y si es un borrador.
Las branches de origen y de destino.
El número de archivos modificados.
El requisito de aprobación en la deployment branch: Approval required, Code owner required o sin requisito.
El estado actual de la revisión: Approved, Changes requested o Awaiting review.
Haga clic en Open in GitHub o Open in GitLab para ver la pull request en su proveedor de Git.Después de que un revisor apruebe una pull request, haga clic en Merge and publish para fusionar y desplegar directamente desde el editor. El editor cambia a su deployment branch después de fusionar.
Para los repositorios de GitHub, los revisores pueden aprobar pull requests abiertas en el editor. Cuando hay una pull request abierta, aparece el botón Approve pull request en el panel de revisión si su cuenta tiene permiso para revisarla. Haga clic en Approve pull request cuando los cambios estén listos para fusionarse. El estado de la revisión cambia a Approved y la acción Merge and publish queda disponible.La acción de aprobar no está disponible para pull requests en borrador, pull requests que ya ha aprobado o merge requests de GitLab. Haga clic en Open in GitLab para aprobar una merge request en GitLab.
Configure reglas de protección de branches en su proveedor de Git para exigir pull requests. Consulte About protected branches en la ayuda de GitHub o Protected branches en la ayuda de GitLab.
Haga clic en cualquier archivo modificado en el menú de publicación para abrirlo en la vista de diff y comparar su branch con la versión publicada. En modo visual verá un diff visual; en modo source verá un diff de texto. Los archivos que no pueden mostrar un diff, como imágenes o archivos eliminados, aparecen en la lista pero no se pueden abrir.
Solo puede haber una publicación a la vez por branch. Si otro miembro del equipo publica en la misma branch, espere a que termine la publicación actual antes de volver a intentarlo.
Al publicar, puede introducir un mensaje de commit antes de confirmar. Si lo deja en blanco, el editor usa un mensaje predeterminado que enumera los archivos que ha creado, actualizado, movido o eliminado.
Los conflictos ocurren cuando su branch y la deployment branch tienen cambios incompatibles en los mismos archivos. Por ejemplo, cuando usted y un compañero de equipo han editado las mismas líneas en un archivo o han movido un archivo a ubicaciones diferentes.El editor muestra una advertencia cuando los conflictos bloquean la publicación. Siga las indicaciones para elegir qué versión de cada sección en conflicto conservar.
Cuando varias personas abren la misma página en la misma branch, editan juntas en tiempo real. El cursor y las ediciones de cada persona son visibles para todos, con avatares mostrados en la barra de herramientas.
Los cambios de todos los colaboradores se fusionan automáticamente. Dos personas editando la misma sección no generarán conflictos.
Deshacer solo afecta a sus propias ediciones.
Si pierde la conexión, las ediciones se guardan localmente y se sincronizan cuando se vuelve a conectar.
Cuando el agente de Mintlify edita una página a través de la API o MCP, aparece en el editor como cualquier otro colaborador. Verá el avatar del agente en la barra de herramientas y un cursor en vivo en su edición más reciente. El cursor desaparece automáticamente después de que el agente termina.
Cuando alguien envía cambios a su repositorio desde fuera del editor, el editor incorpora esos cambios automáticamente.Los cambios que no se solapan se aplican automáticamente. Si un cambio remoto y su edición local afectan a la misma parte de una página, el editor resalta el conflicto para que pueda resolverlo.
Firme commits con su cuenta de GitHub autorizándola en la configuración de su cuenta. Sin autorización, la app de GitHub de Mintlify firma los commits realizados en el editor web.Para una referencia de cómo las acciones del editor se corresponden con las operaciones de Git, consulte Conceptos básicos de Git.
