Skip to main content

Publishing workflows

The editor supports multiple workflows for publishing documentation updates. The workflow you use depends on your repository’s branch protection rules and the branch you work on.
Branch typeBranch protectionAvailable actions
NonePublish directly
Deployment branchPull requests requiredCreate a branch to make changes
NoneSave in branch, create a pull request
Feature branchPull requests requiredSave in branch, create a pull request
Configure branch protection rules in your Git provider to require pull requests. See About protected branches in the GitHub docs or Protected branches in the GitLab docs.

Save changes

As you edit, the editor tracks your changes.
  • New or deleted files.
  • Content edits in pages.
  • Navigation structure changes.
  • Media uploads and organization.
  • Configuration updates.
When you work on your deployment branch, changes automatically save.
Web editor toolbar showing one pending change.
When you work on a feature branch, save changes to the branch.
Web editor toolbar showing one pending change and the Save in branch button on a feature branch.
To discard changes, click Undo changes beside a filename in the files changed dropdown.

Publish your changes

Click the publish button in the toolbar to open the publish popover. The actions available depend on your branch and branch protection rules.
  • Publish: On the deployment branch without branch protections, click Publish to commit and deploy your changes immediately.
  • Save in branch: On a feature branch, click Save in branch to commit your changes to the current branch.
  • Create branch: On a protected deployment branch, click Create branch to move your changes to a new branch.
  • Create pull request: On a feature branch, click Create pull request to open a pull request targeting your deployment branch.
When you create a pull request from the editor, you can set a title and description before creating it.
If there are no pending changes, the publish and save actions are disabled.
Your live documentation site updates after Mintlify builds and deploys your published changes. This typically takes 30 seconds to a few minutes. Check the deployment status of your changes on your dashboard.

Review and merge pull requests

When a pull request is open for the current branch, the publish popover shows its review status:
  • Approved: The pull request has been approved and is ready to merge.
  • Changes requested: A reviewer requested changes before the pull request can merge.
  • Awaiting review: The pull request is waiting for a review.
Click View request to open the pull request in your Git provider. If the pull request is approved, click Merge and publish to merge the pull request and deploy changes to your live documentation directly from the editor. After merging, the editor switches to your deployment branch.
If your repository requires approvals before merging, Merge and publish is only available after the pull request is approved.

Resolve conflicts

Conflicts occur when your branch and the deployment branch have incompatible changes to the same files.

What causes conflicts

Conflicts happen when you try to merge branches with incompatible changes to the same files.
  • You and another team member edit the same lines in a file on different branches.
  • You move, rename, or delete files on one branch and modify them differently on another branch.

Resolve conflicts

The editor displays warnings when conflicts prevent operations like publishing or switching branches. To resolve conflicts, follow the instructions in the editor to choose which changes to keep.

Commit signing

Sign commits with your GitHub account by authorizing it in your account settings. Without authorization, the Mintlify GitHub App signs commits made in the web editor. Attributing commits to your account maintains an accurate history of who made changes to your documentation.