普通视图

发现新文章,点击刷新页面。
昨天以前首页

3 个命令 7 个步骤,学会 git worktree 并行开发

作者 双越AI_club
2026年4月29日 08:43

大家好,我是双越。wangEditor 作者,前百度 滴滴 资深前端工程师,慕课网金牌讲师,PMP,前端面试派 作者。

我正致力于两个项目的开发和升级,感兴趣的可以私信我,加入项目小组。

  • 【划水AI】 Node 全栈 AIGC 知识库,包括 AI 写作、多人协同编辑。复杂业务,真实上线。
  • 【智语】 AI Agent 智能体项目。一个智能面试官,可以优化简历、模拟面试、解答题目等。

开始

你可以一边修复 bug ,同时一边开发新功能,反正两个目录互不影响。

在过去的传统开发模式中,大多数程序员使用 git branch 就已经足够:

  • 开一个功能分支(feature)
  • 开发完成后提交 PR
  • 合并回主分支(main)

这种方式简单直接,在单任务开发场景下非常高效。

但现在情况变了。

随着 AI 编程工具(如 ChatGPT、Claude Code、Copilot)的普及,开发模式正在发生变化:

  • 同时开发多个功能
  • 多个 AI 对话并行执行任务
  • 长时间等待模型响应
  • 需要频繁切换上下文

👉 这时候,传统的 git branch 就开始显得不够用了。

于是,一个很多人没用过的工具开始进入视野:git worktree

很多程序员甚至从没听说过它,但它其实早就内置在 Git 中。

本文将从实战角度,带你彻底理解并掌握它。

Git branch 的不足

我们先看一个真实开发场景:你正在开发功能 A,突然被要求紧急修复 bug1。

传统做法

当前在 feature-a 分支,开发到一半儿了。得先缓存当前代码,再切换到 bugfix-1 分支。

git stash
git checkout -b bugfix-1

或者直接提交当前修改,然后切换到 bugfix-1 分支。

git commit -m "WIP"
git checkout -b bugfix-1

存在的问题

1. 上下文被打断

  • stash 容易忘内容
  • commit 会污染历史

2. 切换成本高

频繁的 stashpop ,容易冲突、出错

git checkout feature-A
git stash pop

3. 无法并行开发

你同一时间只能处理一个分支:

  • 不能一边开发 A,一边修 bug
  • 不能同时跑多个 AI 任务

本质原因

branch 是“逻辑切换”,不是“物理隔离”。

worktree 的价值

👉 它解决的是:让你可以“同时在多个分支开发”,而不是来回切换

worktree 的基本使用

核心概念

  • branch:代码版本线(逻辑)
  • worktree:工作目录(物理)

👉 一个仓库可以有多个 worktree

add 命令

创建一个新的 worktree 并同时创建一个新分支(惯例)

git worktree add ../project-A -b feature-A

PS. 一个分支不能同时在多个 worktree 打开,git 会提示 fatal: 'feature-A' is already checked out at '/Users/xxx/xxx/project-A'

list 命令

列出当前所有的 worktree 目录

git worktree list

remove 命令

删除一个 worktree:

git worktree remove ../project-A

表面现象

你会看到三个同级别的文件夹,其中 /project 就是原始项目的文件夹。看起来像多个独立项目。

/project
/project-A
/project-bugfix

本质

多个目录,共享同一个 Git 仓库 —— 这很重要。

不是执行了三次 git clone 创建的三个独立仓库,不是!

多目录如何实现共享同一个 git 内容

主仓库的 .git 目录,管理着所有 git 数据。这个程序员都知道。

/project/.git/

新建的 worktree 仓库中,有一个 .git 文件。注意,这是一个文件,不是目录。

/project-A/.git

内容类似如下,连接到主仓库的 git 目录中

gitdir: /project/.git/worktrees/project-A

主仓库里多了如下内容,用于绑定 worktree 的状态信息

/project/.git/worktrees/project-A/

这是 git 专门设计的,并不是操作系统的 symlink 软链接。

举例说明(完整流程)

场景

这是一个实际的开发场景:

  • 从 main 开始
  • 开发 A 功能
  • 中途修 bug1
  • bug 合并回 main
  • 继续开发 A
  • A 合并回 main

Step 1:初始化

从 main 分支开始

git checkout main
git pull

Step 2:开始开发 A

新建一个 worktree project-A 同时新建一个 feature-A 分支

git worktree add ../project-A -b feature-A

Step 3:出现 bug

此时你不需要 git stashgit commit

你直接新建一个 worktree ,同时基于 main 分支新建一个 bugfix-1 分支即可。不影响当前分支。

git worktree add ../project-bugfix -b bugfix-1 main

Step 4:修复 bug

在新的 worktree 修复 bug ,提交代码。正常开发流程。

cd ../project-bugfix
git add .
git commit -m "fix: bug1"

Step 5:合并 bug 代码

在任何一个 worktree ,将 bugfix-1 分支的代码合并到 main 分支。或者提交 PR 合并都可以。

cd ../project
git checkout main
git pull
git merge bugfix-1
git push

合并以后,就可以删掉这个 worktree 和分支

git worktree remove ../project-bugfix
git branch -D bugfix-1

Step 6:回到 A 功能

回到 A 功能的 worktree 目录,同步最新的 main 分支代码

cd ../project-A
git fetch
git rebase origin/main

然后继续开发 A 功能的代码。中间如果再有 bug 修复,还是参照上文的步骤。

甚至,你可以一边修复 bug ,同时一边开发 A 功能,反正两个目录互不影响。

Step 7:完成 A 并合并

等待 A 功能开发完了,提交代码,合并到 main 分支。

git add .
git commit -m "feat: A done"

cd ../project
git checkout main
git pull

git merge feature-A
git push

最后删掉 worktree 和分支

git worktree remove ../project-A
git branch -D feature-A

以上就是 git worktree 的基础使用,亲自操作一边,肯定已经学会了。

非 git 管理的文件

以上讨论的都是 git 管理的文件,还有写文件和目录不是 git 管理的,例如 .envnode_modules

注意,这些文件 git 不管理,worktree 当然也就不会管理它们,需要你自己手动处理。

.env

.env 这种单个文件,推荐使用软链接,直接链接到主仓库的原始文件

ln -s ../project/.env ../project-A/.env

node_modules

node_modules 目录的内容太多,而且可能还有版本一致性问题,推荐重复安装。
即新建一个 worktree 之后,在新目录下重新安装。

这里推荐使用 pnpm 安装 pnpm install ,它的优势:

  • 全局缓存
  • 节省空间
  • 安装速度快

最后

学会 worktree,你将获得:

  • 真正的并行开发能力
  • 更好的 AI 编程体验
  • 更清晰的开发上下文隔离

最后,worktree 不是替代 branch,而是让 branch 发挥最大价值。

基于 Cursor Agent 的流水线 AI CR 实践|得物技术

作者 得物技术
2026年4月7日 11:13

一、背景

在实际迭代开发中,不同需求的代码规模差异很大,有些需求涉及上千行代码,有些则只有一两行。且对于前端的代码验收,主要侧重在界面功能,通过功能验收,没法确保每一行代码都测试到的,以及功能的代码逻辑是否合理,是否健壮、是否规范等问题,都需要通过人工代码 CR 来进一步兜底验收代码的质量,尽量降低业务线上出错的可能。但当面对上千行的代码变更时,人工 CR 也是心有余而力不足。

传统的代码审查依赖人工,面对大规模代码变更时效率有限,而 AI 代码审查能够实现自动化、标准化的质量检查,有效补充人工审查的不足。

二、前端研发 CR 现状与可优化点

CR 现状

目前前端研发同学主要使用的代码质量保障工具有前端 Apex 插件智能体、Uraya 质量分检测。其中 Apex 插件智能体是通过前端研发自助点击或 git hook 自动触发 CR 智能体执行,智能体内定制了 CR 规则以及与 MCP 的结合,利用 Cursor IDE 的 Agent 能力进行本地 AI CR ,找出代码问题、本地解决问题。Uraya 质量分检测是在创建 MR 后,通过流水线自动触发,Uraya 质量分检测代码变更的质量分浮动,产出具体问题的记录,引导研发优化代码。

可优化点

  1. 本地触发 CR 需要研发同学主动点击触发或者通过 Apex git hook 执行 CR 智能体,当开发的需求多、分支多、提交次数多的时候,时长容易漏触发、忘记点。
  2. 对于 MR 评审人员,如果希望通过 Cursor CR 时,需要在本地通过调用 CR 智能体再执行一遍,获取 CR 结果,在目前 Cursor 按量计费的背景下,重复执行 CR 智能体的成本需要及时关注。
  3. 当前流水线 Diff + 大模型 API 的 AI CR 方式,误报率较高,研发使用意愿较低。

三、AI CR 方案对比分析

基于以上现状分析,我们对不同 AI CR 方案进行了深入对比。

Cursor Agent CR 主要优势

流水线集成 CR 与本地 AI CR 差异

四、技术方案设计

结合目前现状与可优化点,我们期望能像 Uraya 质量分检测一样,在 MR 过程中通过流水线自动触发,中途每次代码提交也能自动触发,对于流水线中的 CR 不满意时,可以结合 Apex CR 智能体进行本地 CR 调整代码。

为此我们考虑结合 Cursor Agent CLI 在流水线中增加一个 AI CR 的任务,自动触发 Cursor Agent 代码 CR,并记录 CR 结论,及时展示给研发或者代码评审的同学,辅助代码质量优化。

整体链路设计如下:

  1. 当研发创建 MR 后,流水线配置了 AI CR 检测流水线后,将会自动触发 Cursor Agent CR 任务。
  2. 接收到检测任务后,将会前置将该仓库准备好,并将 MR 的信息以及制定的 CR 规则,一并交给 Cursor Agent CLI 执行,待执行完成,会得到一份 CR 报告。
  3. 接收到检测任务完成后,目前会通过 MR 评论的方式添加到对应的 MR 中,引导用户查看。
  4. 对于开发者视角,打开审查报告,可以根据审查出的问题,进行修改。
  5. 对于 CR 人员视角,打开审查报告,可以根据审查出的问题,一键添加到评论,引导开发者修改。

五、MR 流水线接入与 AI CR 报告

自动触发

以下图 MR 为例,在 MR 流水线中,添加了仓库流水线 AI 检测的检测任务,当创建 MR 时,会自动触发执行一次,在 MR 未合入的过程中,每次代码变更也会自动触发。

添加审查报告评论

检测完成后会自动添加一条 MR 评论,通知研发已完成检测,可以点击查看 CR 报告。评论概览中有审查摘要,显示聚类问题的数量;还有审查总结,即对所有反馈的总结,概览问题。

AI CR 报告

以下为实际 MR 生成的 CR 报告,可以看到,报告主要包括:MR 的基础信息、问题的分类 Tab、问题的具体描述、问题的操作。

具体问题列表

首先报告列表会对问题进行聚类,分为严重问题、警告、建议三类,切换对应 Tab 可以看到问题列表。具体的问题信息,主要有类型、问题代码、修复后代码、描述、文件路径、行号、操作等列。

添加到评论

点击操作列的添加到评论,将会一键将相关问题的信息,生成格式化描述,添加到 MR 的评论中,提醒开发者关注问题、解决问题。

AI 智能解决

点击操作列的 Cursor 解决,将会一键将相关问题的信息,生成解决问题 Prompt,一键打开本地 Cursor ,创建 Agent 对话去解决问题。打开链接后,Cursor 会先接收 Prompt ,你可以简单浏览下,点击 Create Chat ,即可一键创建 Chat,回车执行修复。

Cursor Prompt 预览

Cursor Prompt 预览 确认填入 Chat 执行

复制 Prompt

点击复制 Prompt,支持一键复制修复问题 Prompt,可以放到期望的 IDE 里使用。如下图,就是复制的 Prompt 示例。

六、推荐研发流程实践

尽早创建 MR

当需求分支第一次提交后,就可以创建到 release 或 test 目标分支的 MR 了,后续每次提交代码都将会自动触发检测,产出 AI CR 报告。

研发自主查看与解决

研发收到 AI CR 报告的通知后,可以及时打开 CR 报告查看,确认反馈的疑问点是否需要调整,如果需要调整可以通过 Cursor 一键解决,将问题解决前置到提测以前,这样所有的改动可以尽可能的被测试同学验证到。

人工 CR

发布前最后的人工 CR 可以通过前置的 AI CR 发现与问题前置解决,大幅提升靠最后人工 CR 的反馈、修改等环节效率。特别是当业务需求代码量较大时,人工 CR 浏览的效率和质量也是无法保证的。

七、内置提示词工程

AI CR 其实就像给 AI 一个详细的检查清单。这个清单分两部分:一部分是基本规则,比如"你要扮演什么样的角色"、"按什么流程检查";另一部分是具体的技术要点,比如"注意空指针问题"、"检查React用法是否正确"等。有了这个清单,AI 就能像有经验的程序员一样,系统地检查代码,发现各种潜在问题,让代码质量得到保障。

具体这个规则体系的结构如下:

.cursor/rules
├── 00-role-and-constraints.mdc          # 角色与约束 - 定义AI代码审查助手的角色和基本约束条件
├── 01-workflow-steps.mdc                # 工作流程步骤 - 描述代码审查的工作流程和步骤
├── 02-detection-standards.mdc           # 检测标准 - 定义代码问题的检测标准和准则
├── 03-output-format.mdc                 # 输出格式 - 规定代码审查结果的输出格式和规范
├── 04-best-practices.mdc                # 最佳实践 - 提供代码审查中的最佳实践建议
├── common                               # 通用规则目录 - 包含各种常见的代码问题检测规则
│   ├── 01-null-pointer-defense.md       # 空指针防御 - 防止空指针异常的最佳实践
│   ├── 02-react-hooks-usage.md          # React Hooks 使用 - React Hooks 的正确使用方式
│   ├── 03-data-merge-state.md           # 数据合并状态 - 处理数据合并时的状态管理问题
│   ├── 04-async-programming.md          # 异步编程 - 异步编程模式和常见陷阱
│   ├── 05-memory-leak-performance.md    # 内存泄漏性能 - 检测和防止内存泄漏问题
│   ├── 06-security-coding.md            # 安全编码 - 安全编程实践和漏洞防范
│   ├── 07-compatibility.md              # 兼容性 - 确保代码兼容性的检查点
│   ├── 08-git-conflict-detection.md     # Git 冲突检测 - 检测并解决 Git 合并冲突
│   ├── 09-code-quality.md               # 代码质量 - 代码质量评估和改进规则
│   ├── 10-resource-handling.md          # 资源处理 - 正确处理系统资源的规则
│   ├── 11-url-params.md                 # URL 参数 - URL 参数处理的安全和有效性检查
│   ├── 12-business-logic-consistency.md # 业务逻辑一致性 - 确保业务逻辑一致性的规则
│   └── 13-monorepo-dependency.md        # 大仓依赖 - Monorepo 架构中的依赖管理规则
└── README.md                            # 说明文档 - 规则系统的介绍和使用说明

八、模型选择

在 AI CR 环节,模型的选择需要考虑模型对于代码理解的复杂性、上下文长度需求以及推理准确性、模型的速度、模型的使用成本等考量。在 Cursor 的模型列表中,我们优先使用 Compose 1.5,当额度不足时,我们也会降级使用 Auto 模型。

以下为 Cursor auto 模型与 Composer 1.5 模型对比,可以看出,两个模型都找出了 4 个问题,但在时间上,Composer 1.5 进行需 44 秒即可完成,而 auto 模型需要 91 秒。

九、总结与规划

通过多个迭代实践与数据统计,Cursor Agent CR 挖掘的有效问题数可以达到 50% 左右,研发使用的意愿也相比原来有不少提升。当前我们也在将 AI CR 报告融合到 Cursor IDE 插件中,进一步融合到研发流程里。

随着 AI 生成代码在开发流程中越来越普遍,AI CR 的重要性将进一步凸显。相比传统的人工审查,AI 审查能够自动发现 AI 生成代码中可能存在的逻辑错误、安全性问题和规范性缺陷,提前在开发过程中消除隐患。同时,AI CR 还能确保 AI 生成的代码符合团队的技术规范和最佳实践,保持代码风格的一致性。为 AI 时代的开发流程提供了可靠的质保机制,让开发流程更加顺畅,是现代软件开发的重要保障。

往期回顾

1.从IDE到Terminal:适合后端宝宝体质的Claude Code工作流|得物技术

2.AI编程能力边界探索:基于 Claude Code 的 Spec Coding 项目实战|得物技术

3.搜索 C++ 引擎回归能力建设:从自测到工程化准出|得物技术

4.得物社区搜推公式融合调参框架-加乘树3.0实战

5.深入剖析Spark UI界面:参数与界面详解|得物技术

文 /大圣

关注得物技术,每周更新技术干货

要是觉得文章对你有帮助的话,欢迎评论转发点赞~

未经得物技术许可严禁转载,否则依法追究法律责任。

我做了一个鼾声记录App,聊聊背后的功能设计

作者 Flutter笔记
2026年3月27日 10:47

最近做了一款叫「睡眠声音日记」的App,主要用来记录睡眠时的鼾声和梦话。

今天主要聊聊这个App的功能设计思路。

为什么做这个App?

起因很简单:我自己打鼾,但完全不知道每晚打多少、什么时候最严重。 市面上的睡眠App大多侧重睡眠阶段分析,对鼾声的处理比较粗糙。我想做一个真正能听清楚每一段鼾声的工具。

核心:ML鼾声识别

App用CoreML跑了一个本地训练的声音分类模型,实时区分鼾声和人声(梦话)。每检测到一段就自动裁剪保存音频片段,第二天可以逐段回听。

不依赖网络,所有识别都在本地完成,隐私上比较放心。

灵敏度做了三档可调,适配不同噪音环境。

睡眠评分:5个维度

单纯告诉用户"你昨晚打了12次鼾"其实没什么指导意义,所以我做了一套100分制的评分系统,拆成5个维度:睡眠时长、鼾声/呼吸、深睡质量、睡眠连续性、身体恢复。每个维度单独打分,用户一眼就能看出问题出在哪。

AI个性化分析

接入了大模型做每日分析。不是泛泛的建议,而是把用户昨晚的实际数据(鼾声次数、时段分布、评分、HealthKit数据)传进去,生成针对性的建议。

历史页面还有基于多晚数据的趋势分析,能发现长期规律。如果鼾声连续多晚偏重,会主动建议用户去做专业评估。

趋势可视化

做了7晚和30晚两个维度的趋势图表:鼾声趋势、评分趋势、心率趋势、血氧趋势、睡眠时长柱状图。

还有一个昼夜节律分析,记录满5晚后自动解锁,分析用户的时型(早起型/夜猫子)。

这些图表对于观察干预效果很有用——比如换了枕头之后鼾声是不是真的少了。

Apple Watch用户体验拉满

如果你有Apple Watch,体验会更完整:

  • 手表上能看录音状态,直接停止记录
  • 昨晚的评分、鼾声、时长一目了然
  • 详情页有睡眠阶段时间线(核心/深睡/REM),鼾声事件直接叠在上面,一眼看出"你在深睡的时候鼾声最重"
  • 心率、血氧趋势图也有

小组件 + 灵动岛

桌面小组件做了3个尺寸,核心交互是一键开始/停止记录。大号组件额外展示鼾声时间分布图。录音期间支持灵动岛实时活动,锁屏上也能看到计时和事件计数。

其他细节

  • iCloud多设备同步
  • 数据备份恢复,支持导出
  • 音频自动清理(3/7/14/30天),重要片段可钉住跳过清理
  • 睡眠目标 + 睡前提醒
  • 成就系统,增加使用粘性
  • 一键生成分享图片,方便发给医生或朋友
  • iPad侧边栏适配

订阅模式

月订阅6元,年订阅38元,终身买断68元。

欢迎试用,有反馈随时评论区交流~

❌
❌