Activity bar
You can use the activity bar to quickly open files, commits, issues, pull requests, chats, and terminals for the project you are working on.
Navigate the activity bar
The activity bar is organized into Project, Git, DevOps, and Assist sections. DevOps activities appear only when the corresponding provider feature is configured for the project.
The activity bar stays visible. Click an activity icon or label to open its panel beside the bar. Click it again to hide the panel.
Click Hide Labels to view only the item icons of the activity bar.
To initialize a local non-Git folder into a new local Git repository, click Initialize. To publish a local Git repository without a remote branch, click Publish.
Use activity controls
Activity and item context menus focus on actions inside Zide. They omit actions to open or copy provider website links. Issue menus can copy issue numbers. To open a DevOps view on its provider’s website, click the remote badge and use its website link.
Right-click the activity heading or empty list space to open the same actions as More actions. Assist with This attaches the activity’s supported view context to a Zide Assist conversation. It appears only when the activity can describe its contents, rather than just its title. It does not attach every item’s full contents. To ask about one item, right-click its row instead. Right-click a selected row to use Assist with Selection for several selected items.
Activities with detailed cards offer Compact Mode under View in More actions. A check mark on the left shows when it is on. Compact Mode switches to one-line summaries by hiding secondary details. Each panel keeps its own choice while the project is open. Row actions, status indicators, and matching session search text remain available. Turn it off to show the full rows again. Exclusive choices, such as List or Tree, use a radio dot in the same position. Activities with a collapsible list filter also have a filter icon.
To change row spacing across projects, open Settings > Appearance > Interface Sizing and choose List Density: Comfortable or Compact. This setting applies to activity panels and standalone lists without hiding information or changing their compact-view choices.
The top line of an activity panel shows the activity name and the More actions menu (three dots). A DevOps activity also shows its source badge, for example the GitHub logo and the remote name. Click the badge to see the source details. To open the repository on the provider’s website, click Open on GitHub (or the name of your provider) in those details. If you choose another remote for Issue Tracking or Code Review in DevOps > Configure…, an open Issues, Pull Requests, or Merge Requests activity reloads for that remote: its badge, list, and filter choices.
Some activities show their controls on the same line as the name. Commits shows its filter and Graph view icons there. Reference Log shows its filter icon. Issues and Pull Requests show their New Issue or New Pull Request button there. On GitLab, Merge Requests shows New Merge Request.
Stashes puts Push Stash on the title row. Commands, Session List, Terminals, Actions, and Releases put their primary action and filter icon there too. Script Runner puts its filter icon on the title row and keeps Scripts and History below it. Issues and Pull/Merge Requests keep a separate row for their filter selector and filter icon.
In Commits, Reference Log, Stashes, Issues, Pull Requests, Merge Requests, Actions, Pipelines, Releases, Commands, Session List, and Terminals, More actions also contains each button and icon from the top line and the control row, with an action icon or setting indicator. A setting that is on, such as Compact Mode, shows a check mark. Commands that apply only to the whole activity, such as Drop All Stashes…, are only in More actions. In Script Runner, More actions contains Show Filters and the commands and settings that you use less often, such as Rescan and Clear History…. Find in Files and Staging keep their controls beside the work they affect.
Activity headers reserve the same title space and gap, based on the widest activity name. When you switch activities, their controls appear fitted to the current panel width. As you narrow the panel, optional icons such as view icons hide first, the remote badge beside More actions shrinks to its provider logo, and then the primary button loses its label. The filter icon hides only after that, so you can open and close the filter panel from the top line at the default width. Widening the panel restores the primary button label before the remote name. Hidden shortcuts remain in More actions.
Activity colors
The activity icon and its tooltip show the reason for attention:
| Activity | Meaning |
|---|---|
| Staging | Amber for uncommitted changes or a Git operation ready to continue; red for unresolved conflicts. These remain until resolved. |
| Actions and Pipelines | Red for a failed run on the current branch, blue while running or queued, and amber when waiting for user action. Success returns the icon to neutral. |
| Files | Amber for submodules needing attention, red for submodule errors or failed operations. |
| Script Runner | Red for failed runs started in Zide; blue for newly built artifacts you have not viewed. |
| Releases | Red for a failed release operation, such as publishing or uploading an asset. Drafts and successful releases do not change the icon color. |
Keep failure indicator after viewing is on by default, so failures stay red after you view the activity. To clear failure indicators when viewed, turn it off in More actions > Failure indicator. The choice persists across projects and restarts. Actions and Pipelines share one choice; Script Runner and Releases each have their own.
Actions considers workflows for the newest commit with runs on the current branch. Older scheduled or manual failures do not keep the icon red. With this setting on, a failure stays red while its workflow retries that commit, until it succeeds. An unrelated workflow’s success on the same commit does not clear it. A newer commit starts with its own results. Pipelines also scopes failures to the newest commit with runs on the current branch. Script Runner and Releases retain failures observed during this app session until the same script or operation succeeds. Stopping a script does not count as a failure or a successful retry.
To clear historical submodule failures, use Files > More actions > Submodules > Dismiss Failed Operation Notices. Current repository problems remain highlighted.
When failure indicators clear after viewing, other work that is running or waiting for action remains highlighted. A retained failure can keep the activity red while its retry shows blue in the panel.