dsh-workbench-layout: Provides a three-column workspace layout for DSH Web
dsh-workbench-layout is a DSH Web plugin (npm package @lsq64737/dsh-workbench-layout, MIT license) that reorganizes the official AppFrame into a three-column layout: left side contains Sessions, File Browser, Git Changes and Commit Graph, Terminal List; middle is Multi-file Tab Editor and Terminal; right side preserves the native DSH session, allowing users to view files, Git status, and run commands without leaving the conversation. Core features include: sorting by Git status...
Read Moredsh-git-sidebar: View uncommitted changes in the Git workspace on the DSH conversation page
dsh-git-sidebar is an embedded plugin for the DeepSeek Harness (DSH) Web GUI, maintained by H2O-MERO and licensed under the MIT License. It aims to address the high operational overhead associated with users frequently switching terminals or IDEs to check Git status when managing workspace files in the conversation page. It provides a VSCode-style sidebar for uncommitted changes on the right side of the DSH conversation page, enabling users to intuitively view staged, unstaged, and untracked files of the current workspace Git repository without leaving the current session interface. Core features include automatically following the workspace repository of the current conversation, supporting the viewing of file status badges (e.g., M, A, D), line-level diff statistics (+/-), and single-file diff expansion; renamed files will display the old and new paths, and untracked...
Read MoreThe Distinction Between Git's Staging Area and Working Directory: The Reason for `add` Before `commit`
This article introduces the core concepts, differences, and functions of the working directory and staging area in Git. The working directory consists of files that can be directly operated on locally (like a draft paper), while the staging area is an internal intermediate repository within Git (like a pending review express box). The key differences between them are as follows: location (the working directory is the local file system, while the staging area is internal to Git), editing methods (the working directory can be modified directly, while the staging area requires changes via commands), Git tracking status (the working directory is untracked, while the staging area is marked for commit), and visibility (modifications in the working directory are directly visible, while the staging area is only visible to Git). The process of "add before commit" is mandatory because the staging area allows for more selective commits: skipping the staging area and directly committing would cause Git to submit all changes in the working directory, potentially leading to accidental commits of incomplete work. By following the workflow of "modify → git status → git add → git commit", developers can achieve staged commits. As a buffer zone, the staging area helps developers flexibly control the scope of commits, preventing drafts or incomplete content from being accidentally committed and making code management more controllable.
Read MoreDetailed Explanation of the Relationships Between Git Working Directory, Staging Area, and Local Repository
The three core areas of Git (working directory, staging area, and local repository) have clear divisions of labor and work together to complete version control. **Working Directory** is the directory you directly operate on (e.g., a project folder), where you can freely modify files (add, delete, edit). It is the "operation site" visible to the user. **Staging Area** is a hidden temporary area (`.git/index`). You use `git add` to stage changes for commit, and you can preview or undo them (e.g., `git reset HEAD <file>`). It acts like a "transfer station/fridge". **Local Repository** is the `.git` directory, which stores project version history, branches, etc. Changes from the staging area are committed into version history via `git commit`, making it a "permanent storage room". The core workflow among the three is: **Modify → Stage → Commit**: Modify files in the working directory, stage them with `git add`, and commit to the local repository with `git commit`. Understanding this workflow allows you to manage code versions clearly and avoid operational chaos.
Read More