1. 为什么多机共用一个账号这件事值得认真对待先说结论多台机器共用一个 WorkBuddy 账号本质上不是登录问题而是状态同步问题。很多人第一次遇到这个需求脑子里冒出来的第一个念头是我直接在两台机器上分别登录不就行了结果用不了几天就会发现A 机器上聊到一半的上下文B 机器上完全接不上A 机器改过的项目配置B 机器打开还是旧的更麻烦的是两边同时写最后谁覆盖了谁都不知道。我自己是同时在台式机、笔记本和一台常驻的 Linux 小主机上用 WorkBuddy 的。台式机写代码笔记本开会和外出时用Linux 那台跑一些长任务。一开始我也是各登各的后来发现记忆完全割裂等于每次换机器都要重新交代一遍背景效率反而比单机低。于是我开始认真研究跨机双写同步这件事中间踩了不少坑也试过好几种方案最后落到一套以git 裸仓 commit-aware 同步为核心的组合拳上。这篇文章适合三类人看第一类是多设备重度用户想让 WorkBuddy 的会话记忆、项目配置、技能文件在不同机器之间保持一致第二类是对 git 有一定了解、想把它当成状态同步总线来用的开发者第三类是单纯好奇双写同步到底难在哪、为什么不能简单粗暴地双向覆盖的人。我会把原理、选型理由、具体操作步骤、以及我实际踩过的坑都摊开讲尽量让你看完就能照着搭一套。需要提前说明的是WorkBuddy 本身的工作目录、缓存目录、技能目录在不同系统上位置不一样Windows、macOS、Linux 三套路径差异很大这也是后面同步方案要重点处理的地方。另外账号层面的记忆和本地文件层面的状态是两回事前者依赖服务端后者才是我们能通过 git 掌控的部分这个边界一定要先分清楚否则后面会做很多无用功。2. 双写同步到底难在哪三个绕不开的核心矛盾2.1 冲突不是会不会发生而是什么时候发生单机使用的时候文件写入是串行的你改完这个再改那个天然没有冲突。一旦变成两台机器同时写同一个逻辑状态冲突就从边缘情况变成了常态。举个很具体的例子你在台式机上让 WorkBuddy 更新了某个项目的技能配置同时笔记本上因为打开了旧版本退出时把旧配置又写回去了。等你回到台式机发现刚改的东西没了。这就是典型的后写覆盖先写。git 能帮你发现冲突但前提是你得让它有机会发现——如果你用的是简单的文件同步工具它很可能直接按时间戳覆盖连冲突提示都不给你。所以双写同步的第一个核心矛盾就是如何让冲突可见而不是被静默吞掉。2.2 缓存目录和技能目录的路径漂移WorkBuddy 在不同系统上的目录结构差异是第二个大坑。Windows 上通常在用户目录下的 AppData 里macOS 在 Library 下Linux 在 .config 或 .local 下。你如果直接把整个目录原样同步过去路径里带着用户名、带着系统特定的分隔符到了另一台机器上要么找不到要么被当成新目录重新创建。我一开始就是吃了这个亏把 Windows 上的配置目录整个复制到 Linux结果 WorkBuddy 在 Linux 上根本读不到因为它找的是另一个路径。后来我才明白同步的应该是内容而不是路径。也就是说你需要一个中间层把不同系统上的真实路径映射到同一个逻辑仓库里让 git 管理的是逻辑内容而不是物理位置。2.3 commit-aware 到底aware的是什么热词里出现了 commit-aware这个词听起来很玄其实拆开就懂了它指的是同步逻辑要感知每一次提交的语义而不是无脑地拉取和推送。普通同步是我这边有新东西就推上去你那边有新的就拉下来commit-aware 则更进一步——它会判断这次提交改的是哪一类内容是会话记忆、是技能文件、还是项目配置然后决定要不要合并、怎么合并、要不要触发重新加载。为什么这个区分重要因为不同类内容的合并策略完全不同。会话记忆是追加型的冲突了可以两边都保留技能文件是覆盖型的冲突了必须人工选一个项目配置介于两者之间有些字段可以合并有些必须二选一。如果你用同一套策略处理所有内容迟早会出问题。commit-aware 的价值就在于按内容类型分流处理这也是我最终选择 git 而不是普通网盘同步的根本原因。3. 方案选型为什么最后落到 git 裸仓3.1 试过的几种方案和它们的死穴在定下 git 裸仓之前我认真试过三种方案每一种都用了至少一周这里把结论直接给你省得你重复踩。方案优点死穴适用场景网盘同步目录配置简单跨平台静默覆盖无冲突提示缓存文件乱传只读型资料备份手动打包复制完全可控全靠人肉容易漏无法追溯极低频迁移单机 git 仓库 远程有版本历史双写时冲突处理麻烦路径问题依旧单人单机为主git 裸仓 工作区映射冲突可见历史完整可脚本化初次搭建有门槛多机双写同步网盘方案死得最快。它最大的问题是不告诉你发生了什么。两台机器同时改它按修改时间挑一个赢家另一个直接没了你连曾经有过冲突都不知道。对于会话记忆这种追加型内容这等于随机丢数据。手动打包的问题在于不可持续。偶尔迁移一次还行天天用就是折磨自己而且一旦忘了打包某个隐藏目录排查起来极其痛苦。单机 git 仓库比前两个好但它的工作区就是真实目录双写的时候两边都在改同一个工作区git 的索引状态会互相干扰尤其是你在 A 机器上还没提交B 机器就推了新东西拉取的时候各种报错。3.2 裸仓方案的核心思路裸仓bare repository的关键特性是它没有工作区只存 git 对象和引用。这意味着它天然适合当中转站每台机器各自维护自己的工作区通过推拉到裸仓来交换状态。裸仓本身不会被任何一台机器的工作区状态污染冲突也只在推拉的时候暴露清晰可控。我的整体架构是这样的在一台常驻的机器我用的就是那台 Linux 小主机上建一个裸仓作为同步中心。台式机和笔记本各自把 WorkBuddy 的相关目录映射成一个 git 工作区平时正常用需要同步的时候执行推拉脚本。裸仓不参与任何实际运行只负责存历史、暴露冲突。提示裸仓所在机器最好是一直在线的否则你推拉的时候连不上体验会很差。如果实在没有常驻机器也可以用一个私有远程仓库代替原理完全一样。3.3 为什么不用现成的同步工具有人会问市面上不是有专门的目录同步工具吗为什么要自己搭 git我的理由是同步工具解决的是文件一致我要解决的是状态可追溯 冲突可处理。git 给我的不只是同步还有完整的提交历史、清晰的分支模型、以及成熟的冲突解决机制。当我某次同步出问题的时候我能精确地看到是哪次提交、改了哪个文件、和哪次提交冲突这是普通同步工具给不了的。而且 git 的钩子和脚本能力让我可以把 commit-aware 的逻辑做进去——比如提交前自动检查改的是哪类文件提交信息里带上机器标识推送后自动触发另一端的拉取。这些用同步工具做起来非常别扭。4. 从零搭建裸仓、工作区映射与首次同步4.1 在常驻机器上初始化裸仓假设你的常驻机器是 Linux用户名是 sync你想把裸仓放在/srv/workbuddy-sync.git。操作如下# 在常驻机器上执行 mkdir -p /srv/workbuddy-sync.git cd /srv/workbuddy-sync.git git init --bare--bare这个参数是关键它告诉 git 这是一个没有工作区的仓库。初始化完之后这个目录里会有HEAD、config、objects、refs这些东西但不会有任何实际文件。这就是我们要的中转站。接下来建议把默认分支设成 main避免不同机器上默认分支名不一致导致的混乱cd /srv/workbuddy-sync.git git symbolic-ref HEAD refs/heads/main这一步很多人会忽略结果一台机器默认 master另一台默认 main推拉的时候各种对不上。提前统一省心。4.2 在每台机器上建立工作区映射这是整个方案里最需要动脑子的部分。你不能直接把 WorkBuddy 的真实目录变成 git 工作区因为那里面有很多不该同步的东西比如临时缓存、日志、锁文件。正确做法是建一个独立的同步工作区用软链接或者脚本把需要同步的内容映射进去。以 Linux 为例假设 WorkBuddy 的技能目录在~/.config/workbuddy/skills会话记忆在~/.local/share/workbuddy/memory。我建一个~/workbuddy-sync作为 git 工作区结构如下~/workbuddy-sync/ ├── skills/ # 映射到真实技能目录 ├── memory/ # 映射到真实记忆目录 ├── config/ # 映射到真实配置目录 └── .gitignore然后用软链接把真实目录指过来ln -s ~/.config/workbuddy/skills ~/workbuddy-sync/skills ln -s ~/.local/share/workbuddy/memory ~/workbuddy-sync/memoryWindows 上软链接需要管理员权限可以用mklink /D或者干脆用同步脚本在推拉前后复制文件。我两种都用过软链接更省事但 Windows 上偶尔会因为权限问题失败所以我在 Windows 机器上用的是脚本复制方案后面会讲。.gitignore一定要认真写把缓存、日志、锁文件、临时文件都排除掉*.log *.tmp *.lock cache/ tmp/ *.pid注意如果你不小心把缓存目录提交进去了第一次推送可能会非常大而且每次运行都会产生大量无意义变更。宁可一开始多花十分钟写 gitignore也不要事后清理。4.3 首次提交与推送工作区建好之后在每台机器上分别初始化并关联裸仓cd ~/workbuddy-sync git init git remote add origin ssh://sync常驻机器IP/srv/workbuddy-sync.git git add . git commit -m init: 台式机首次同步 git push -u origin main第一台机器推完之后第二台机器不要直接git init然后推而是先克隆git clone ssh://sync常驻机器IP/srv/workbuddy-sync.git ~/workbuddy-sync克隆下来之后再把软链接建好。这样第二台机器就天然和第一台对齐了不会出现两个互不相关的历史。这里有个细节克隆下来的目录里软链接会变成普通文件或空目录因为 git 默认不跟踪软链接指向的内容。所以克隆完必须重新建软链接这一步不能忘。我建议把建软链接的操作写成一个setup.sh每台新机器跑一次就行。5. commit-aware 同步脚本让每次推拉都知道自己在干什么5.1 提交信息里带上机器标识和内容类型commit-aware 的第一步是让每次提交都能被识别。我在每台机器上设了不同的 git 用户名提交信息也按固定格式写[机器名][内容类型] 简短描述比如[desktop][skills] 更新代码审查技能或者[laptop][memory] 追加项目背景记忆。这样在裸仓的提交历史里一眼就能看出哪台机器、改了哪类内容。为什么这个格式重要因为后面做自动合并的时候脚本要靠它来判断策略。比如看到[memory]就知道是追加型内容冲突了可以两边都留看到[skills]就知道是覆盖型冲突了必须人工介入。5.2 推拉脚本的完整逻辑我写了一个sync.sh放在每台机器的~/workbuddy-sync下核心逻辑分四步先拉、再检查冲突、再提交本地变更、最后推。#!/bin/bash set -e cd ~/workbuddy-sync # 1. 先拉取远端最新 git fetch origin main # 2. 检查是否有远端更新 LOCAL$(git rev-parse main) REMOTE$(git rev-parse origin/main) if [ $LOCAL ! $REMOTE ]; then echo 检测到远端有更新尝试合并... git merge origin/main --no-edit || { echo 合并冲突请手动处理 exit 1 } fi # 3. 提交本地变更 if [ -n $(git status --porcelain) ]; then git add . git commit -m [$(hostname)][auto] $(date %Y-%m-%d %H:%M) fi # 4. 推送 git push origin main这个脚本看起来简单但每一步都有讲究。先拉后推是必须的否则你推的时候会被拒绝。合并失败就退出也很重要不要强行继续否则会把冲突状态搞得更乱。5.3 按内容类型分流处理冲突真正体现 commit-aware 的地方是在合并冲突的时候。默认的 git 合并是逐行比对对会话记忆这种追加型内容很不友好——两边都追加了新内容git 会认为冲突但其实完全可以都保留。我的做法是在脚本里加一层判断如果冲突文件在memory/目录下就用git merge -X ours或者手动拼接的方式把两边的内容都保留如果在skills/下就停下来让人工处理。# 简化版的分流逻辑 if git diff --name-only --diff-filterU | grep -q ^memory/; then echo 记忆目录冲突采用两边保留策略 # 这里可以用自定义脚本把两边内容拼接 fi说实话这个分流逻辑我调了好几版才稳定。一开始想全自动结果发现技能文件的冲突自动合并经常出错最后还是老老实实让技能文件走人工。记忆可以自动技能必须人工这是我踩坑之后总结的铁律。6. 实测踩过的坑从 ssh 认证失败到缓存目录乱入6.1 ssh 认证失败最常见也最容易排查第一次搭的时候我在笔记本上推代码直接报Permission denied (publickey)。这个错误的排查链路其实很清晰我按顺序列一下你照着走基本都能解决。第一步确认本地有没有密钥。ls ~/.ssh/看看有没有id_rsa或id_ed25519。没有就生成一个ssh-keygen -t ed25519 -C 你的标识。第二步确认公钥有没有加到常驻机器的~/.ssh/authorized_keys里。这一步最容易被跳过很多人以为生成了密钥就完事了其实公钥必须放到目标机器上。第三步确认权限。~/.ssh必须是 700authorized_keys必须是 600。权限不对ssh 会直接拒绝而且报错信息很含糊容易让人以为是密钥问题。第四步用ssh -v看详细日志。这个命令会打印整个握手过程哪一步失败一目了然。我遇到过一次是常驻机器的 sshd 配置里禁用了公钥认证日志里写得很清楚改配置重启就好了。提示如果你在 Windows 上用 gitssh 的密钥路径可能和系统自带的不一样。git for windows 默认用~/.ssh但如果你装了其他 ssh 客户端可能会冲突。用ssh -T测试一下连的是哪个。6.2 缓存目录乱入导致仓库爆炸这个坑我印象很深。有一次同步完发现裸仓体积从几 MB 涨到了几百 MB。查了半天发现是 WorkBuddy 的某个缓存目录被软链接带进来了里面全是二进制缓存文件每次运行都变每次提交都产生巨大 diff。解决办法有两个一是把缓存目录从软链接里排除二是在.gitignore里加规则。我两个都做了。软链接只链需要同步的内容缓存目录坚决不链这是原则。如果你已经不小心提交了大文件清理起来比较麻烦需要用git filter-repo或者BFG来重写历史。我建议直接重建仓库把该排除的排除掉比清理历史省事。6.3 换账号后记忆丢失的问题热词里有个workbuddy 换账号如何获得原来账号的记忆这个问题我也遇到过。需要明确一点账号层面的记忆在服务端本地 git 同步的是文件层面的状态。如果你换了账号服务端的记忆是拿不回来的但如果你之前把本地的记忆文件同步到了 git 仓库那部分内容还在。所以我的建议是重要的项目背景、技能配置尽量落到本地文件层面并且纳入 git 同步。这样即使账号出问题你的核心资产还在自己手里。这也是我坚持用 git 而不是纯依赖服务端的根本原因。6.4 路径漂移导致的找不到文件前面提过路径问题这里给一个具体的排查方法。当 WorkBuddy 在某台机器上读不到同步过来的配置时先确认三件事真实目录路径对不对、软链接有没有断、文件权限对不对。# 检查软链接是否有效 ls -la ~/workbuddy-sync/skills # 如果显示红色或者指向不存在的路径说明链接断了软链接断掉最常见的原因是真实目录被移动或重命名了。重新建一下链接就行。另外从 Windows 同步到 Linux 的时候文件权限可能会变成 777 或者丢失执行位如果 WorkBuddy 对权限有要求需要手动修一下。7. 让同步更省心的几个进阶技巧7.1 用 git hook 自动触发同步每次手动跑sync.sh容易忘。我的做法是在 WorkBuddy 的启动脚本里加一行启动前先跑一次同步。这样每次打开 WorkBuddy状态都是最新的。如果你用的是 Linux 的 systemd 或者 macOS 的 launchd也可以配一个定时任务每隔一段时间自动同步一次。但要注意自动同步不能太频繁否则会产生大量无意义的提交。我设的是每 30 分钟一次加上启动时一次基本够用。7.2 分支策略主分支只读工作分支各自写为了避免双写冲突我后来改成了分支策略裸仓的 main 分支只接受合并每台机器在自己的分支上写定期合并到 main。main - 只接受合并保持稳定 ├── desktop - 台式机的工作分支 ├── laptop - 笔记本的工作分支 └── linux - 常驻机的工作分支这样每台机器的提交历史是独立的合并的时候冲突范围也小。代价是操作稍微复杂一点需要多几步合并命令。如果你机器不多、冲突不频繁直接用 main 也行如果经常双写分支策略会省很多事。7.3 定期备份裸仓裸仓虽然稳但也不是不会坏。我每周会把裸仓打包备份一次放到另一个地方。命令很简单cd /srv tar czf workbuddy-sync-backup-$(date %Y%m%d).tar.gz workbuddy-sync.git备份文件保留最近四周旧的删掉。这个习惯救过我一次——有次裸仓所在磁盘出问题靠备份恢复了全部历史。7.4 用 commit 注释记录同步原因热词里有git commit 提交注释这个看似小事其实对排查问题帮助很大。我的提交注释除了机器名和类型还会写清楚这次同步的原因比如同步前先提交本地未保存的技能修改。这样回头看历史的时候能快速定位到某次变更的上下文。git commit --amend在改注释的时候很有用但要注意只对还没推送的提交用推送过的提交改了会导致历史不一致推拉的时候会出问题。8. 我实际用下来的一些体会这套方案我用了大半年中间调整过好几次现在基本稳定了。最大的感受是双写同步的难点从来不在技术而在想清楚哪些该同步、哪些不该同步。git 只是工具真正决定成败的是你对 WorkBuddy 目录结构的理解以及对冲突处理策略的设计。如果你刚开始搭我的建议是先跑通最小闭环一个裸仓、两台机器、只同步技能目录。跑顺了再逐步加入记忆目录、配置目录。一次性全上出了问题很难定位。另外别追求全自动。技能文件、配置文件的冲突人工处理一次可能只要两分钟但自动合并出错导致的后果可能要花两小时排查。该人工的地方就人工这不是偷懒是务实。最后说一个容易被忽略的点同步脚本本身也要纳入版本管理。我一开始把sync.sh放在工作区外面结果换机器的时候忘了带又得重写一遍。后来把它放进仓库里每台机器克隆下来就有省事很多。脚本里的机器名用hostname动态获取这样一份脚本能在所有机器上用不用为每台机器单独改。