---
title: 工作区隔离
description: "基于 Git worktree 的隔离机制，让并行实验互不冲突"
---

工作区隔离是 Verdent 用于确保并行工作互不干扰的系统。每个工作区都是一个完全独立的工作环境，利用 git worktree 在文件系统层面实现隔离。

---

## 你将学到什么

- 工作区隔离如何防止冲突
- git worktree 如何实现隔离
- Base Workspace 与 Workspaces 的区别
- 创建、切换和管理工作区
- 工作区管理的最佳实践

---

## 什么是工作区隔离？

工作区隔离确保来自一个任务的更改永远不会影响另一个任务。你可以并行尝试不同方案、对比结果，并选择性地只将你想要的更改 rebase 回主分支。

### 工作原理

| 层级 | 工作方式 |
|-------|--------------|
| **目录** | 每个工作区都是一个独立的目录 |
| **分支** | 每个工作区都有自己的分支检出 |
| **文件** | 一个工作区中的文件更改不会影响其他工作区 |
| **暂存区** | 每个工作区都有自己的暂存区 |

### 优势

<CardGroup cols={2}>
  <Card title="零干扰" icon="shield-halved">
    并行的智能体无法相互冲突，物理上不可能
  </Card>
  <Card title="安全实验" icon="flask">
    尝试有风险的更改而不影响稳定代码
  </Card>
  <Card title="清晰对比" icon="code-compare">
    使用 git diff 跨工作区对比不同方案
  </Card>
  <Card title="选择性 Rebase" icon="code-merge">
    只 rebase 你信任的结果
  </Card>
</CardGroup>

---

## Base Workspace 与 Workspaces

### Base Workspace

Base 工作区是你原始的仓库检出，作为默认的起点。

| 特征 | 描述 |
|----------------|-------------|
| **位置** | 你原始的 git clone 或 init 位置 |
| **主分支** | 通常位于 main 或 development 分支 |
| **参照点** | 用于对比实验性工作的来源 |

**何时使用 Base：**
- 不需要隔离的快速更改
- 对比实验性工作的参照点
- 当你希望更改直接进入主分支时
- 不需要并行执行的简单任务

### Workspace

Workspace 是使用 git worktree 创建的独立工作环境，拥有自己独立的分支检出和文件状态。

**何时使用 Workspace：**
- 并行的功能开发
- 实验有风险的更改
- 同时处理多个任务
- 当你想在 rebase 之前进行隔离时

---

## 创建和管理工作区

### 创建新工作区

| 平台 | 快捷键 |
|----------|----------|
| **macOS** | `Cmd+Shift+N` |
| **Windows** | `Ctrl+Shift+N` |

**会发生什么：**
1. Verdent 创建一个独立的 git worktree 目录
2. 创建一个新分支（或检出已有分支）
3. 该工作区与其他工作区完全隔离
4. 工作区出现在顶部栏的 **All Workspaces** 中

### 在工作区之间切换

| 操作 | macOS | Windows |
|--------|-------|---------------|
| **下一个工作区** | `Ctrl+Tab` | `Ctrl+Tab` |
| **上一个工作区** | `Ctrl+Shift+Tab` | `Ctrl+Shift+Tab` |
| **选择工作区** | 点击顶部栏的 **All Workspaces** | 点击顶部栏的 **All Workspaces** |

**状态保留：**
- Verdent 会保持所有工作区状态处于活动状态
- 即时切换，无需重新设置等待
- 切换时完整保留上下文

---

## Rebase 工作区更改

当你准备将工作区更改整合回主分支时：

### 使用 Verdent 界面

<Steps>
  <Step title="完成工作">
    在工作区中完成工作
  </Step>
  <Step title="审查更改">
    点击中间面板的 **Task Changes** 以审查所有修改
  </Step>
  <Step title="Rebase 到主分支">
    在 Workspace Bar 中点击 **Workspace Actions → Rebase to main branch**
  </Step>
  <Step title="解决冲突">
    如有提示，解决所有冲突
  </Step>
  <Step title="验证">
    在确认前审查更改
  </Step>
</Steps>

### 保持工作区更新

使用 **Workspace Actions → Sync with main branch** 将主分支的最新更改拉取到你的工作区。这有助于在 rebase 时避免大量冲突。

---

## 最佳实践

### 命名约定

| 实践 | 示例 |
|----------|---------|
| 描述性名称 | `feature-auth`、`bugfix-123`、`experiment-caching` |
| 包含工单编号 | `JIRA-456-user-login` |
| 保持名称简短 | 避免过长的名称 |

### 工作区维护

| 实践 | 原因 |
|----------|-----|
| **删除已 rebase 的工作区** | 释放磁盘空间 |
| **移除已放弃的实验** | 保持工作区列表可管理 |
| **保持工作区数量合理** | 系统资源是有限的 |

### Git 卫生

| 实践 | 原因 |
|----------|-----|
| **频繁提交** | 在切换前提交进行中的工作 |
| **小颗粒提交** | 较小的提交更容易 cherry-pick |
| **定期与 base 同步** | 不要让工作区与主分支偏离太远 |
| **降低冲突复杂度** | 定期整合可防止大量冲突 |

---

## 常见问题

<AccordionGroup>
<Accordion title="每个工作区占用多少磁盘空间？">
每个工作区会复制工作文件，但共享 `.git` 目录。每个工作区的空间占用大致等于你的项目大小。具有许多并行工作区的大型项目将占用大量磁盘空间。
</Accordion>

<Accordion title="我可以删除工作区吗？">
可以。通过 Verdent 删除工作区。这会移除目录，但会保留该分支上已提交的工作。
</Accordion>

<Accordion title="如果删除工作区，未提交的更改会怎样？">
删除工作区时，未提交的更改会丢失。在移除工作区前，请务必提交或 stash 你的更改。
</Accordion>

<Accordion title="我可以将工作区转换为 base 工作区吗？">
没有直接的转换方式，但你可以将工作区的所有更改 rebase 到主分支，然后删除该工作区。分支历史会被保留。
</Accordion>

<Accordion title="worktree 能与所有 git 托管服务配合使用吗？">
可以。Git worktree 是标准的 git 功能。它们可与 GitHub、GitLab、Bitbucket 以及任何其他 git 托管服务配合使用。
</Accordion>
</AccordionGroup>