zai-org / zai-org/feedback

[建议 / Feature] 支持识别单一文件夹下的多个 Git 仓库(multi-repo workspace)

Open
#574 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: P2
Dominant language
No language data
Stars
22
Forks
1
PR merge metrics
No merged PRs in 30d

Description

提交前确认 · Pre-submission checklist

  • 我已搜索过现有 issue,确认这不是重复提议 / I searched existing issues and confirmed this isn't a duplicate.
  • 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

已确认与现有 issue 无重复:#132 / #220 针对的是「单仓库内 multiple worktrees」,与本次「一个文件夹下多个独立 Git 仓库的识别」不是同一场景。

问题类别 · Category

文件 / 项目操作 · File / Project ops

涉及框架 · Agent framework

不涉及框架 · Not framework-specific(这是宿主桌面的 Git 集成,与 Agent 框架无关)

使用场景 · Use case

我的工作目录下并排放着多个独立的 Git 仓库(典型 polyrepo:微服务集合、插件集合、外挂工具集),例如:

F:\projects\
├─ repo-a\.git
├─ repo-b\.git
└─ repo-c\.git

打开工作区时选择了 F:\projects(或任意包含多个 .git 子目录的父文件夹),但 ZCode 的 Git 集成只对工作区路径本身执行一次 git rev-parse --show-toplevel 来解析仓库根。当父文件夹不是 Git 仓库时:

  • Git 侧边栏整个不可用,提示「工作区不在 Git 仓库中」;
  • 内部嵌套的 repo-a/b/c 不会被自动发现,每个子仓库都必须单独打开一个对话标签页、或反复切换工作区才能使用分支/变更/提交功能。

补充验证(当前版本 3.10.2 Windows 端,反编译 app.asar 确认):

  • Git 后端所有接口(分支、提交、diff、push)均以单个 workspacePath 为参数,repoRoot 由一次 rev-parse --show-toplevel 得到,不存在 repositories 数组;
  • UI 仅在 isGitAvailable && isRepository 时渲染 Git 面板;
  • 无 multi-root / addWorkspaceFolder 支持,无 submodule 或嵌套仓库特判处理。

跨仓库日常(合并主分支、查看所有仓库的分支/变更状态)目前只能串行切仓库,效率低且容易遗漏状态。

建议方案 · Proposal

  1. 自动发现嵌套仓库:打开工作区时(或按需)递归/浅层扫描子目录中的 Git 仓库(检测 .gitgit rev-parse),Git 侧边栏按仓库列表展示,每个仓库独立的分支/变更/提交/远程状态;
  2. 多文件夹工作区:允许单个对话绑定多个文件夹,Git 工具对各根目录分别解析(参考 VS Code multi-root、Claude Code 的 --add-dir 附加目录能力);
  3. 嵌套/子仓库正确归属:嵌套 .git 与 submodule 仓库单独识别,避免被误当作父仓库的一部分;Git 工具对「工作区不在仓库内」但「工作区含仓库」的情况给出选择入口(如 Git 面板引导打开子仓库)。

预期价值 · Expected value

  • 多仓库(polyrepo)团队/个人不再需要「每个仓库开一个对话」,分支、变更、提交状态一处可见;
  • 减少工作区切换与状态遗漏,对齐 VS Code / Claude Code 已有的多仓库工作流体验。

优先级 · Priority

中 · Medium

版本 · Version

ZCode 3.10.2 / Windows 10 22631 x64(桌面端)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the Git backend and Git sidebar paths described in the app.asar investigation, including the workspacePath and repoRoot handling and the isGitAvailable/isRepository rendering gate. Define the repository discovery and multi-folder behavior before implementation; done means independent nested repositories can expose branch, change, commit, and remote status without switching workspaces.

Written by the indexing model from the issue text.

Assessment

Tech stack
git
Domain
desktop, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.