Skip to main content

Branching Overview

Team Plan

GitSync connects your workspace to a Git repository. Branching decides how many branches that workspace uses and how changes reach the branch your team treats as live.

There are two modes. Every workspace starts in single-branch mode, and multiple branches are something you opt into.

How the Modes Differ​

Single-branch modeMulti-branch mode
BranchesOne, the default branchA default branch plus feature branches
Editing the default branchAllowedBlocked, changes arrive by merge
How changes reach GitCommit directlyCommit to a feature branch, then merge a pull request
Review before changes landNoneRequired, through a pull request
Builders working at onceOne at a timeIn parallel, each on their own branch

Choosing a Mode​

Single-branch mode suits a team where one person edits an application at a time. You get a version history in Git, backup and recovery, and the ability to move applications between development, staging, and production instances. Changes go straight to the branch, so there is no review step and no merge conflicts to resolve.

Multi-branch mode suits a team building in parallel. Each builder works on their own branch, the default branch is read-only, and everything that reaches it has been through a pull request. That gives you isolation between builders and an approval gate before anything becomes releasable.

If you are unsure, start with single-branch mode. Turning branching on later does not discard anything you have already committed.

Behavior Shared by Both Modes​

Some behavior does not change with the mode:

  • Versions and Tags covers drafts, saved versions, and how versions are tagged in Git.
  • Resolving Conflicts covers duplicate names and slugs, which are checked before anything is written in either mode.
  • Auto-Sync keeps connected instances up to date from the repository.

Need Help?​