跨机同步方案：Git主干+增量镜像打造一致开发环境

1. 三台机器的混乱日常：这个同步方案到底在解决什么问题

先说一个我自己的真实场景：办公室一台台式机，家里一台主力开发机，出差还带着一台轻便笔记本。以前没做跨机同步的时候，项目代码基本靠U盘拷贝加聊天软件文件传输顶着，经常出现一种很魔幻的状态——周一到周三改的代码在办公室电脑上，周四在家继续写只能凭记忆把改动重新敲一遍，出差的时候干脆就是看别人的旧代码。更麻烦的是，同一份项目在每台机器上都有自己的配置、缓存和临时文件，时间一长，三台机器上的"同一项目"已经悄悄变成了三个不兼容的分支。

这次要聊的"整体设计定稿之35项目跨机同步方案之2"，就是专门解决这个问题的方案设计文档。文档编号20260207，定稿时间在二月初。方案1踩了不少坑，这次是彻底复盘之后的修订版。整个方案的核心思路是用 codebuddy 作为项目开发主工具，把多台机器的项目文件、配置、AI助手的工作状态统一到一个可同步的架构里，真正做到"在哪台机器上打开都是同一个项目"。

1.1 同一天出现三个版本的代码

我统计过自己一周的工作流变化：早上在办公室台式机写核心模块，下午带着笔记本去会议室联调，晚上回家在主力机上想继续改同一个接口。如果没有同步机制，每一次换机器都是一次手工合并，这个合并的代价根本不是几分钟，而是"忘改一个地方"带来的连锁问题。

有一次我印象特别深，在笔记本上修了一个接口的返回字段，忘记同步到台式机。第二天在台式机上跑测试，怎么跑怎么不对。排查了半天，最后发现是两台机器的代码根本不一样，联调阶段暴露出来的问题其实在昨天就已经修掉了——代码却停在旧版本上。这种情况只要出现过两次，你就一定会认真考虑跨机同步这件事。

跨机同步要解决的痛点，首先不是"如何把文件复制过去"，而是"如何保证多台机器之间的工作状态一致"。所谓工作状态，包括代码文件本身，也包括依赖配置、环境变量、本地构建产物，还有开发工具的运行记忆。

1.2 不只是代码：环境配置和AI助手的记忆也要跟得上

很多人第一反应是"代码同步用Git不就完了"。Git确实解决了版本管理的问题，但跨机同步比这要复杂得多。项目里有一堆不该进仓库的东西，却必须在多台机器之间保持一致，比如：

• 本地配置文件，像 .env、.codebuddy 这类工具的私有配置，里面有不同机器的差异化信息，又不能随便丢。
• AI编程助手的会话上下文、索引缓存、用户自定义指令，这些数据在换机器之后如果丢了，等于让AI助手失忆。
• 构建工具产生的本地依赖目录，比如 node_modules、vendor，虽然可以重新安装，但在没有网络或者网络很慢的环境下重新拉取一遍代价很大。
• 数据库的本地副本、缓存目录、甚至IDE的窗口布局和工作区列表。

这些内容单独看都不大，但它们共同构成了"我在这台机器上正常工作"的环境。跨机同步方案要做的，就是把这些状态按优先级和敏感度分级，用不同的同步策略去处理，而不是简单地用网盘同步整个文件夹。

1.3 方案1失败之后，方案2的基本盘

方案1当初的想法很天真：直接用一个同步工具把整个项目目录做双向实时同步，碰到冲突靠"后来者覆盖"。结果实战中问题一堆，最典型的是构建工具在后台写文件时触发了同步风暴，还有两台机器同时改同一个文件导致版本互相覆盖。

方案2从根上换了一套思路：先明确数据分区的边界，再决定每一类数据用什么方式同步，最后才谈工具选型。 不是"我要同步"，而是"什么东西值得同步、什么东西不需要同步、什么东西必须串行修改"。这套思路确立之后，后面的技术选型和工作流设计都变得清爽很多。

2. 选型复盘：为什么最终是"Git主干+增量镜像"的组合架构

跨机同步方案的选型，市面上常见的选择其实就那么几类：网盘同步、自建NAS、版本库拉取、增量文件镜像。每一类我都实际用过一段