Skip to main content

Understanding Branches

Most users only need the main branch. Branching is useful for teams or advanced workflows, but if you’re working solo or just getting started, staying on main is perfectly fine — you can always create branches later.
Web app: The ByteRover web dashboard currently supports the main branch only. Multi-branch support in the web app is coming soon. In the CLI and TUI, all branching features are fully available now.
Branches let you work on different versions of your context tree in parallel. Each branch is an independent line of development — changes on one branch don’t affect others until you explicitly merge them. Common use cases:
  • Feature branches: Experiment with new domain structures or context reorganization
  • Team branches: Each team member curates context independently, then merges
  • Release branches: Maintain a stable context baseline while developing new content

List Branches

View the branches in your context tree.
The current branch is marked with * in the output. Remote-tracking branches (shown with -a) appear as origin/<branch-name>.

Flags

Create a Branch

Create a new branch from the current HEAD. The new branch points to the same commit you’re currently on.
Creating a branch does not switch to it. Your working tree stays on the current branch. Use vc checkout to switch.

Error Handling

Switch Branches

Switch your working tree to a different branch. This updates all context tree files to match the target branch’s latest commit.

Create and Switch in One Step

Use the -b flag to create a new branch and immediately switch to it. This is the most common way to start working on a new branch.
This is equivalent to running vc branch feature/new-context followed by vc checkout feature/new-context.

Force Switch

If you have uncommitted changes that would conflict with the target branch, the checkout will fail with an UNCOMMITTED_CHANGES error. Use --force to discard those changes and switch anyway.
--force permanently discards any uncommitted changes in your working tree. Commit your work before force-switching if you want to keep it.

Flags

Error Handling

Delete a Branch

Remove a branch you no longer need. This deletes the branch pointer only — the commits it pointed to are preserved in the history.

Error Handling

Set Upstream Tracking

Link your current local branch to a remote-tracking branch. This enables vc status to show ahead/behind counts and allows vc pull/vc push to work without specifying the remote and branch.
You can also set upstream tracking during push with brv vc push -u origin <branch>, which pushes and sets the upstream in one step.

Merge a Branch

Merge another branch into your current branch. This incorporates all the commits from the source branch into your current branch.

Basic Merge

If the merge completes without conflicts, a merge commit is created automatically.

Merge with Custom Message

Provide a custom message for the merge commit instead of the default:

Merge Unrelated Histories

When merging branches that share no common ancestor (e.g., importing context from a completely separate space), Git-Semantic will refuse the merge by default. Use the --allow-unrelated-histories flag to override:

Merge Outcomes

A merge can result in one of three outcomes:

Flags

--abort and --continue are mutually exclusive — you cannot use both in the same command.

Error Handling

Resolve Merge Conflicts

When a merge produces conflicts, the merge pauses and waits for you to manually resolve them. Conflicts occur when both branches modified the same part of the same file.
1

Check merge status

Confirm the merge state and see which files are affected:
Status will show that a merge is in progress and list unmerged paths.
2

Edit the conflicting files

The status output lists unmerged paths and files with conflict markers. Open each conflicting file and resolve the conflict markers. A typical conflict looks like:
To resolve:
  1. Decide which content to keep (or combine both)
  2. Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
  3. Save the file
All conflict markers must be removed before you can complete the merge. The CONFLICT_MARKERS_PRESENT error will occur if any remain.
3

Stage the resolved files

After resolving all conflicts, stage the fixed files:
4

Complete the merge

Finalize the merge by creating the merge commit:
If no -m flag is provided, your configured editor ($GIT_EDITOR or $EDITOR or vim) opens for you to write the commit message.

Abort a Merge

If you want to cancel a merge entirely and restore the state before the merge started:
This is safe — it discards the merge state and returns your working tree to the pre-merge state. No commits are lost.

Branching Workflow Examples

Feature Branch Workflow

The most common pattern — create a branch, make changes, merge back:

Team Collaboration Workflow

Multiple team members working on different context areas:

Experiment and Discard

Try a risky restructuring without affecting your main context: