三个仓库改一个需求，最先该对齐的是分支

「订单列表加导出」这个需求，动了三个仓库：前端加按钮和下载，网关加一条路由，后端加接口和查询。

三个人，三个分支。后端在自己的功能分支上改，前端在主干上改，网关还停在上一个发布分支，因为那周有个线上问题在热修。

三个 IDEA 窗口并排，进度靠群里发消息。消息一多，最容易漏的是那个一直没说话的人。

一个窗口，不等于一个时间点

把三个仓库挂进同一个工作区之后，界面上的麻烦先没了。左边一栏三个项目，谁改了什么，一眼看得见。

有个前提容易被跳过：三个项目进了同一个窗口，各自的 Git 分支还是各管各的。版本管理窗口按仓库分开列，点谁只看谁自己的提交。读代码的时候，读的是三个仓库当前检出的那三份文件。

后端在功能分支上，网关在发布分支上，前端在主干上。一次生成出来的改动，是三个时间点拼起来的。

拼出来的东西通常不报错，只是不对。网关那个老分支上，订单服务的地址前缀还是单数，而主干里后端已经改成了复数。它照着两边各自的实际情况写，配出来能通；等三个分支都合回主干，前缀又对不上。

这类问题评审时看不出来，因为每个仓库的改动单独看都是对的。三个仓库的自动构建也是各跑各的，绿的都绿，合起来才炸。

动手之前，三件跟工具无关的事

一，三个仓库切到同一个基线。要么都从主干拉新分支，要么都从同一个发布点拉，别一个功能分支、一个发布分支。

二，当前分支写进需求里。人知道，也让它在读代码之前先知道。

三，确认版本对得上。前端用的接口类型包，是不是从后端这一版生成的；网关依赖的服务名，改过没有。

三件里最容易省掉的是第二件。人心里清楚自己在哪个分支上，就默认别人也清楚，工具更该清楚。可它读的是文件，不是你的记忆。漏一条，后面全白搭。

三件事做完，工作区才算真的成了「一个项目」。

一次需求，三个仓库一起改

前提齐了，就轮到动手。这里用的是飞算 JavaAI，一个 IDEA 里的 AI 编程插件，主打 Java 这套工程流程：读需求、定接口和表结构、生成代码。它把三个仓库看成同一次改动的三个落点。

省下来的不是切窗口那几下，是那三遍「我说一遍、你改一遍」。 需求写在输入框里，它按项目把改动分开落下去：后端出接口和查询，网关加一条路由，前端加请求和页面。三个仓库各自的改动摆在同一个窗口里，谁的没改完一眼看得出来。

路径和参数只说一次。后端改了名字、前端照旧抄这种事，没有发生的条件。

再往上游是先定接口：先读需求，出表结构和接口定义，再按接口定义做页面。产物落在项目里，是仓库里的文件。三个仓库为什么这么配合，翻那份文档能看明白，不用去翻群聊记录。

模型这块也得分两头看。产品自己那几档按任务切开，赶进度的走快档，啃架构的走深档，底子是针对 Java 调过的开源模型；旁边还开了一栏，接的是外面那几家，智谱、DeepSeek 都在可选范围内。挂后者的人多半不是嫌原来的不行，是不想换一套东西就得重新试一遍手感。

全挂上，还是按需挂

三个仓库都挂上去，机器的账是实打实的。三个都是几万行的项目，第一次打开建索引要好几分钟，之后每切一次分支，索引还得跟着动。

挂得越多不等于越省。工作区支持把手头的项目「卸下」：项目变成灰色，不参与全局搜索和索引，要用的时候再装回来。注意它只是不参与索引，不是删除，文件还在原处。

卸下和移除是两件事。移除是把项目从工作区里拿掉，路径都不在了；卸下只是让它暂时不干活，第二天要改，装回来还在原位。

按需挂更省。只改一个页面，网关不必整天开着索引；只调网关的规则，后端那边也能先放一放。工作区里只剩这次要动的两三个项目，读到的范围也干净。

还有一笔账容易忘：三个仓库的依赖各躺在自己的目录里，索引之外，编译本身也吃内存。真要三个一起构建，先看看机器还剩多少。

它管的是改动落在哪，不管分支怎么合

飞算 JavaAI 这一层不参与分支策略、合并顺序、网关那条路由谁审。项目跑不起来的时候，依赖读不全，改出来的东西也是半截。

还有一件得人定：这三处改动是不是同一个需求的改动。 它能一起改完，但不能替你判断这次该不该顺手把网关的限流也调了。范围是人的事。

那天最费时间的不是改代码，是合完之后把三处的路径对一遍。三个仓库的提交信息各写各的，事后想串起来，只能靠人回忆。

最后合并的顺序是后端、网关、前端。反过来试过一次，前端先合，线上白屏了四分钟。顺序错了，回滚比重合还慢。

三个仓库最后一次停在同一个提交上，是什么时候？