Git Stage

Git Stage is a VS Code sidebar extension for splitting staged work into named groups before turning it into a real Git commit.

Think of it as multi-staging for Git. You can stage one meaningful slice of work, keep working, stage another slice, inspect each group independently, then commit the staged set when it is ready.

Features

• Stage all current working-tree changes into a named stage.
• Browse named stages and loose changes in flat list mode or folder tree mode.
• Open editable files or view diffs from either Stages or Changes.
• Merge one stage with its children, or merge all stages into one.
• Discard individual stages, all stages, individual loose changes, or all loose changes.
• Generate a commit message from the staged groups.
• Commit staged work from the sidebar, with an optional Commit & Push action.

Sidebar

Git Stage adds a dedicated activity-bar view with three sections.

Commit

The Commit section lets you write or generate a commit message, then commit all named stages.

The Commit and Generate buttons are disabled until at least one named stage exists. If loose unstaged changes still exist, Git Stage warns before committing and lets you skip future warnings.

Stages

Stages contains the named groups created through Git Stage.

Files can be shown as a flat list or grouped by folder. Clicking a file opens its diff. Inline actions let you open the real editable file, view its diff, merge stages, or discard stages.

Available section actions:

• Merge All Stages: squash all stages into a single stage using the root stage name.
• Discard All Stages: remove every named stage without discarding unrelated working-tree changes.
• Toggle View: switch between list mode and tree mode.

Changes

Changes contains loose working-tree edits that are not yet captured in a named stage.

Available actions:

• Stage All Changes: capture the current loose changes into a named stage and run git add --all.
• Discard All Changes: restore tracked files and clean untracked files.
• Open File: open the editable file from the workspace.
• View Diff: compare a loose change against the most recent staged version of that file, or HEAD if it has not been staged through Git Stage.

How It Works

When you use Stage All Changes, Git Stage stores the captured file contents in extension metadata under the repository's .git directory, then stages the files in Git's normal index.

The workspace file stays editable. When a file has staged content from Git Stage, opening it from Explorer or Git Stage shows the latest staged version unless you edit it again. New edits appear in Changes as loose work.

When you commit from Git Stage, the extension commits the current Git index instead of running another git add --all. That means edits made after the last Stage All Changes action stay loose and are not accidentally included.

Behind The Scenes

Git itself only has one staging area: the index. Git Stage does not replace that or invent a second Git index. Instead, it uses the normal Git index for the real commit, then keeps a small map of how the staged files were grouped.

Each named stage stores:

• the stage name and parent relationship
• the files captured in that stage
• the file content before the stage
• the file content after the stage
• a snapshot of the Git index so external staging can be detected later

That metadata is written to .git/gitstage.json, so it stays local to your repository and is never committed. The actual files are still staged in Git's index, which means normal Git commands continue to work.

When you create a stage from Git Stage, the extension captures the loose working-tree changes, runs git add --all, records only the files that belonged to that stage, and links the new stage to the most recent stage. This creates the visual chain of staging areas while Git still sees one final staged set.

When something stages files outside the extension, such as git add ., VS Code Source Control, or a stash apply, Git Stage compares the current index with its last recorded index snapshot. Any new or changed staged files become a new automatic child stage. If files are unstaged outside the extension, Git Stage removes those files from the matching stages; if the whole index is cleared, the staged areas are cleared too.

The Changes section only shows loose working-tree edits that are not already represented by the staged index. This is why a staged file disappears from Changes but still appears under Staged Changes.

Basic Workflow

1. Open a Git repository in VS Code.
2. Open Git Stage from the activity bar.
3. Make a focused set of edits.
4. Use Stage All Changes from Changes and give the stage a name.
5. Continue working and create more stages as needed.
6. Review staged files with View Diff.
7. Merge or discard stages if the shape of the work changes.
8. Generate or write a commit message.
9. Commit, or Commit & Push.

Development

pnpm install
pnpm run compile
pnpm run lint

The extension builds directly with tsc; webpack is not used.