> ## 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.
# Reviews and merging
> Ask for a review, comment line by line, approve or ask for changes, resolve conflicts, and merge a branch into Your site
A **review** asks to merge one branch into another, usually into Your site. Your team and AI tools comment on it, a person approves it, and when it is ready it merges. Merging into Your site does not publish: visitors see the change after you put it live.
AI tools call a review a pull request, and Your site `main` (the `project_vcs_pr_*` tools). See [Branches and AI tools](/editor/branches-and-ai).
## Ask for a review
**Ask for a review** is in the branch selector, on a branch's card on the **Branches** tab, and in the **Deploy** menu's Production row while you are on a branch.
* **From** is the branch with the changes. **Into** is where they go; it starts as the branch From was started from, usually Your site.
* **Title** ("What does this change?") and **Description (optional)** ("Anything the reviewer should know").
* Any branch can be From or Into, Your site included. From and Into must differ: "Pick two different branches."
When it is sent: `Asked for a review: "spring-sale" into Your site.`
Each pair of branches has one open review at a time; a second one for the same From and Into is refused, and Hiveku points to the open one. A new review is ready for review at once. To hold it back while you work, set it to a draft (see [Drafts](#drafts)).
## Find reviews
While reviews are waiting, the **Branches** tab header shows **Waiting for review · *n***. It opens "Changes waiting for review", filtered by **Waiting**, **Merged** and **Closed**, with **Show older reviews** at the end. A branch's side panel lists its own reviews, and its card says **In review**.
## The review drawer
Click a review to open it. At the top:
* Its title, From and Into, and who sent it and when, for example "Sent for review 2h ago by Sam".
* "Your site has newer versions than when this branch was started.", when it has.
* "Includes changes on "*branch*" that are not in a version yet.", when the branch has latest changes. The merge takes them too.
* **Merge**, **Close without merging**, **Preview branch** (or **Open preview**) and **Work here**, which switches the editor to the branch.
### Where it stands
The status line says what the review waits for:
| Status | What it means |
| - | - |
| **Ready to merge** | Nothing stands in the way. |
| **Needs an approval** | The site requires an approval (see [Require an approval](#require-an-approval)), and nobody has approved the current changes. |
| **Changes asked for by Sam** | A reviewer asked for changes, and that request still stands. |
| **Approved an earlier version** | "Sam approved before the changes moved on. It needs a new approval." |
| **Draft** | It cannot be approved or merged until someone marks it ready. |
| **Approved by Sam and Alex** | The current changes are approved. |
A chip says whether it merges cleanly:
| Chip | What it means |
| - | - |
| **Ready to merge** | It merges into where it goes without a conflict. |
| **Conflicts with Your site** | "*n* files conflict with Your site: …. Resolve them before it can merge or join the merge line." See [Conflicts](#conflicts). |
| **Overlaps with review #12** | It merges cleanly now, but it would conflict with another open review into the same place: `Would conflict with review #12 "New pricing" in 2 files: …. If review #12 merges first, this one will be sent back.` |
| **Not checked** | It could not be checked right now, for example "It is too large to check here. The merge itself checks it." |
The check against other open reviews compares them two at a time, so it is a warning, not a promise: the merge itself has the final say.
### Files and Conversation
**Files · *n*** lists the changed files as added, changed and removed, each with a side-by-side view. A file over 1 MB says "This file is too large to show here.", and a file that is not text says "This file changed. It cannot be shown as text."
Files compares the branch with where it goes as it is now. When Your site has moved on since the branch started, some of the differences are Your site's newer changes, not the branch's: [bring them into the branch](#bring-your-sites-changes-into-a-branch) first to see only the branch's own.
**Conversation · *n*** holds the reviews so far and every comment thread.
## Comment
Comment on one line: open a file under **Files** and click a line number on the changed side ("Comment on line 12"). Line comments go on files the review adds or changes, while the review is open.
* Comments gather into conversations. **Reply** answers one. **Resolve** marks a conversation done, and **Unresolve** reopens it; anyone who can comment can do either ("Resolved by Sam").
* A comment on a line that has changed since it was written is marked **Outdated**: "The changes moved on since this was written, so the line may be different now."
* Edit or delete your own comments; an edited one says "edited". An owner or admin can delete anyone's comment in the dashboard: "It will read "This comment was deleted" for everyone. This cannot be undone."
* A comment can be up to 20,000 characters. A review holds up to 2,000 comments in all, deleted ones included. One review you send with **Send review** can carry up to 200 line comments (AI tools send their line comments that way).
## Approve, ask for changes, or comment
**Review** opens "Review these changes":
* **Comment**: "Say something without approving."
* **Approve**: "These changes can go in."
* **Ask for changes**: "They need work before they go in."
Write a **Message** (optional for an approval; needed to comment or ask for changes) and click **Send review**. A review names the changes you looked at: if the branch changes while you read, nothing is sent and the latest changes are shown, so you review what will actually merge.
**Only people approve.** AI tools comment and ask for changes, but never approve: "Only a person signed in to Hiveku can approve changes. AI tools can comment and ask for changes."
* **Nobody approves a review they opened**: "You sent these changes for review, so someone else on your team needs to approve them." A review that an AI tool opened, with your key or from your chat, can be approved by you or anyone else on the team.
* **An approval is for the changes it saw.** When the branch changes after an approval, the status reads **Approved an earlier version**, and it needs a new approval before it counts.
* **Approve** is not offered on a draft ("This review is a draft, so it cannot be approved yet. Mark it ready first.") or on changes that come from Your site ("Changes that come from Your site cannot be approved. Comment or ask for changes instead.").
* **Dismiss** takes back a review: your own, or anyone's if you are an owner or admin in the dashboard. A dismissed approval no longer counts toward merging, and a dismissed request for changes no longer stops it.
## Drafts
**Back to draft** turns a review into a draft: "Back to draft. It cannot be approved or merged until it is marked ready." People can still read it, comment and ask for changes. **Mark ready** turns it back: "Marked ready. It can be approved and merged now." A draft cannot join the merge line.
## Edit, move, close and reopen
**Edit review** (the pencil beside the title) changes:
* **Title** and **Description (optional)**
* **Goes into**: move the review to Your site or another branch. A note "Retargeted from *old* to *new*" is left on it, and "Moving it to another branch means the approvals given so far no longer count." A request for changes keeps standing. Moving it where another open review of the same branch already goes is refused.
* **Keep this branch after merging**: keep the branch instead of archiving it when the review merges.
Anyone who can merge a review can edit it.
**Close without merging** asks **Why**: **Not going in** ("These changes will not be used."), **Replaced by other changes** ("Other changes do this instead.") or **Another reason** ("Say why in the note."), with an optional **Note** left as a comment on the review. A closed review shows its reason.
**Reopen** puts a closed review back: "Reopened. It is waiting for review again." A merged review cannot be reopened, and both branches must still exist.
## Merge
**Merge** in the drawer merges the review. When it would be refused, the button is off and says why, for example "This review is a draft. Mark it ready before merging", "Needs an approval from someone other than Sam" or "Changes asked for by Alex".
* **All or nothing.** If any file changed in the same place on both sides, nothing is merged. See [Conflicts](#conflicts).
* **Your site's latest changes are kept.** Before merging into Your site, Hiveku saves Your site's latest changes as a version ("Saved automatically before merging"). The merge itself is one version, marked **Merged "*branch*"**.
* **It does not publish.** "Merged "*branch*" into Your site. Put the latest version live when you are ready." Visitors see the change after you publish from the **Deploy** menu.
* **One merge at a time per site.** "Another review is being merged into this site right now. Nothing was merged. Try again in a few seconds."
The **Merge** button merges straight away. The merge line's checks (the secret scan and **Build before merging**) run only in the [merge line](/editor/merge-line), so add the review there when you want them.
After the merge, the branch is archived and can be restored for 30 days, unless it is kept (see [After a merge](/editor/branches#after-a-merge)). Reviews that went into the archived branch move to where this one went.
## Conflicts
A **conflict** is a file that both sides changed since the branch started, in a way Hiveku cannot combine: the same lines changed differently, a file that is not text (an image, for example), a file edited on one side and deleted on the other, or two versions too far apart to combine line by line. Separate edits in one file merge on their own.
When a merge is refused for conflicts, the drawer says "*n* files changed in the same place on both branches, so nothing was merged. Choose what to keep for each one, then merge again." **Choose what to keep** lists each file:
* **Keep this branch's**
* **Use Your site's** (or the other branch's, named, when the review goes into a branch)
* **Edit** (text files only): write the final text yourself. "Your site's lines come first, between `<<<<<<<` and `=======`. This branch's lines follow, up to `>>>>>>>`. Keep the lines you want and delete the three marker lines." Text that still holds a marker asks before it is saved.
**Show both versions** shows the two sides. A file "Too large to combine line by line" is resolved by keeping one of the two versions.
**Resolve *n* files** saves your choices as one new version of the branch: `Resolved 2 files. Your choices were saved as a new version of "spring-sale".` Nothing changes where it goes until the review merges: when "No conflicts left. Merge again to finish." appears, click **Merge again**.
* If Your site changes a file after you chose, nothing is changed: "Your site changed *file* after you chose, so nothing was changed. Its new version is shown below: choose again for it. Your other choices are kept."
* Conflicts are resolved against the branch this one was started from. If neither branch was started from the other, merge each into the one it was started from first.
* Editing a conflicting file by hand on the branch does not clear the conflict, because the merge still compares both sides with where the branch started. Choose what to keep instead.
## Bring Your site's changes into a branch
When Your site moves on after a branch starts, the branch's card says "Your site has *n* newer versions". Click it to bring them into the branch. Files that merge cleanly come across as one version named "Catch up with Your site"; files that changed in the same place on both open **Choose what to keep**. When it is done: `"spring-sale" is up to date with Your site.`
## Require an approval
**Require an approval** is one of the three [Branch settings](/editor/merge-line#branch-settings), off until an owner or admin turns it on: "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."
With it on, a review into Your site merges only when:
* at least one person other than whoever opened the review has approved its current changes, and the approval was not dismissed;
* nobody's latest review asks for changes. An older request for changes keeps standing until that reviewer approves or comments again, or it is dismissed.
Reviews into other branches are not affected. A refused merge says "Nothing was merged. Needs an approval from someone other than Sam." The merge is tied to the approved changes: a save on the branch after the approval refuses it ("The changes moved on after they were approved, so nothing was merged. Look at the current changes and approve them again.").
With the rule on, AI tools cannot merge a branch straight into Your site: they open a review for a person to approve. Hiveku AI can still merge into Your site, and only after the person approves its card in the chat.
## Notifications
The person who opened a review hears in their Hiveku notifications (bell, email and push, as their **Mentions** setting says) when someone reviews it, comments on it, declines it or merges it from the review, and when its branch is archived or it moves to another branch: for example "Sam approved "New pricing"", "Sam asked for changes on "New pricing"" and "Sam merged "New pricing" into Your site". For a review an AI tool opened, that is the person whose key it used, or whose chat it was. Nobody is told about their own action.
Two things are not sent to the opener: closing a review without declining it sends no notification, and when the [merge line](/editor/merge-line) merges a review, the person who added it to the line is told instead.
Reviewers see what is waiting under **Waiting for review** on the **Branches** tab.
## Who can do what
* **Websites › Deployments: View** shows reviews and their conversations.
* **Websites › Deployments: Manage** asks for, edits, closes, reopens and merges reviews, comments, and reviews. Approving needs a person signed in to the dashboard.
* An **owner or admin** can also change Branch settings, dismiss anyone's review and delete anyone's comment.
See [Permissions](/settings/permissions).
## Common questions
Not yet. A merge changes Your site. Visitors see it after you publish from the **Deploy** menu.
No. Only a person signed in to Hiveku approves, and nobody approves a review they opened. AI tools can comment and ask for changes.
The branch changed after the approval. Look at the latest changes and approve again.
A merge compares both sides with where the branch started, so editing one side does not clear it. Use **Choose what to keep** in the review.
It was archived. Open the merged review and click **Restore** within 30 days. To keep a branch, turn on **Keep this branch after merging** in **Edit review** before you merge.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.