> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.
# The merge line and branch settings
> Reviews in the merge line merge one at a time, in order, each after its checks pass. Plus the three Branch settings that decide how changes reach Your site.
When several reviews go into the same place, the **merge line** merges them one at a time, in order, each after its checks pass. It runs in the background, so nobody has to wait by the screen.
Joining the merge line is the approval to merge. At its turn a review merges with nobody asking again. Nothing goes live: visitors see the change after you publish.
## Add a review
Open a review (see [Reviews and merging](/editor/reviews)). Its drawer says "The merge line merges reviews in order, each at its turn." Click **Add to the merge line**, and confirm:
> Joining the line is the approval to merge: at its turn it merges into Your site with nobody asking again. Before then, the line checks that it still merges cleanly and adds no secret keys to code, and sends it back if not. The live site changes only when it is published.
Hiveku then says where it stands, for example `Added: 3rd in the merge line into Your site, behind "New pricing", "Footer links".`, or that it merges next, and warns when it is likely to clash with a review ahead of it.
Anyone who can merge a review can add it. These cannot join:
* a draft, or a review that is merged or closed;
* a review of Your site's own changes: only a branch's changes can join;
* a review that conflicts with where it goes: resolve the conflicts first;
* a review that is already in a line.
A line holds up to 100 reviews: "The merge line into Your site holds *n* reviews, the most it holds. Try again once some have merged."
## Its place in the line
Each place reviews go into (Your site, or a branch) has its own line. Reviews merge in the order they were added; an **urgent** review goes to the front.
The review drawer shows where it stands:
| The drawer says | What it means |
| - | - |
| **3rd in the merge line into Your site** | Two reviews merge before it. |
| **Merging into Your site now** | Its turn has come. |
| **Waiting for review #12 to merge first.** | It waits for another review (see below). |
| **Waiting for an approval.** | The site requires an approval, and nobody has approved its current changes yet. |
| **Building the merged result.** / **Waiting for a build slot.** | **Build before merging** is on, and its build is running or queued. |
| **Stopped in the merge line into Your site: it needs a person** | It tried and could not finish. See [When it needs a person](#when-it-needs-a-person). |
A review that waits keeps its place and does not hold up the reviews behind it.
AI tools can also set:
* **Urgent** priority, which puts a review at the front. Only an owner or admin, or an AI tool whose key was made by one, can set it: "Only an owner or admin can add a review to the front of the merge line (urgent)."
* **What it waits for** (up to 20 other reviews that must merge first). If one of those leaves the line or is closed, the reviews waiting for it leave too.
The dashboard adds reviews at the back of the line, and shows each review's own place in its drawer. AI tools read the whole line with `project_vcs_queue`.
## What happens at its turn
1. **Its changes are the ones that joined.** A save on the branch after the review joined sends it back: `New changes were saved to "spring-sale" after the review joined the merge line, so it was not merged. Add it again to merge the current changes.`
2. **It merges cleanly**: "Merges into Your site without a conflict." Otherwise it is sent back with the files that conflict.
3. **It adds no secret keys** (the secret scan, below).
4. **It is approved**, when the site's **Require an approval** setting is on and it goes into Your site. It waits for the approval and keeps its place.
5. **It builds**, when **Build before merging** is on (see [Build before merging](#build-before-merging)).
6. **It merges**, exactly as **Merge** in the drawer does: all or nothing, with Your site's latest changes saved as a version first.
The drawer shows each check as **Passed**, **Failed**, **Warning** or **Waiting**, with one sentence that says why.
### The secret scan
The secret scan reads only the lines the merge would add.
* **It sends the review back** for a private key, an AWS access key, a live Stripe secret key, a GitHub token, a Slack bot or user token, or a link with a password or token in it.
* **It warns, and the review still merges,** for a sign-in token (JWT), a Bearer token, a Stripe test key, a webhook signing secret, another kind of Slack token, or a value of 12 or more characters next to a name like "password". Files that are not text, over 1 MB, or past the scan's budget are listed as not scanned.
What it finds reads like this: "*path* line 12 looks like a live Stripe secret key. A secret in a file is readable by anyone who can read the site's code. Remove it, keep it in the site's secrets (Project Settings > Environment Variables) and read it from there, then add the review to the merge line again." See [Environment variables](/how-tos/env-vars).
## Why a review leaves the line
When a review leaves the line, the person who added it is told why in their Hiveku notifications, and AI tools see the reason in `project_vcs_queue` among its recent outcomes. The review's drawer then offers **Add to the merge line** again. Unless it was closed or merged elsewhere, the review stays open, unmerged.
| Why | What the notice says |
| - | - |
| It conflicts | "These files changed on Your site too: …. Resolve them on "*branch*", then add the review to the merge line again." |
| The branch changed after it joined | "New changes were saved to "*branch*" after the review joined the merge line, so it was not merged. Add it again to merge the current changes." |
| A check failed | The check's own sentence, for example the secret scan's or the build's |
| It was closed | "The review was closed, so it left the merge line." |
| It was made a draft | "The review was made a draft. Mark it ready for review, then add it to the merge line again." |
| It was moved to another branch | "The review no longer goes into Your site, so it left that merge line. Add it again to merge it where it goes now." |
| What it waited for left | "Review #*n* it was waiting for left the merge line or was closed, so this one left too. Add it again when it is ready." |
| Someone took it out | "*Name* took it out of the merge line." |
| Its branch is gone | "Its branch "*branch*" no longer exists, so it cannot be merged." |
| It was merged elsewhere | "It was merged outside the merge line." |
### When it needs a person
A review stops in the line, "Stopped in the merge line into Your site: it needs a person", when it could not be merged after 8 tries, when a merge stopped part way, or when 4 builds did not give a lasting pass. Take it out and add it again once the cause is fixed.
## Take a review out
**Take out** asks "Take this review out of the merge line into Your site?": "It stays open, unmerged. You can add it again later; it then goes to the back of the line." A review that is merging right now cannot be taken out: "Review #*n* is merging right now, so it cannot be changed or taken out of the merge line. Look again in a minute."
## Who hears about it
The person who added the review hears when it merges, leaves the line or needs a person, for example ""New pricing" merged into Your site from the merge line" with "The changes are on Your site now. Publish to put them live." When an AI tool added it, that is the person whose key it used.
The line acts on each change at once (a review added or taken out, an approval, a finished build, a settings change) and checks itself every five minutes in case anything was missed.
## Branch settings
**Branch settings**, the gear in the **Branches** tab header, holds three rules for the site:
| Setting | What it does |
| - | - |
| **Require an approval** | "When this is on, changes go into Your site only after someone other than the person who made them approves the latest version, and while nobody is asking for changes." See [Require an approval](/editor/reviews#require-an-approval). |
| **Require reviews for outside AI tools** | "AI tools connected from outside Hiveku, such as Claude, Codex or VS Code, send their changes for review instead of changing Your site directly. Hiveku AI and people editing here are not affected." |
| **Build before merging** | "The merge line builds each review merged with Your site before it goes in, and sends the review back if the build fails. Each review takes a few minutes longer to merge." |
All three are off until an owner or admin turns them on, in the dashboard. Everyone else sees whether they are on: "Only an owner or admin can change this." AI tools can read the settings (`project_vcs_settings`) but never change them, and every change is written to the account's audit log.
### Require reviews for outside AI tools
This setting makes AI tools that connect with a person's own Hiveku key work through reviews. That covers the Claude Code plugin, Codex, the VS Code extension, Hiveku Sync, and AI apps connected to Hiveku (such as claude.ai and ChatGPT). People working in the dashboard, Hiveku AI and Hiveku's department assistants, and workflows are not affected.
With it on, such a tool cannot change Your site's files. These are refused, and nothing is changed:
* saving, deleting or moving files, and folder changes
* restores and rollbacks, and versions that carry files
* merging a branch into Your site
* GitHub pulls, imports and generated code
* SEO tools that write page files
* the shared image and media library, which every branch uses and no review can carry: a person on the team changes it in the dashboard
CMS entries and marketing publishes are not site files, so they are not affected, and nothing on a branch is. A tool may still save what is already on Your site as a version, and run dry runs.
The tool is told what to do instead: create a branch, save the changes on it, open a review into Your site, and add the review to the merge line. It merges into Your site at its turn, once its checks pass. A tool that tries to merge a review into Your site directly is pointed to the merge line.
#### The approval link
Most AI tools ask you before they add a review to the merge line. When the app making the call does not (an AI app connected to Hiveku, or an older plugin), Hiveku asks you itself: the tool gets a one-time link to give you, and nothing is added yet.
The link opens "An AI tool asked to add a review to the merge line", with **From branch**, **Merges into**, **Place in line**, **Asked by** and **Asked at**, and **Approve** or **Decline**. Anyone who can merge reviews on the site can decide.
* The request waits for 10 minutes.
* An approval works once, within 10 minutes, for that same review, place in line, key and changes. If the review's changes change in the meantime, the tool must ask again.
* A site takes up to 20 such requests an hour.
The apps that ask you first, and so never need the link: the Claude Code plugin from 0.27.30, the VS Code extension from 0.91.8, the Codex plugin from 0.3.14 and Hiveku Sync from 0.5.5.
### Build before merging
With this on, the merge line builds each review merged with where it goes, on a hidden copy, using the site's test build (a build that is never deployed). A review whose build fails leaves the line, and the notice names the build's error, with the file and line when the build gave them: fix it on the branch, then add it again. A passing build reads "This review merged with Your site builds."
* **Only in the merge line.** **Merge** in the drawer does not build.
* **Up to 150 MB.** A larger site cannot turn it on ("Your site is about *n* MB, more than the 150 MB a build before merging can take, so "Build before merging" cannot be turned on for it. Nothing was changed."), and a review whose merged result grows past 150 MB leaves the line.
* **One build per site at a time, within the test build allowance** (6 test builds per site in 15 minutes). A review waits for a slot, and never fails for lack of one: "Waiting for a build slot: this site started its 6 test builds of the last 15 minutes. This one builds when one frees up."
* **Builds again when it must.** If files the review touches change where it goes while it waits, it builds again. After 4 builds without a lasting pass, it stops and needs a person.
* **Turned off while a review waits**: "Build before merging" was turned off, so this review merges without waiting for its build.
## Limits
| | Limit |
| - | - |
| Reviews in one line | 100 |
| Reviews one review can wait for | 20 |
| Tries before it needs a person | 8 |
| Builds before it needs a person | 4 |
| Site size for **Build before merging** | 150 MB |
| Test builds per site | 6 in 15 minutes |
| Approval link | Works once, within 10 minutes; 20 requests per site an hour |
## From AI tools
* `project_vcs_queue` reads the line: the order, each review's place, what it waits for and recent outcomes. Read it before you start work on a site that several people or agents share.
* `project_vcs_queue_add` adds a review (`priority`, `depends_on`, and `approval_token` after an approval link). Its answer gives the review's place, who is ahead, and what it may clash with.
* `project_vcs_queue_remove` takes a review out, and `project_vcs_queue_update` changes its priority or what it waits for.
See [Branches and AI tools](/editor/branches-and-ai).
## Common questions
No. It merges into Your site. Visitors see the change after you publish.
No. Unless it was closed or merged elsewhere, it stays open, unmerged. The person who added it gets a notification saying why it left; fix that, then add it again from the review's drawer. It goes to the back of the line.
The checks run only in the merge line. To have a review built before it merges, turn on **Build before merging** and add the review to the merge line.
The site requires reviews for outside AI tools, and the app the tool runs in does not ask you itself. Open the link, check the review it names, and click **Approve** or **Decline**. Nothing is added until you approve.
No. Only an owner or admin changes Branch settings, in the dashboard.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.