Project tabs

A project is a folder that you open in Zide. Any folder can be a project, with or without Git. Each open project, including each open Git worktree, has its own project tab.

Files outside your open projects open in Standalone Files. This separate tab sits at the left of the project tab bar. It does not replace a project tab or change project numbers.

Opening a project claims back the files that belong to it: any file sitting in Standalone Files that the project you just opened contains moves into that project tab, keeping your unsaved changes, undo history, cursor, and view exactly as they were.

Project tab bar layout

The project tab bar contains each project tab that you have open. You can drag a project tab to rearrange the order the tabs appear in. When the project tab bar is full, arrow buttons appear at the ends of the project tab bar for scrolling. A dropdown menu also appears to select a project tab.

Project header layout

The header of a project tab contains the following icons.

Icon	Description
Branch	Browse, manage, and open branches and worktrees.
Worktree	For worktrees, manages the current worktree’s source relationship and lifecycle.
Push	For a Git repository. Pushes local commits to the selected remote.
Pull	For a Git repository. Pulls commits from the selected remote branch. Click the More pull options to fetch commits or select if commits merge or rebase.
PR/MR	Displays the current pull request or merge request for the current branch.
Refresh	Fetches from the remote and reloads all content tabs.
Project actions	Opens less-frequent project and Git actions.

Open PR/MR to see the current branch’s review status and actions. The dropdown is titled Pull Requests on GitHub and Bitbucket, or Merge Requests on GitLab, including when no review exists. It shows the source branch, an arrow, and the target branch on separate lines. Long branch names wrap so you can read both names.

The Status line describes the current state. View Pull Request or View Merge Request opens the review’s detail tab without changing its state. Under Manage, Pull Request List or Merge Request List opens the provider’s review list.

Each project’s PR/MR control works only with that project. If you switch to another project tab while the control loads, its status and actions stay with the project where it started.

The control shows the review from the repository that the branch is pushed to. Zide follows Git’s push settings (branch.<name>.pushRemote, remote.pushDefault, then the branch’s remote), then uses the project’s default remote, then origin. One exception: a branch that tracks a different branch on the Code Review remote, for example one made with git checkout -b feature upstream/main, is pushed to the default remote. When that repository is a fork of the Code Review repository, Zide shows the review from the fork. A review from another fork with the same branch name does not show.

Create Pull Request or Create Merge Request opens the New PR or New MR tab with both branches filled in. When the branch has commits that are not pushed, the action reads Push & Create Pull Request or Push & Create Merge Request. It only opens the tab; Zide pushes the branch when you create the review. If a New PR or New MR tab for the same repository and branches is open, Zide shows it. A tab for other branches stays as it is, and Zide opens a new tab.

If Zide cannot create the review from the branch’s repository, the create action is unavailable. Point to it to see the reason. For a branch on a fork, GitLab and Bitbucket projects also show Create on GitLab or Create on Bitbucket, which opens the provider’s create page in your browser.

When the branch name contains an issue number, such as issue-12-widget or fix/12, Zide looks for that issue in the project’s Issue Tracking repository. If the issue exists, the empty description starts with a reference to it: Closes #12 when the issue is in the review’s repository, owner/repo#12 for another repository on the same provider, or a link to the issue. Bitbucket always uses a link. Zide does not change a description that has text. Generate uses the same reference and adds no other issue references.

Click the Project actions icon to refresh the project, open the folder in the File Manager, open it in an external terminal, or copy the folder path. For a Git repository, the menu also opens Git Overview and Manage Remotes.

Branch

You can view and create branches in the repository from the project tab header. Click the Branch control to open the Branch dropdown. Branches are separated into the current, favorites, local, and remote sections. The Branch dropdown lists if a branch is a local branch, a local worktree branch, or a remote branch. Click View branch details to open the selected branch in the Branches tab.

Click Name to sort branches by name. Click Activity to sort by latest activity. Use Search branches to find a branch by name. Click Filter branches to filter by worktree status (In a worktree or Not in a worktree) or location (Local or Remote-only).

Click a branch to perform the following actions.

• Push: Push the commits of the local branch to the remote.
• Show in Commits: Go to the latest commit on the selected branch in Commits.
• Create Tag: Create a tag from the selected branch.
• Compare with current branch: Compare the commits of the selected branch to the current branch.
• Merge into current branch…: Merge the commits of the selected branch to the current branch.
• Switch branch: Switch to the selected local branch.
• Check out and switch: Create and switch to a local copy of the selected remote branch.
• Create worktree: Create a worktree of the selected branch.
• View branch details: Open the selected branch in the Branches tab.

A merge that changes files starts only when no operation is in progress, tracked files have no uncommitted changes, and no untracked or ignored files are in the way. Otherwise Zide lists the blockers and offers the actions that can clear them, such as Open Staging or Stash Changes and Review. After a stash, Zide asks you to confirm the merge again.

When the repository has a post-checkout hook, or changes files as Git writes them with a filter such as Git LFS or with a working tree encoding, Zide switches branches through Git. The files and the hook then match a switch made with Git. If Git stops before it moves to the new branch, for example because a required filter fails, the current branch does not change, and Zide names the files that Git already changed. If Git moves to the new branch but cannot write every file, the new branch stays checked out, and the error says so. Review the files in Staging before you try again. If the hook fails after the switch, the switch stays done. See A hook failed after a checkout or discard.

Click New branch… to create a branch. Click New worktree… to create a worktree. Click Branches to open the Branches tab and click Worktrees to open the Worktrees tab.

For more information about Branches, see Branches.

Worktree dropdown

A worktree Project Tab replaces the Branch control with a singular Worktree control. Neutral styling means ordinary work is active, cyan means committed work is ready to merge into the repository’s default branch, amber marks a condition that needs attention, and red means the worktree folder is missing.

Open the control to view the Worktree branch, open its details in the Branches tab, merge newer commits from the default branch into the worktree, open Finish worktree…, or open the full Branches and Worktrees tabs.

The Finish dialog can merge the worktree branch into the branch currently checked out in the parent project, delete the worktree folder, and optionally delete the branch after removal. It shows the parent branch read-only, explains blockers and data-loss risks for each choice, and rechecks the repository state before changing anything.

For complete lifecycle and safety details, see Worktrees.

Conflict banner

The Git-operation header and Staging activity icon are red while conflicts remain, and amber when the operation is ready for you to continue or commit.

When a merge, rebase, cherry-pick, revert, or patch series stops on a conflict, the Branch or Worktree control becomes a conflict banner. So does an Interactive Rebase that stops at a commit set to Edit. The banner names the operation and, when available, the branch, for example Merge: main or Rebase: feature. A patch series is a set of patches that git am applies. Zide shows one that Apply Patch Series started, or one that a terminal or another tool started, for example Patch series: main.

The banner shows one action: what the operation is waiting for. While files remain conflicted, it shows Resolve N files. Click it to show Staging. When no conflicts remain, it shows Commit, or Continue for a rebase, a patch series, a cherry-pick of several commits, a squash merge, or a cherry-pick or revert without a commit. A squash merge, and a cherry-pick or revert without a commit, leave the result staged for you to commit. If Continue cannot run, for example because nothing is staged for the current patch, it is dimmed and its tooltip gives the reason.

If a terminal or another tool checks out a different branch or detaches HEAD while an operation is paused, Git finishes the operation there. When Zide detects this, the banner keeps the operation’s branch and shows now on other or detached HEAD. The menu explains the change and its effect. Commit, Continue, and Skip ask you to confirm first. To go back, click Check out branch in the menu, or Detach HEAD for a rebase or an operation that started on a detached HEAD. Only HEAD moves. Files and staged changes stay unchanged. If the branch is unavailable, the menu shows why.

Click the operation label to open a menu headed Merge paused, Rebase paused, Cherry-pick paused, Revert paused, or Patch series paused. At an Edit stop, it is headed Rebase stopped to edit, and Continue stays dimmed, with the reason in its tooltip, until the edit is finished. It shows:

• Current and Incoming: the branch, when there is one, and the commit for each side.
• Base (or Bases): the commit the two sides are compared against.
• A rebase shows Target, the branch it rebuilds onto, and Incoming, the commit it is applying now. It leaves out the other two, because a rebase detaches HEAD onto commits it has just written.
• A patch series shows Current and Patch N of M, with the subject and author of the patch Git stopped on. A patch is not a commit, so it has no hash.
• A cherry-pick started from Cherry-Pick Commits shows Incoming, commit N of M.

Press Escape while the menu has focus to close it and return focus to the operation label.

Click a commit hash to open its details. For a rebase started from an Interactive Rebase plan, Show Rebase Plan opens that plan. Resolve N files opens Staging with the conflicts. When none remain, the row says Open Staging. During a rebase, Skip this commit… leaves out the commit Git stopped on and its changes. It is not shown at an Edit stop, where the commit is already applied. In a patch series, Skip this patch… leaves out the current patch and its changes. In a cherry-pick of several commits, Skip this commit… leaves out the commit Git stopped on. When that commit has no changes left to apply, Keep Empty Commit keeps it as an empty commit and continues, and Continue is dimmed. For a cherry-pick started from Cherry-Pick Commits, Show Cherry-Pick Plan opens the plan. To abort, click Abort merge…, Abort rebase…, Abort cherry-pick…, Abort revert…, or Abort patch series…, then confirm.

Abort restores files to the commit where the operation started. All changes in those files are discarded, including conflict resolutions. Unstaged changes in other files are kept. The confirmation names the starting commit and how many files are restored and kept. If HEAD moved after the operation started, for example because a commit was made during the merge, Zide does not abort and shows why. When Git runs the operation, for example a revert of several commits, Git performs the abort and the confirmation shows no file counts. For a cherry-pick of several commits, the confirmation says how many commits are removed.

Git performs Continue, Skip, and the abort for a patch series. Continue commits the current patch with the patch’s author and message, then applies the next patches until one stops. Staging cannot make an ordinary commit while a patch series is paused. Abort returns the branch to the commit where the series started and removes the commits the series added. The confirmation names that commit and how many commits are removed.

Zide does not continue, skip, or abort a patch series in these cases:

• HEAD moved after Git stopped, for example because another tool moved the branch. The menu shows where the series stopped and where HEAD is now. Use the Reflog to review the change.
• Git’s state does not show whether a patch series or a rebase is in progress. The banner shows Operation. Finish it with Git from a terminal.
• For Skip and abort only: a change that is not part of the series was staged after Git stopped. Git would discard it. Unstage it first. If Git refused the series at the start because changes were already staged, abort only ends the series and keeps those changes.

Bisect control

The Branch or Worktree control becomes the bisect control when you select a commit for bisect or a bisect is active.

• Bisect: Setup: select the missing good or bad commit, wait for validation, or correct the selection.
• Bisect: Ready: the selected commits passed validation. Click Start.
• Bisect: a1b2c3d: test this commit. Click Good if the bug is absent or Bad if it is present.
• Bisect: Blocked: the next test commit is not checked out. Resolve any checkout problem, then click Retry Checkout.
• Bisect: Found or Bisect: Inconclusive: the search is complete. Click Finish Bisect to return to the starting branch or commit.

Click the label to see details for the current state. The menu repeats the button on the control and adds the rest: Start Bisect and Cancel Bisect before you start, Mark as Good, Mark as Bad, and Skip while you test, and Retry Checkout when a checkout is blocked. While you test, those marks are grouped under Commit under test with the commit they act on. Undo Last Decision takes back the last answer and replays the rest. Show in Commits locates the commit under test or the first bad commit. Show Bisect opens the Bisect tab, which holds the range, the decisions, and the result. Abort Bisect… ends an unfinished bisect and returns to where it started.

For the complete steps, including undoing a decision and reading the result, see Bisect.

Push and pull

You can push, pull, and fetch changes from the project tab header. Click the Push icon to push recent changes you made to the remote branch. Click the Pull icon to pull changes from the remote branch to your local branch.

If the project has submodules, a pull also brings them to the commits it just recorded, and a short summary of that appears beside the buttons. See Submodules for what it does and does not move.

To fetch changes, click the More pull options icon and select Fetch. Then, click the Fetch icon to fetch changes from the remote branch to your local branch.

Click the More push options icon to push changes to a different remote, to include tags in a push, force push (with lease), force push (overwrite), or preview outgoing commits.

Click the More pull options icon to set the pull or fetch behavior to merge or rebase, pull or fetch from a different remote, or preview incoming commits.

In either preview, Show in Commits goes to the newest listed commit. It stays disabled while commits load, when there are no commits to show, or if loading fails. Hover over the button to see the reason.

If the repository has submodules

Before pushing the repository, Zide checks whether the required submodule commits are available on their remotes. This check can fetch from submodule remotes. If a commit is unavailable or cannot be checked, the push stops. A dialog shows the affected submodules, their destinations, and their commits.

If Zide can push the submodules for you, the title is Push this submodule too? or Push these submodules too?. Continue pushes each submodule branch, then pushes the repository. Cancel stops, and the repository is not pushed.

If Zide cannot push all required submodules, the title is Cannot push this repository. Each commit row shows a branch to push or a reason it cannot be pushed. Select Show in Submodules to review the affected submodules in the Submodules tab. See Submodules.

Work with project tabs

Click a project tab to switch between folders, repositories, and worktrees. Content tabs, split-pane layouts, scroll positions, and selections opened in the project tab remain open when you switch between project tabs.

Right-click a project tab to open options for it.

Switch project tabs from the keyboard

Shortcut	Action
Ctrl+Alt+1 – Ctrl+Alt+9	Switch to the first through ninth project tab.
Ctrl+Page Up / Ctrl+Page Down	Switch to the previous or next project tab.
Ctrl+Alt+`	Open the project switcher in most-recently-used order.

Previous and next navigation wraps around at the ends of the project tab bar. In the project switcher, keep Ctrl held and press Tab or Shift+Tab to move through the list, then release Ctrl to switch. Press Esc to cancel.

Ctrl+1 – Ctrl+9 switches content tabs inside the current project. See Content tabs.

Close a project tab

Close a project tab using its close button, by middle-clicking it, from Close Tab in its right-click menu, or with File > Close Project.

If the project or one of its worktrees has unsaved files, Zide lists them before closing. Choose Save & Close, Discard & Close, or Cancel. If a file cannot be saved, the project remains open with that file unsaved. The prompt also warns when closing would interrupt an active Zide Assist response.

Discard & Close is permanent. The listed edits are dropped, and reopening the project brings its files back as they are on disk. If Zide cannot record the discard, the project stays open with the files still unsaved rather than losing them.

Closing a repository also closes its worktree and submodule tabs. Zide identifies these related tabs before closing.

The right-click menu also provides Close Others, Close All, Close to the Left, and Close to the Right. These commands preserve parent-child relationships. When confirmation is required, choosing Cancel stops the entire close operation.

Reopen a closed project tab

To reopen the most recently closed project, press Ctrl+Alt+Shift+T, or right-click the project tab bar and click Reopen Closed Project Tab. Zide restores its split-pane layout, content tabs, worktrees, and submodules. Files reopen with their saved contents; unsaved edits you discarded on close are not restored. You can also reopen a closed project from the Recent list in the Open Project tab.

Zide remembers the last 10 closed projects during the current session. The command is disabled when there is nothing to reopen, and projects whose folders are no longer available are skipped.

Reopening a worktree or submodule restores it beneath its repository. This history is separate from Reopen Closed Tab (Ctrl+Shift+T), which restores content tabs.

Active work when closing

Closing a Project Tab checks its Zide Assist sessions, CLI Agents, and terminals, including those in child Project Tabs. Active work can require confirmation even when all files are saved. CLI Agent and terminal warnings follow your warning settings. Declining a warning keeps the project open and does not cancel sessions confirmed in earlier warnings. The same checks apply when you quit Zide.