Staging
You can use Staging to review changes before committing your files. It supports staging individual files, unstaging all changes at once, and committing your changes.
Navigate Staging
To open Staging, click Git > Staging. Staging opens in the side panel.
Changed files are organized into the Unstaged section, the Staged section, or the Conflicts section. Each file displays a Git status badge, the file path, and a stage or unstage icon. The following table lists all Git status badges that appear next to each file.
| Badge | Description |
|---|---|
| Modified | Tracked files with changes that are staged or still in the working tree. |
| Untracked | Files Git does not track. |
| Added | New files staged for the next commit. |
| Conflict | Files with unresolved conflicts. |
| Deleted | Tracked files removed from the working tree or staged for deletion. |
Each section scrolls independently and keeps its position when the file list refreshes. Large conflict lists scroll within their section, leaving room for Unstaged and Staged.
If a background refresh fails, Staging keeps the list and shows Changes could not be refreshed. This list may be out of date. The notice stays until a refresh succeeds.
Click a file to open its changes in a Diff tab. Click another file to show its diff in the same tab. For more information, see Diff viewer.
To keep a diff while you look at others, pin its tab. A pinned tab is never replaced.
To choose files and discard their changes, click the Discard Changes… icon in the Unstaged section header. See Stage, unstage, or discard selected files. To undo the last commit, click the Undo last commit icon in the Staging header.
To open a diff in its own tab that later files will not replace, right-click the file and click Open Diff in New Tab.
To open a file from Staging in a separate tab, right-click the file and click Open File in New Tab.
Stage and unstage files
To stage or unstage a file, click the Stage icon or the Unstage icon next to the file. To stage or unstage all files, click the Stage All Unstaged Files icon or the Unstage All Files icon in the section header.
Staged files with unstaged changes will display a partial badge.
Stage, unstage, or discard selected files
Click More actions for Staging. Click Stage Files…, Unstage Files…, or Discard Changes….
All files in the dialog are selected when it opens. To change the selection:
- Type a file path or part of a path in Filter files. The filter does not change which files are selected.
- Select or clear a file’s check box.
- Select or clear Select All. This changes the selection for all listed files, including files hidden by the filter.
The count shows how many files are selected and how many selected files the filter hides. Click Stage, Unstage, or Discard to apply the selection.
For a partially staged file, Stage stages its unstaged changes. Unstage removes its staged changes from the next commit and keeps the working file. Discard removes its unstaged changes and keeps its staged changes.
The Discard Changes dialog shows how many selected tracked files have changes to discard. It also shows how many selected untracked files it will permanently delete. Discard applies these changes without another confirmation.
The dialogs do not list conflicted files. Stage Files and Discard Changes also do not list nested repositories. Discard Changes also does not list submodules. A note shows how many files of each type are not listed.
If Zide reports that the repository changed, the action did not start. Click Review Updated List to load the list again. Files you selected stay selected if they are still listed. New files are not selected.
If some files fail, the dialog lists them and any files that were not attempted. Click Review Remaining to load the list again. Only the failed and not attempted files that are still listed are selected. The Console shows why each file failed.
Stash a file
Right-click the file. Click Stash This File…. The Push Stash dialog opens with only that file selected. Click Stash Selected Files, or Stash if this is the only selectable file in the scope. Changes in other files stay in your working tree and index. For more information, see Stash selected files.
Ignore an untracked file
You can ignore an untracked file from its shortcut menu. For the rule choices and where the rule is written, see Ignore files and folders.
Track a file with Git LFS
Right-click a file and select Track with Git LFS… to add a Git LFS pattern for it. If a rule already covers the file, the item is Open Git LFS. For the pattern choices and what you must stage afterwards, see Track a file from Staging or the file browser.
Commit and amend staged files
Use Generate beside Commit Staged Changes or Amend Previous Commit to draft both the subject and description with Zide. The label stays visible when the fields contain text. In a narrow pane, the label hides before the button wraps; the icon keeps its tooltip. Widen the pane to restore the label. Hover or focus the button to see both affected fields. Existing text opens a review before replacement, and applied results offer Undo. To expand the message editor, use the expand button beside the Commit and Amend tabs. It opens in the selected mode, with Generate in its header. The expand button is disabled when Commit has no staged files or Amend has no previous commit. You can still expand Amend to change only the previous commit message. Done returns the edited subject and description to Staging. Review the result, then click Commit or Amend.
You can commit changes once your files are staged. To create a commit, complete the following steps.
- In Staging, click Commit.
- Enter the commit message and optionally a description of the commit.
Commit templates are loaded automatically if a.gitmessagefile exists. - Click Commit.
You can also amend files to your previous commit. To amend your files to a commit, complete the following steps.
- In Staging, click Amend. Zide pre-fills the commit message from the previous commit.
- Click Amend.
- In the Amend Commit dialog, click Confirm.
You can skip pre-commit hooks in Advanced Options.
While Staging commits or amends changes, the button shows a spinner and Committing… or Amending…. You cannot stage, unstage, or discard changes during this time. You can still click a file to see its diff.
Finish a merge, rebase, cherry-pick, or revert
When a merge, rebase, cherry-pick, or revert pauses on a conflict, the conflicted files appear in the Conflicts section and the Project Header replaces the Branch or Worktree control with a conflict banner. Resolve each file, then finish the operation from that banner: click Commit for a merge, cherry-pick, or revert, or Continue for a rebase, a squash merge, or a cherry-pick or revert without a commit. To abort, click the operation label in the banner, select the abort action at the bottom of the menu, then confirm. See Project tabs.
Resolve a conflicted file
Select a conflicted file to see its two sides in a Diff tab. The conflict bar above the sides names the conflict and shows the actions that apply to it. These can include Stage As-Is and one control for where you resolve the file:
- Resolve in Zide opens the file in the editor with controls for each conflict.
- Open in tool starts the external merge tool that Git is configured to use.
When both are available, click the caret to choose one. Zide remembers your choice. With no external tool configured, there is one button and no caret.
Stage As-Is stages the file as it is in the working tree, including your edits. If the file is missing, it stages the deletion. It is not available for a binary conflict or a file deleted on both sides.
To see what Stage As-Is will stage, click Working file view in the Diff tab header. This view shows the file as it is on disk and highlights conflict marker lines. To choose a version, click Compare Versions.
After you remove all conflict markers and save a text file, it stays in Conflicts until you stage it. Its row shows a + button to stage the file in place of the conflict type. The Diff tab’s conflict bar turns green and shows Conflict: No markers remaining, with Stage instead of Stage As-Is as its main action. Zide checks for markers again before staging and refuses if any remain. Removing markers does not prove the merge is correct, so review the file before staging.
Click Last file commit beside a branch name to see the last commit that changed this file on that side, with its message and date. In a narrow column, click the history icon. Click the commit id to open the commit. This commit may not have changed the conflicting lines. For a deleted side, the button reads Deleted in and the id of the commit that deleted the file. If both sides share the commit, only the left column has the button.
Resolving in an external merge tool
Open in tool launches the merge tool Git is configured to use, with the base, local and remote versions of the file.
Closing the tool is not the same as resolving the conflict, so Zide stages the file only when the evidence says it was resolved: the tool saved something, no conflict markers remain, and the tool did not report failure. If you close the tool without saving, or save a file that still has markers in it, the file stays in the Conflicts group and the Console says why.
Zide reads mergetool.trustExitCode for the third of those checks, the same way Git does. It is off by default, because most tools do not report a declined merge in their exit status.
Conflicts with no markers
A conflict is not always two versions of some text. A file one side changed and the other deleted, a file both sides deleted, a binary file, a file too large to merge, and a conflicted submodule all have nothing to edit. Zide shows each of them in the way that suits it, and offers only the choices that conflict has:
Every conflict appears as two columns with the branch name above each one, because every conflict has two versions. What fills a column depends on what that version holds:
| Conflict | What fills the columns |
|---|---|
| Both sides changed the text | The two versions, as a diff |
| One side changed the file, the other deleted it | The surviving file as text or hex; the other column’s label is marked (deleted) |
| Binary Zide can preview | Image, audio, or video previews; Hex view shows each version’s bytes |
| Binary it cannot preview, or a file too large to read | Each version in hex; a version larger than 256 MiB shows its size instead |
| A submodule | The commit each side pins: its short id, its message, and its date |
| Deleted on both sides | Where each side moved the file to, when Zide can tell |
The conflict bar names the conflict. An action for one version is in that version’s column header:
| Conflict | Choices |
|---|---|
| Both sides changed the text | Use This Version under either side. It stages that whole version. To combine the two, resolve the file in the editor instead. |
| Changed on one side, deleted on the other | Keep File for the branch that kept it, Delete File for the branch that removed it |
| Deleted on both sides | Delete File in the conflict bar |
| Binary, or too large to merge | Use This Version under either side |
| Submodule | Use This Version under the commit it would pin |
Why a file deleted on both sides is a conflict
Deleting the same file on both branches does not cause a conflict. A conflict where both sides deleted the file usually involves a rename, such as each side moving the file to a different path. Zide shows any new paths it can identify. Delete File stages the deletion of the old path. Content that moved to a new path is not lost.
Taking a choice resolves and stages the file at once. Only a choice that stages a deletion asks you to confirm first.
Conflicts outside the sparse checkout
A conflict in a folder outside your sparse checkout stays in the Conflicts section. If Git writes the file into your working tree, you can resolve it as usual.
If the file is not in your working tree, you can inspect the conflict, but resolution actions are disabled. Zide does not create the file. Commit and Continue stay blocked until the conflict is resolved. To finish, use Git outside Zide to resolve the conflict or, if Git allows it, add the folder to your sparse checkout and resolve it in Zide. To stop, abort the operation from the conflict banner.
Resolving every conflict does not finish the operation. Once all conflicts are resolved, the Conflicts group stops warning and reads No conflicts, and the operation stays open until you finish it from the conflict banner in the Project Header.
When a resolution leaves nothing to stage and nothing unstaged, which happens when you resolve a conflict in favor of the side that already matches your branch, Staging reports All conflicts resolved and names the banner control that completes the operation. It reports Working tree clean only when there is no unfinished operation.