浏览 AI 知识库
git status 怎么看：改代码前先确认工作区变更归属
接手一个已有改动的仓库，第一件事是看清工作区。逐个确认修改归属、生成文件和未跟踪文件，才能避免格式化或回退掉别人的工作。
沿完整工作流推进
前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。
git status 里的 23 个文件，不能默认都属于这次任务
接手项目时 `git status` 有 23 个修改文件。Agent 如果先格式化或恢复，很可能覆盖用户尚未提交的工作；如果全部当成本任务，又无法交付清晰 diff。
- staged/unstaged/untracked 已区分
- 每项变更有归属或未知标签
- 没有执行破坏性恢复命令
先确认这次任务的起点、边界和交付
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 分支 `feature/search`；状态含 4 个 staged、17 个 unstaged 和 2 个 untracked；本次任务只改搜索空状态。 |
| 不能越过的边界 | 只读确认变更归属；不 reset、checkout 或删除；无法判断的文件先不碰。 |
| 要交付的结果 | 变更归属清单与安全起点 |
从“读取规则和分支”走到“限制后续编辑”
| 当前阶段 | 实际处理 |
|---|---|
| 读取规则和分支 | 确认项目贡献规则、当前分支、远端关系和禁止修改区域。 |
| 逐文件看状态 | 区分已暂存、未暂存、未跟踪和忽略文件，查看 diff 与最近提交，不只看文件名。 |
| 标注变更归属 | 将本次需要、用户已有、生成物和未知改动分开；未知项与任务重叠时先停止确认。 |
| 建立安全起点 | 在不覆盖用户改动的前提下选择新分支、补丁、提交或备份，记录恢复方式。 |
| 限制后续编辑 | 每轮修改后重看 diff，确保没有格式化或生成命令带来大范围无关变化。 |
先把用户已有改动、生成物和本次范围分成三张表
| 类别 | 证据 | 处理 |
|---|---|---|
| 用户已有 | git diff 与时间/内容对应任务 | 保留，不重写 |
| 本次范围 | 目标源文件和新增 diff | 只编辑这些文件 |
| 生成物 | 构建后批量变化，能由源文件重建 | 构建后核对，不手工清理 |
| 未知 | 无法确认归属或与任务重叠 | 记录并停止清理 |
归属必须从 diff、规则和任务范围判断，不能按文件名猜。
完成后的变更归属清单与安全起点
归属表把已有支付、导航和草稿文件标为用户工作；本任务只授权搜索组件与测试。修改前后 status 都保存，最终 diff 可单独审查，没有改变 staged 区。
为什么“任务文件本来就有用户改动”还不能交付
任务文件本来就有用户改动
- 原因
- 同一文件存在混合归属
- 怎么改
- 逐块阅读 diff，与用户改动叠加而不覆盖；无法安全区分时停下说明