Skip to content

Branches

Zide’s Branch control is the compact place to find a branch and decide what to do with it. The full Branches tab uses the same branch names, relationship information, filters, sorting, and action rules while adding configuration, cleanup, remote management, and destructive operations.

Use the Branch control

The Project Header displays the current branch. Click it to open the Branch control.

The current branch appears separately at the top so it is never confused with an action target. When useful, this area also shows its default-branch status, worktree, dirty state, recent activity, relationship to the default branch, and Merge & Close.

Under Select branch, each matching branch shows:

  • Its last commit activity
  • A Branch icon for local branches, Worktree icon when already checked out, or Remotes icon for remote-only cached refs
  • A favorite star for local branches
  • The (default) annotation when it is the detected default branch

Relationship counts are intentionally deferred until selection, where they can inform an action instead of crowding every list row. When the current branch is not the default branch, the Current branch area also reports commits available from the default branch when there are any.

Clicking a branch does not switch immediately. It opens a second stage with the operations that apply:

  • Compare with current branch opens immediately.
  • Merge into current branch… stays disabled until the relationship is known, then opens a directional confirmation before Git runs. A compact summary shows the number of incoming commits; current-only history is omitted because the merge retains it. The default Auto Merge action uses Git’s normal merge behavior without showing strategy controls. Expand Advanced options to see all four strategies. Auto is selected and described as recommended for most merges, alongside contextual conflict-resolution preferences.
  • Switch branch switches a local branch. Dirty changes use the existing stash/switch decision flow.
  • Check out and switch to [remote-only branch] explains that Zide will create a local branch first.
  • Create worktree for [branch] opens worktree setup.
  • Open worktree for [branch] replaces Create when that local branch is already checked out.

Use Back at the bottom left to return without losing your search, filters, sort, scroll position, or selection. Cancel closes the control. Compare and Open Worktree are navigation actions and therefore do not add a confirmation step.

Remote-only branches use the remote-tracking ref already cached in your repository. Selecting, comparing, merging, or checking one out does not fetch automatically. Fetch first when you need the latest server state.

If local and remote refs with the same short name point to the same commit, they appear as one branch even when no upstream is configured. If their tips differ, expand the exact-ref choice and select the full ref that the operation should use, such as feature or origin/feature.

Search, filter, and sort

Search matches branch names as you type, including full remote prefixes. The inline clear button clears only the search text; press Escape to clear text before Escape closes the control.

Open the icon-only Filter control for these options:

  • Worktrees: any status, in a worktree, or not in a worktree
  • Location: any location, local, or remote-only

Use the clickable Name and Activity captions above the list to sort and reverse the selected order. The header control and Branches tab use the same column-header treatment and keep label positions fixed as the sort indicator moves between columns.

The branch list uses a darker surface than the Create and Manage sections, so searching and selecting branches remains visually separate from management shortcuts.

Activity sorts by newest tip commit and is the initial default. Zide remembers an explicit Activity/Name choice. The matching default branch sorts first, followed by matching favorites; default and favorite branches still have to match active search and filters. Reset filters and sort clears structured filters and restores Activity without clearing search text.

Create and manage

The first stage also includes:

  • New branch and, where supported, New worktree under Create
  • Branches and Worktrees under Manage

On a worktree Project Tab, the singular Worktree control in the Project Header replaces Branch. It manages the current worktree’s source relationship and lifecycle, including compare, merge from source, merge back, sibling navigation, management, and deletion. Use View Branch Details there for general branch management.

Use the Branches tab

Open Git > Branches for the full management view. The current branch remains separate. Local and remote-only branches have their own categories, while repeated quiet Name and Activity captions sort each category using one shared ordering. Search, worktree associations, exact refs, and current-relative relationship details follow the same shared model as the header control.

Click a branch row to expand commit details, Git configuration, exact-ref selection, and actions. The tab additionally supports rebase, create-from, rename, copy, deletion, sync-remote configuration, pruning remote-tracking refs, and deleting merged branches.

Create a new branch

  1. Open the Branches tab and click New Branch.
  2. Enter the branch name.
  3. Click Create & Switch.

Delete merged branches

Click Delete Merged to review and delete local branches already merged into the current branch. The optional remote checkbox clearly identifies that it also pushes deletion of each selected branch to its configured remote server.

Remote management

  • Fetch explicitly refreshes a selected remote-tracking ref.
  • Checkout creates a local branch from the selected cached remote-only ref after confirmation.
  • Delete Remote Branch pushes a deletion to the remote server after confirmation. It is unavailable while conflicts are active.
  • Prune [remote] removes stale remote-tracking refs for that remote.

Branch and worktree controls remain Git-only. Pull-request, CI, and provider-specific status appear in their own DevOps surfaces.