mirror of
https://github.com/mintlify/docs.git
synced 2026-09-14 13:35:46 +08:00
017d7c7377
* fix: reduce Vale false positives via vocab and config updates - Make English-word vocab entries case-insensitive so sentence-start capitalization and normal prose usage stop flagging (agents, rest, cursor, setup, endpoints, etc.) - Add vocab entries for filenames and code identifiers that appear in frontmatter and JSX contexts (docs.json, llms.txt, CLAUDE.md, etc.) - Ignore openapi frontmatter lines, filenames, JSX attributes, email addresses, and internal link targets via TokenIgnores - Skip inline code scope and indented code fences - Add Headings exceptions for proper nouns (Claude Code, GitHub Actions, Route 53, GA4, etc.) - Disable linting for the all-code vercel-json-generator snippet Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: resolve all Vale warnings and errors across docs Content fixes: - Reword sentences using 'will', first person, spaced em dashes, 'e.g.', Latin abbreviations, and hyphenated adverbs - Sentence-case headings that started with dotted filenames - Backtick literal API values instead of bolding them - Move periods inside quotation marks - Fix Oxford comma rule misfires by restructuring sentences False-positive suppression: - Vale toggles around example user questions, keyboard shortcut keys (Cmd+I), UI labels, and code samples in JSX contexts that Vale misparses - Exclude vale toggle comments from the brace Token/BlockIgnores so in-document commands actually reach Vale (the greedy brace pattern was also silently swallowing large regions; now lazy) - Vocab entries for code identifiers (internal_id, handleSubmit, etc.) - Per-file rule disables for component docs with dotted JSX names and files where link-target linting ignores in-document toggles Result: vale --minAlertLevel warning is clean repo-wide; only suggestion-level items (Passive, Semicolons, Acronyms) remain. mint broken-links passes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: correct WordList rule instead of degrading prose - Restore sentence-start "Email" in advanced-support; the rule now only flags hyphenated e-mail/E-mail forms - Restore the idiom "above all else"; the above->preceding swap now exempts "above all" Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: restore deliberate prose flagged by blunt rules - Restore spatial 'above the navbar' / 'above a page title' in custom-scripts; the above->preceding swap now exempts 'above the/a/an' - Restore the '= ...' in the react-components named-export example (the ellipsis is inside inline code) with an Ellipses toggle - Restore SLA phrasing 'will use commercially reasonable efforts' with a Will toggle - Restore the quoted developer question in the GEO guide intro with a FirstPerson toggle, matching the file's other example questions Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: remove WordList swaps that flag legitimate English - Drop tablet->device and firewalls->firewall rules; both words are correct in ordinary prose - Narrow touch->tap to UI-instruction phrasing (touch the/a) so 'keep in touch' and 'touch devices' stop flagging Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: reposition vale toggles to wrap whole blocks Toggle comments placed between list items split the lists (restarting ol numbering in deployments) and comments flush against tables risked breaking GFM table parsing. Wrap entire lists/tables with blank-line separation instead. Verified rendering with mint dev: single ol with two items, tables intact, no comments in visible DOM. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor: prune accept.txt to load-bearing entries Empirically removed 166 vocab entries (575 -> 409) whose removal causes no Vale flags across all 908 English pages: dictionary words that never needed listing (agents, setup, endpoints, webhooks, yaml), lowercase entries the speller already accepts, and filename entries made redundant by inline vale toggles. Kept every case-enforcing entry (API, JSON, GitHub, ...) so casing policy is unchanged, plus entries that double as capitalization exceptions for headings (mcp, md, auth, cursor, txt). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Update ai/mintlify-mcp.mdx * Update api/agent/v2/create-agent-job.mdx * chore: alphabetize Headings exceptions and accept.txt Case-insensitive sort, ignoring the (?i) prefix; also drops a duplicate Scala entry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: re-apply OxfordComma rewrite lost in branch merge Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: resolve Vale suggestions batch 1 (acronyms, semicolons, passive voice) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: resolve remaining Vale suggestions (passive voice batch 2) Rewrite ~90 passive constructions to active voice across deploy, guides, migration-services, and organize docs. Toggle the deliberate passive examples in the style-and-tone guide ('by zombies' test). Add axios/lodash vocab entries for a repositioned code example. vale . is now fully clean: 0 errors, 0 warnings, 0 suggestions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
127 lines
3.9 KiB
Plaintext
127 lines
3.9 KiB
Plaintext
---
|
|
title: "Work with branches"
|
|
description: "Create and manage documentation branches to preview changes, collaborate with teammates, and merge updates before publishing to production."
|
|
keywords: ["Git","branches","branch workflow","creating branches","deployment branch"]
|
|
---
|
|
|
|
Branches are a feature of version control that point to specific commits in your repository. Your deployment branch, usually called `main`, represents the content used to build your live documentation site. All other branches are independent of your live docs unless you choose to merge them into your deployment branch.
|
|
|
|
Branches let you create separate instances of your documentation to make changes, get reviews, and try new approaches before publishing. Your team can work on branches to update different parts of your documentation simultaneously without affecting what users see on your live site.
|
|
|
|
The following diagram shows an example of a branch workflow where you create a feature branch, make changes, and then merge the feature branch into the main branch.
|
|
|
|
```mermaid
|
|
gitGraph
|
|
commit id: "Initial commit"
|
|
commit id: "Branch created"
|
|
branch feature-branch
|
|
checkout feature-branch
|
|
commit id: "Add Changes"
|
|
commit id: "Add more changes"
|
|
checkout main
|
|
checkout feature-branch
|
|
commit id: "Add reviewer feedback"
|
|
checkout main
|
|
merge feature-branch id: "Merge into main" type: HIGHLIGHT
|
|
commit id: "Live docs"
|
|
```
|
|
|
|
Always work from branches when updating documentation to keep your live site stable and enable review workflows.
|
|
|
|
## Branch naming conventions
|
|
|
|
Use clear, descriptive names that explain the purpose of a branch.
|
|
|
|
**Use**:
|
|
|
|
- `fix-broken-links`
|
|
- `add-webhooks-guide`
|
|
- `reorganize-getting-started`
|
|
- `ticket-123-oauth-guide`
|
|
|
|
**Avoid**:
|
|
|
|
- `temp`
|
|
- `my-branch`
|
|
- `updates`
|
|
- `branch1`
|
|
|
|
## Create a branch
|
|
|
|
<Tabs>
|
|
<Tab title="Using web editor">
|
|
1. Click the branch name in the editor toolbar.
|
|
1. Click **Create new branch**.
|
|
1. Enter a descriptive name.
|
|
1. If you have unsaved changes, choose whether to bring them to the new branch or leave them on your current branch.
|
|
1. Click **Create branch**.
|
|
</Tab>
|
|
<Tab title="Using local development">
|
|
<Steps>
|
|
<Step title="Create a branch from your terminal">
|
|
```bash
|
|
git checkout -b branch-name
|
|
```
|
|
|
|
This creates the branch and switches to it in one command.
|
|
</Step>
|
|
<Step title="Push the branch to GitHub">
|
|
```bash
|
|
git push -u origin branch-name
|
|
```
|
|
|
|
The `-u` flag sets up tracking so future pushes just need `git push`.
|
|
</Step>
|
|
</Steps>
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
## Save changes on a branch
|
|
|
|
<Tabs>
|
|
<Tab title="Using web editor">
|
|
Click the **Save as commit** button in the top-right of the editor toolbar. This creates a commit and pushes your work to your branch automatically.
|
|
</Tab>
|
|
<Tab title="Using local development">
|
|
Stage, commit, and push your changes.
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "Describe your changes"
|
|
git push
|
|
```
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
## Switch branches
|
|
|
|
<Tabs>
|
|
<Tab title="Using web editor">
|
|
1. Click the branch name in the editor toolbar to open the branch dropdown.
|
|
1. Search for a branch by name or scroll through the list.
|
|
1. Click the branch you want to switch to.
|
|
|
|
Each branch in the dropdown displays a status indicator so you can see whether it is ready, syncing, or failed.
|
|
|
|
<Warning>
|
|
Unsaved changes are lost when switching branches. Save your work first.
|
|
</Warning>
|
|
</Tab>
|
|
<Tab title="Using local development">
|
|
Switch to an existing branch:
|
|
|
|
```bash
|
|
git checkout branch-name
|
|
```
|
|
|
|
Or create and switch in one command:
|
|
|
|
```bash
|
|
git checkout -b new-branch-name
|
|
```
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
## Merge branches
|
|
|
|
Once your changes are ready to publish, create a pull request to merge your branch into the deployment branch. |