1. 多机共用一个账号这件事到底难在哪先说清楚场景。WorkBuddy 这类工具账号通常绑定的是单一身份、单一会话状态设计之初就没打算让你在两台机器上同时用。但现实情况是很多人手头不止一台设备——公司一台台式、家里一台笔记本、偶尔还有一台跑长任务的备用机。你不可能每台机器都买一个账号成本摆在那里你也不可能每次换机器就重新登录、重新配置一遍环境时间耗不起。所以“多机共用一个 WorkBuddy 账号”这个需求本质上是在解决三个层面的问题身份复用、状态同步、冲突规避。身份复用好理解就是让两台机器都认为自己是同一个用户在操作状态同步是难点WorkBuddy 的会话记忆、缓存目录、配置文件散落在不同位置你得把它们统一管理起来冲突规避是最容易被忽略的两台机器同时写同一份数据轻则覆盖丢失重则整个配置目录损坏。我最初的做法很朴素——手动拷贝配置目录。每次在公司机器上改完配置用 U 盘或者网盘同步到家里那台。用了不到一周就放弃了原因很简单WorkBuddy 的缓存目录里有一堆运行时生成的临时文件、锁文件、会话 token你根本分不清哪些该同步、哪些不该同步。有一次我把带锁文件的目录直接覆盖过去结果两台机器都起不来了只能删掉重装。后来我换了个思路不直接同步 WorkBuddy 的工作目录而是同步一个中间层。这个中间层用 Git 来管理因为 Git 天然擅长处理“多端修改同一份文本”的场景有 commit 记录、有冲突标记、有分支合并。WorkBuddy 的配置和记忆数据大部分是文本格式JSON、YAML、Markdown非常适合放进 Git 仓库。至于那些二进制缓存、临时文件用.gitignore过滤掉就行。这个方案的核心就是标题里说的“跨机双写同步”——两台机器各自往同一个 Git 裸仓里写通过 commit-aware 的同步策略保证不丢数据、不冲突。下面我把整套实践拆开讲包括为什么这么设计、具体怎么操作、踩过哪些坑。2. 整体方案设计与核心思路拆解2.1 为什么选 Git 裸仓做中间层先解释一下“裸仓”是什么。普通 Git 仓库有一个工作区你看到的文件目录和一个.git目录版本历史。裸仓没有工作区只有版本历史它就是一个纯粹的“数据交换站”。你在本地机器上把改动 push 到裸仓另一台机器从裸仓 pull 下来两边不需要直接通信。为什么不用网盘同步因为网盘是“文件级”同步它不理解文件内容的变化。两台机器同时改同一个文件网盘只会用“最后修改时间”来决定谁覆盖谁你根本不知道丢了什么。Git 是“内容级”同步它能告诉你哪一行改了、哪一行冲突了你可以手动决定怎么合并。对于 WorkBuddy 的配置文件这种“改错一行就可能导致启动失败”的东西Git 的安全性是网盘比不了的。为什么不用 WorkBuddy 自带的云同步两个原因一是很多版本根本没有云同步功能二是即使有它同步的是“整个账号状态”你没法控制哪些数据同步、哪些不同步。比如缓存目录里那些跟机器绑定的路径信息同步过去反而会导致另一台机器找不到文件。用 Git 做中间层你可以精确控制同步范围。裸仓的搭建很简单找一台常开的机器或者用一台便宜的云主机建一个空目录执行mkdir workbuddy-sync.git cd workbuddy-sync.git git init --bare这个裸仓不需要任何工作区文件它只负责接收和分发 commit。两台机器都把它当作 remotepush 和 pull 都走它。2.2 双写同步的核心矛盾谁先谁后“双写”意味着两台机器都可能往裸仓里写。这就带来一个经典问题如果 A 机器 push 了B 机器还没 pull 就也 push会发生什么Git 的默认行为是拒绝 B 的 push因为 B 的本地历史落后于裸仓。B 必须先 pull把 A 的改动合并进来然后再 push。这个机制本身是安全的但问题在于“合并”这一步。如果 A 和 B 改的是同一个文件的不同位置Git 能自动合并如果改的是同一行就会产生冲突需要手动解决。对于 WorkBuddy 的配置数据来说冲突是必须避免的。你不可能在每次同步时都手动解决 JSON 文件的冲突那太累了。所以我的策略是用 commit-aware 的方式做同步让每台机器在写之前先确认自己是最新的。具体做法是在每台机器上写一个同步脚本push 之前先执行git pull --rebase。rebase 的意思是“把我的改动放到最新提交的后面”而不是“创建一个合并提交”。这样历史线是直的不会出现分叉再合并的混乱局面。如果 rebase 过程中出现冲突脚本会暂停并提示你手动处理而不是自动覆盖。2.3 哪些数据该同步哪些不该同步这是整个方案里最关键的设计决策。WorkBuddy 的数据大致分四类数据类型典型位置是否同步原因配置文件~/.workbuddy/config/同步文本格式跨机一致改了不会导致崩溃会话记忆~/.workbuddy/memory/同步核心资产换机器后需要延续上下文缓存目录~/.workbuddy/cache/不同步含机器绑定路径、临时文件、锁文件日志文件~/.workbuddy/logs/不同步体积大无跨机价值且可能含敏感信息同步范围用.gitignore精确控制。在 Git 仓库根目录放一个.gitignore# 忽略缓存和日志 cache/ logs/ *.log *.tmp *.lock # 忽略机器绑定文件 machine-id *.local # 但保留配置和记忆 !config/ !memory/这里有个细节.gitignore的规则是“先忽略再排除”所以如果你先写了cache/再写!cache/后者会覆盖前者。但如果你写的是cache/*再写!cache/keep.json那只有keep.json会被保留。我建议先用git status看一下哪些文件被跟踪了确认缓存目录确实没进去。注意WorkBuddy 不同版本的目录结构可能不一样。有的版本把配置放在~/.config/workbuddy/有的放在~/.workbuddy/。你先用find ~ -name *workbuddy* -type d找一下实际位置再决定同步哪些目录。3. 核心细节解析与实操要点3.1 裸仓的初始化与权限配置裸仓建好之后需要配置一下权限否则 push 的时候可能报错。如果你用的是 SSH 方式访问裸仓确保裸仓所在机器的 SSH 服务正常并且你的公钥已经加到~/.ssh/authorized_keys里。如果你用的是本地文件路径比如裸仓就在同一台机器的另一个目录那就不需要 SSH直接用路径就行。我推荐用 SSH 方式因为这样两台机器可以真正“跨机”同步不依赖文件共享。裸仓所在机器可以是任何一台常开的设备甚至是一台树莓派。初始化裸仓后在每台工作机器上执行cd ~/.workbuddy git init git remote add origin ssh://userhost/path/to/workbuddy-sync.git git add -A git commit -m init: 初始配置 git push -u origin master注意git init要在 WorkBuddy 的数据目录里执行这样 Git 才能跟踪到那些文件。但这样做的风险是WorkBuddy 运行时可能会往这个目录里写临时文件导致git status一直显示有未跟踪文件。解决办法就是前面说的.gitignore把临时文件过滤掉。3.2 commit-aware 同步脚本的编写“commit-aware”这个词听起来玄乎其实意思就是“同步的时候要知道对方提交了什么”。具体到操作上就是每次 push 之前先 fetch看看裸仓有没有新 commit有的话先 rebase。我写了一个简单的 shell 脚本放在~/sync-workbuddy.sh#!/bin/bash set -e cd ~/.workbuddy # 拉取最新改动用 rebase 保持历史线直 git fetch origin git rebase origin/master # 添加本地改动 git add -A git commit -m sync: $(date %Y-%m-%d_%H:%M:%S) from $(hostname) || true # 再次 rebase防止在 commit 期间对方又 push 了 git fetch origin git rebase origin/master # 推送 git push origin master这个脚本的关键点是两次 rebase。第一次 rebase 是在添加本地改动之前确保本地基线是最新的第二次 rebase 是在 commit 之后、push 之前防止在你 commit 的这几秒钟里对方又 push 了新内容。虽然概率很小但一旦发生push 就会被拒绝脚本会报错退出。|| true的作用是如果本地没有改动git commit会失败因为没有东西可提交加上|| true让脚本继续执行不中断。3.3 冲突处理的实际策略即使有 rebase冲突仍然可能发生。最常见的情况是两台机器都改了同一个配置文件的不同部分Git 能自动合并但如果改的是同一行就会冲突。比如 WorkBuddy 的config.json里有一行theme: darkA 机器改成了theme: lightB 机器改成了theme: autorebase 时就会冲突。Git 会在文件里插入冲突标记 HEAD theme: light theme: auto commit-hash这时候你需要手动决定保留哪个或者改成第三个值。处理完之后执行git add config.json和git rebase --continue。我的经验是尽量避免两台机器同时改同一个配置项。具体做法是把配置按功能拆分成多个小文件比如theme.json、shortcuts.json、model.json而不是全部塞在一个大文件里。这样两台机器改不同功能时冲突概率大大降低。提示如果你不确定冲突怎么解决可以先执行git rebase --abort放弃这次 rebase回到之前的状态。然后手动对比两台机器的文件决定怎么合并。4. 实操过程与核心环节实现4.1 第一台机器的完整配置流程假设你已经在机器 A 上装好了 WorkBuddy并且配置好了账号。现在要把这套配置同步到机器 B。第一步在机器 A 上找到 WorkBuddy 的数据目录。不同系统路径不同WindowsC:\Users\你的用户名\.workbuddy\macOS/Users/你的用户名/.workbuddy/Linux/home/你的用户名/.workbuddy/你可以用 WorkBuddy 的设置界面查看“数据目录”或“缓存目录”的实际路径。如果找不到就在文件管理器里搜索.workbuddy文件夹。第二步进入数据目录初始化 Git 仓库cd ~/.workbuddy git init第三步创建.gitignore文件内容参考前面的表格。这里要特别注意先不要急着git add -A先用git status看一下哪些文件会被跟踪。如果发现缓存目录里的文件也被跟踪了说明.gitignore没写对需要调整。第四步提交并推送到裸仓git add -A git commit -m init: 机器A的初始配置 git remote add origin ssh://userhost/path/to/workbuddy-sync.git git push -u origin master4.2 第二台机器的接入流程机器 B 上可能已经装了 WorkBuddy也可能没装。如果没装先装好但不要登录账号因为登录会生成新的会话数据可能覆盖你要同步的内容。如果机器 B 上已经有 WorkBuddy 的数据目录先把它备份一下mv ~/.workbuddy ~/.workbuddy.bak然后从裸仓克隆git clone ssh://userhost/path/to/workbuddy-sync.git ~/.workbuddy克隆完成后检查一下config/和memory/目录是否存在内容是否完整。然后启动 WorkBuddy看它是否能正常读取配置。如果启动失败大概率是某个配置文件里包含了机器 A 的绝对路径需要手动改成机器 B 的路径。注意WorkBuddy 的某些配置项可能包含机器绑定的信息比如cache_dir: /home/userA/.workbuddy/cache。这种路径在机器 B 上不存在会导致启动失败。解决办法是在.gitignore里排除这类文件或者用环境变量代替绝对路径。4.3 日常同步的操作节奏两台机器都接入之后日常使用就是“改完就同步”。我的习惯是在机器 A 上改完配置或积累了一段会话记忆后执行~/sync-workbuddy.sh。换到机器 B 时先执行git pull --rebase再启动 WorkBuddy。如果机器 B 上也改了东西同样执行~/sync-workbuddy.sh。这个节奏的关键是不要攒太多改动再同步。改动越多冲突概率越大。我一般是一天同步一次或者每次切换机器前同步一次。如果你经常忘记同步可以设置一个定时任务。Linux 和 macOS 用crontabWindows 用“任务计划程序”。比如每小时同步一次# crontab -e 0 * * * * /home/user/sync-workbuddy.sh /tmp/workbuddy-sync.log 21但定时同步有个风险如果 WorkBuddy 正在写文件同步脚本可能会读到不完整的数据。所以最好在 WorkBuddy 空闲时同步或者同步前先关闭 WorkBuddy。4.4 验证同步是否成功的检查清单每次同步后我会做几个快速检查git log --oneline -5看最近的 commit 是否包含对方的改动。git status看是否有未提交的本地改动。启动 WorkBuddy看会话记忆是否延续、配置是否生效。检查cache/和logs/目录是否被意外同步用git ls-files | grep cache确认。如果发现缓存文件被跟踪了执行git rm -r --cached cache/把它们从 Git 索引里移除然后重新提交。5. 常见问题与排查技巧实录5.1 SSH 认证失败怎么办这是最常见的问题。报错通常是Permission denied (publickey)或ssh: connect to host xxx port 22: Connection refused。先检查 SSH 密钥是否生成ls ~/.ssh/id_rsa.pub如果没有执行ssh-keygen -t rsa -b 4096生成。然后把公钥内容加到裸仓所在机器的~/.ssh/authorized_keys里。如果密钥有了但还是失败用ssh -v userhost看详细日志。常见原因包括裸仓机器的 SSH 服务没启动、防火墙挡了 22 端口、用户名写错了、密钥权限太开放chmod 600 ~/.ssh/id_rsa。提示如果你用的是 WindowsSSH 密钥默认在C:\Users\你的用户名\.ssh\下。Git Bash 和 PowerShell 的路径可能不一样注意区分。5.2 rebase 冲突后怎么恢复如果你执行git rebase时遇到冲突脚本会停在冲突状态。这时候你有三个选择手动解决冲突然后git addgit rebase --continue。放弃这次 rebase执行git rebase --abort回到之前的状态。如果已经解决了一部分但想重新来执行git rebase --skip跳过当前 commit慎用可能丢改动。我的建议是如果你不确定怎么解决先git rebase --abort然后用git diff对比两台机器的文件手动合并后再提交。这样虽然麻烦一点但不会丢数据。5.3 同步后 WorkBuddy 启动失败启动失败通常是因为配置文件里包含了机器绑定的路径或 ID。排查步骤看 WorkBuddy 的日志文件在logs/目录下找到报错的具体文件。用git log -p 文件名看这个文件最近改了什么。对比两台机器的这个文件找出差异。把机器绑定的部分改成通用值或者用环境变量代替。如果实在找不到原因可以先把config/目录回退到上一个 commitgit checkout HEAD~1 -- config/然后逐个文件恢复定位到具体是哪个文件导致的问题。5.4 常见问题速查表问题现象可能原因解决方法push 被拒绝裸仓有新 commit先git pull --rebase再 pushrebase 冲突两台机器改了同一行手动解决冲突后git rebase --continueSSH 认证失败密钥未配置或权限不对检查~/.ssh/和authorized_keys启动失败配置含机器绑定路径检查日志修改或排除该文件缓存文件被同步.gitignore没生效git rm -r --cached cache/后重新提交同步后记忆丢失memory 目录未同步检查.gitignore是否排除了 memory5.5 几个我踩过的坑第一个坑在 WorkBuddy 运行时执行同步。有一次我没关 WorkBuddy 就跑了同步脚本结果它正在写会话记忆文件Git 读到了一个半截的 JSONpush 上去之后另一台机器 pull 下来直接解析失败。后来我养成了习惯同步前先退出 WorkBuddy。第二个坑.gitignore写得太宽泛。我一开始写了*.json想忽略所有 JSON 文件结果把配置文件也忽略了。正确的做法是按目录忽略而不是按扩展名。第三个坑裸仓所在机器磁盘满了。裸仓虽然只存版本历史但时间长了也会积累很多 commit。如果裸仓机器磁盘小建议定期执行git gc清理无用对象。第四个坑两台机器的 WorkBuddy 版本不一致。版本不同可能导致配置文件格式不兼容同步后一台能启动一台不能。解决办法是尽量保持两台机器的 WorkBuddy 版本一致升级时两台一起升。6. 进阶优化与长期维护建议6.1 用分支隔离不同机器的改动如果你想让同步更安全可以给每台机器建一个分支。机器 A 用machine-a分支机器 B 用machine-b分支裸仓的master分支作为汇总。每台机器先 push 到自己的分支然后定期把master合并进来。这样做的好处是即使某台机器的改动有问题也不会直接影响另一台。缺点是操作更复杂需要手动合并分支。适合对数据安全性要求极高的场景。6.2 定期备份裸仓裸仓虽然比工作目录安全但也不是万无一失。如果裸仓所在机器坏了所有版本历史都没了。建议定期把裸仓打包备份到另一个地方cd /path/to/workbuddy-sync.git git bundle create /backup/workbuddy-sync-$(date %Y%m%d).bundle --allgit bundle会把整个仓库打包成一个文件恢复时用git clone workbuddy-sync.bundle就行。6.3 监控同步状态如果你有多台机器频繁同步可以写一个简单的监控脚本每天检查一次裸仓的 commit 数量和各机器的最后同步时间。如果某台机器超过 48 小时没同步就发个提醒。这个脚本用git log和git show就能实现不需要额外工具。关键是养成定期检查的习惯不要等到出问题了才去看。6.4 什么时候该放弃这个方案说实话这个方案不是万能的。如果你满足以下任一条件可能不值得折腾只有一台机器没有跨机需求。WorkBuddy 的数据量极大比如几十 GB 的缓存Git 处理起来很慢。你完全不熟悉命令行每次操作都要查教程。这种情况下手动拷贝配置文件可能更省事。或者等 WorkBuddy 官方推出云同步功能直接用官方的更省心。我个人在实际操作中的体会是这套方案最大的价值不是“省了多少钱”而是“让你对自己的数据有完全的控制权”。你知道哪些数据在同步、哪些不在出了问题能定位到具体是哪个 commit 导致的。这种掌控感是网盘同步给不了的。最后再分享一个小技巧如果你在同步脚本里加上git log --oneline -1的输出每次同步后就能看到最新 commit 的哈希和消息方便快速确认同步是否成功。
多机共用一个WorkBuddy账号：Git裸仓实现跨机双写同步
1. 多机共用一个账号这件事到底难在哪先说清楚场景。WorkBuddy 这类工具账号通常绑定的是单一身份、单一会话状态设计之初就没打算让你在两台机器上同时用。但现实情况是很多人手头不止一台设备——公司一台台式、家里一台笔记本、偶尔还有一台跑长任务的备用机。你不可能每台机器都买一个账号成本摆在那里你也不可能每次换机器就重新登录、重新配置一遍环境时间耗不起。所以“多机共用一个 WorkBuddy 账号”这个需求本质上是在解决三个层面的问题身份复用、状态同步、冲突规避。身份复用好理解就是让两台机器都认为自己是同一个用户在操作状态同步是难点WorkBuddy 的会话记忆、缓存目录、配置文件散落在不同位置你得把它们统一管理起来冲突规避是最容易被忽略的两台机器同时写同一份数据轻则覆盖丢失重则整个配置目录损坏。我最初的做法很朴素——手动拷贝配置目录。每次在公司机器上改完配置用 U 盘或者网盘同步到家里那台。用了不到一周就放弃了原因很简单WorkBuddy 的缓存目录里有一堆运行时生成的临时文件、锁文件、会话 token你根本分不清哪些该同步、哪些不该同步。有一次我把带锁文件的目录直接覆盖过去结果两台机器都起不来了只能删掉重装。后来我换了个思路不直接同步 WorkBuddy 的工作目录而是同步一个中间层。这个中间层用 Git 来管理因为 Git 天然擅长处理“多端修改同一份文本”的场景有 commit 记录、有冲突标记、有分支合并。WorkBuddy 的配置和记忆数据大部分是文本格式JSON、YAML、Markdown非常适合放进 Git 仓库。至于那些二进制缓存、临时文件用.gitignore过滤掉就行。这个方案的核心就是标题里说的“跨机双写同步”——两台机器各自往同一个 Git 裸仓里写通过 commit-aware 的同步策略保证不丢数据、不冲突。下面我把整套实践拆开讲包括为什么这么设计、具体怎么操作、踩过哪些坑。2. 整体方案设计与核心思路拆解2.1 为什么选 Git 裸仓做中间层先解释一下“裸仓”是什么。普通 Git 仓库有一个工作区你看到的文件目录和一个.git目录版本历史。裸仓没有工作区只有版本历史它就是一个纯粹的“数据交换站”。你在本地机器上把改动 push 到裸仓另一台机器从裸仓 pull 下来两边不需要直接通信。为什么不用网盘同步因为网盘是“文件级”同步它不理解文件内容的变化。两台机器同时改同一个文件网盘只会用“最后修改时间”来决定谁覆盖谁你根本不知道丢了什么。Git 是“内容级”同步它能告诉你哪一行改了、哪一行冲突了你可以手动决定怎么合并。对于 WorkBuddy 的配置文件这种“改错一行就可能导致启动失败”的东西Git 的安全性是网盘比不了的。为什么不用 WorkBuddy 自带的云同步两个原因一是很多版本根本没有云同步功能二是即使有它同步的是“整个账号状态”你没法控制哪些数据同步、哪些不同步。比如缓存目录里那些跟机器绑定的路径信息同步过去反而会导致另一台机器找不到文件。用 Git 做中间层你可以精确控制同步范围。裸仓的搭建很简单找一台常开的机器或者用一台便宜的云主机建一个空目录执行mkdir workbuddy-sync.git cd workbuddy-sync.git git init --bare这个裸仓不需要任何工作区文件它只负责接收和分发 commit。两台机器都把它当作 remotepush 和 pull 都走它。2.2 双写同步的核心矛盾谁先谁后“双写”意味着两台机器都可能往裸仓里写。这就带来一个经典问题如果 A 机器 push 了B 机器还没 pull 就也 push会发生什么Git 的默认行为是拒绝 B 的 push因为 B 的本地历史落后于裸仓。B 必须先 pull把 A 的改动合并进来然后再 push。这个机制本身是安全的但问题在于“合并”这一步。如果 A 和 B 改的是同一个文件的不同位置Git 能自动合并如果改的是同一行就会产生冲突需要手动解决。对于 WorkBuddy 的配置数据来说冲突是必须避免的。你不可能在每次同步时都手动解决 JSON 文件的冲突那太累了。所以我的策略是用 commit-aware 的方式做同步让每台机器在写之前先确认自己是最新的。具体做法是在每台机器上写一个同步脚本push 之前先执行git pull --rebase。rebase 的意思是“把我的改动放到最新提交的后面”而不是“创建一个合并提交”。这样历史线是直的不会出现分叉再合并的混乱局面。如果 rebase 过程中出现冲突脚本会暂停并提示你手动处理而不是自动覆盖。2.3 哪些数据该同步哪些不该同步这是整个方案里最关键的设计决策。WorkBuddy 的数据大致分四类数据类型典型位置是否同步原因配置文件~/.workbuddy/config/同步文本格式跨机一致改了不会导致崩溃会话记忆~/.workbuddy/memory/同步核心资产换机器后需要延续上下文缓存目录~/.workbuddy/cache/不同步含机器绑定路径、临时文件、锁文件日志文件~/.workbuddy/logs/不同步体积大无跨机价值且可能含敏感信息同步范围用.gitignore精确控制。在 Git 仓库根目录放一个.gitignore# 忽略缓存和日志 cache/ logs/ *.log *.tmp *.lock # 忽略机器绑定文件 machine-id *.local # 但保留配置和记忆 !config/ !memory/这里有个细节.gitignore的规则是“先忽略再排除”所以如果你先写了cache/再写!cache/后者会覆盖前者。但如果你写的是cache/*再写!cache/keep.json那只有keep.json会被保留。我建议先用git status看一下哪些文件被跟踪了确认缓存目录确实没进去。注意WorkBuddy 不同版本的目录结构可能不一样。有的版本把配置放在~/.config/workbuddy/有的放在~/.workbuddy/。你先用find ~ -name *workbuddy* -type d找一下实际位置再决定同步哪些目录。3. 核心细节解析与实操要点3.1 裸仓的初始化与权限配置裸仓建好之后需要配置一下权限否则 push 的时候可能报错。如果你用的是 SSH 方式访问裸仓确保裸仓所在机器的 SSH 服务正常并且你的公钥已经加到~/.ssh/authorized_keys里。如果你用的是本地文件路径比如裸仓就在同一台机器的另一个目录那就不需要 SSH直接用路径就行。我推荐用 SSH 方式因为这样两台机器可以真正“跨机”同步不依赖文件共享。裸仓所在机器可以是任何一台常开的设备甚至是一台树莓派。初始化裸仓后在每台工作机器上执行cd ~/.workbuddy git init git remote add origin ssh://userhost/path/to/workbuddy-sync.git git add -A git commit -m init: 初始配置 git push -u origin master注意git init要在 WorkBuddy 的数据目录里执行这样 Git 才能跟踪到那些文件。但这样做的风险是WorkBuddy 运行时可能会往这个目录里写临时文件导致git status一直显示有未跟踪文件。解决办法就是前面说的.gitignore把临时文件过滤掉。3.2 commit-aware 同步脚本的编写“commit-aware”这个词听起来玄乎其实意思就是“同步的时候要知道对方提交了什么”。具体到操作上就是每次 push 之前先 fetch看看裸仓有没有新 commit有的话先 rebase。我写了一个简单的 shell 脚本放在~/sync-workbuddy.sh#!/bin/bash set -e cd ~/.workbuddy # 拉取最新改动用 rebase 保持历史线直 git fetch origin git rebase origin/master # 添加本地改动 git add -A git commit -m sync: $(date %Y-%m-%d_%H:%M:%S) from $(hostname) || true # 再次 rebase防止在 commit 期间对方又 push 了 git fetch origin git rebase origin/master # 推送 git push origin master这个脚本的关键点是两次 rebase。第一次 rebase 是在添加本地改动之前确保本地基线是最新的第二次 rebase 是在 commit 之后、push 之前防止在你 commit 的这几秒钟里对方又 push 了新内容。虽然概率很小但一旦发生push 就会被拒绝脚本会报错退出。|| true的作用是如果本地没有改动git commit会失败因为没有东西可提交加上|| true让脚本继续执行不中断。3.3 冲突处理的实际策略即使有 rebase冲突仍然可能发生。最常见的情况是两台机器都改了同一个配置文件的不同部分Git 能自动合并但如果改的是同一行就会冲突。比如 WorkBuddy 的config.json里有一行theme: darkA 机器改成了theme: lightB 机器改成了theme: autorebase 时就会冲突。Git 会在文件里插入冲突标记 HEAD theme: light theme: auto commit-hash这时候你需要手动决定保留哪个或者改成第三个值。处理完之后执行git add config.json和git rebase --continue。我的经验是尽量避免两台机器同时改同一个配置项。具体做法是把配置按功能拆分成多个小文件比如theme.json、shortcuts.json、model.json而不是全部塞在一个大文件里。这样两台机器改不同功能时冲突概率大大降低。提示如果你不确定冲突怎么解决可以先执行git rebase --abort放弃这次 rebase回到之前的状态。然后手动对比两台机器的文件决定怎么合并。4. 实操过程与核心环节实现4.1 第一台机器的完整配置流程假设你已经在机器 A 上装好了 WorkBuddy并且配置好了账号。现在要把这套配置同步到机器 B。第一步在机器 A 上找到 WorkBuddy 的数据目录。不同系统路径不同WindowsC:\Users\你的用户名\.workbuddy\macOS/Users/你的用户名/.workbuddy/Linux/home/你的用户名/.workbuddy/你可以用 WorkBuddy 的设置界面查看“数据目录”或“缓存目录”的实际路径。如果找不到就在文件管理器里搜索.workbuddy文件夹。第二步进入数据目录初始化 Git 仓库cd ~/.workbuddy git init第三步创建.gitignore文件内容参考前面的表格。这里要特别注意先不要急着git add -A先用git status看一下哪些文件会被跟踪。如果发现缓存目录里的文件也被跟踪了说明.gitignore没写对需要调整。第四步提交并推送到裸仓git add -A git commit -m init: 机器A的初始配置 git remote add origin ssh://userhost/path/to/workbuddy-sync.git git push -u origin master4.2 第二台机器的接入流程机器 B 上可能已经装了 WorkBuddy也可能没装。如果没装先装好但不要登录账号因为登录会生成新的会话数据可能覆盖你要同步的内容。如果机器 B 上已经有 WorkBuddy 的数据目录先把它备份一下mv ~/.workbuddy ~/.workbuddy.bak然后从裸仓克隆git clone ssh://userhost/path/to/workbuddy-sync.git ~/.workbuddy克隆完成后检查一下config/和memory/目录是否存在内容是否完整。然后启动 WorkBuddy看它是否能正常读取配置。如果启动失败大概率是某个配置文件里包含了机器 A 的绝对路径需要手动改成机器 B 的路径。注意WorkBuddy 的某些配置项可能包含机器绑定的信息比如cache_dir: /home/userA/.workbuddy/cache。这种路径在机器 B 上不存在会导致启动失败。解决办法是在.gitignore里排除这类文件或者用环境变量代替绝对路径。4.3 日常同步的操作节奏两台机器都接入之后日常使用就是“改完就同步”。我的习惯是在机器 A 上改完配置或积累了一段会话记忆后执行~/sync-workbuddy.sh。换到机器 B 时先执行git pull --rebase再启动 WorkBuddy。如果机器 B 上也改了东西同样执行~/sync-workbuddy.sh。这个节奏的关键是不要攒太多改动再同步。改动越多冲突概率越大。我一般是一天同步一次或者每次切换机器前同步一次。如果你经常忘记同步可以设置一个定时任务。Linux 和 macOS 用crontabWindows 用“任务计划程序”。比如每小时同步一次# crontab -e 0 * * * * /home/user/sync-workbuddy.sh /tmp/workbuddy-sync.log 21但定时同步有个风险如果 WorkBuddy 正在写文件同步脚本可能会读到不完整的数据。所以最好在 WorkBuddy 空闲时同步或者同步前先关闭 WorkBuddy。4.4 验证同步是否成功的检查清单每次同步后我会做几个快速检查git log --oneline -5看最近的 commit 是否包含对方的改动。git status看是否有未提交的本地改动。启动 WorkBuddy看会话记忆是否延续、配置是否生效。检查cache/和logs/目录是否被意外同步用git ls-files | grep cache确认。如果发现缓存文件被跟踪了执行git rm -r --cached cache/把它们从 Git 索引里移除然后重新提交。5. 常见问题与排查技巧实录5.1 SSH 认证失败怎么办这是最常见的问题。报错通常是Permission denied (publickey)或ssh: connect to host xxx port 22: Connection refused。先检查 SSH 密钥是否生成ls ~/.ssh/id_rsa.pub如果没有执行ssh-keygen -t rsa -b 4096生成。然后把公钥内容加到裸仓所在机器的~/.ssh/authorized_keys里。如果密钥有了但还是失败用ssh -v userhost看详细日志。常见原因包括裸仓机器的 SSH 服务没启动、防火墙挡了 22 端口、用户名写错了、密钥权限太开放chmod 600 ~/.ssh/id_rsa。提示如果你用的是 WindowsSSH 密钥默认在C:\Users\你的用户名\.ssh\下。Git Bash 和 PowerShell 的路径可能不一样注意区分。5.2 rebase 冲突后怎么恢复如果你执行git rebase时遇到冲突脚本会停在冲突状态。这时候你有三个选择手动解决冲突然后git addgit rebase --continue。放弃这次 rebase执行git rebase --abort回到之前的状态。如果已经解决了一部分但想重新来执行git rebase --skip跳过当前 commit慎用可能丢改动。我的建议是如果你不确定怎么解决先git rebase --abort然后用git diff对比两台机器的文件手动合并后再提交。这样虽然麻烦一点但不会丢数据。5.3 同步后 WorkBuddy 启动失败启动失败通常是因为配置文件里包含了机器绑定的路径或 ID。排查步骤看 WorkBuddy 的日志文件在logs/目录下找到报错的具体文件。用git log -p 文件名看这个文件最近改了什么。对比两台机器的这个文件找出差异。把机器绑定的部分改成通用值或者用环境变量代替。如果实在找不到原因可以先把config/目录回退到上一个 commitgit checkout HEAD~1 -- config/然后逐个文件恢复定位到具体是哪个文件导致的问题。5.4 常见问题速查表问题现象可能原因解决方法push 被拒绝裸仓有新 commit先git pull --rebase再 pushrebase 冲突两台机器改了同一行手动解决冲突后git rebase --continueSSH 认证失败密钥未配置或权限不对检查~/.ssh/和authorized_keys启动失败配置含机器绑定路径检查日志修改或排除该文件缓存文件被同步.gitignore没生效git rm -r --cached cache/后重新提交同步后记忆丢失memory 目录未同步检查.gitignore是否排除了 memory5.5 几个我踩过的坑第一个坑在 WorkBuddy 运行时执行同步。有一次我没关 WorkBuddy 就跑了同步脚本结果它正在写会话记忆文件Git 读到了一个半截的 JSONpush 上去之后另一台机器 pull 下来直接解析失败。后来我养成了习惯同步前先退出 WorkBuddy。第二个坑.gitignore写得太宽泛。我一开始写了*.json想忽略所有 JSON 文件结果把配置文件也忽略了。正确的做法是按目录忽略而不是按扩展名。第三个坑裸仓所在机器磁盘满了。裸仓虽然只存版本历史但时间长了也会积累很多 commit。如果裸仓机器磁盘小建议定期执行git gc清理无用对象。第四个坑两台机器的 WorkBuddy 版本不一致。版本不同可能导致配置文件格式不兼容同步后一台能启动一台不能。解决办法是尽量保持两台机器的 WorkBuddy 版本一致升级时两台一起升。6. 进阶优化与长期维护建议6.1 用分支隔离不同机器的改动如果你想让同步更安全可以给每台机器建一个分支。机器 A 用machine-a分支机器 B 用machine-b分支裸仓的master分支作为汇总。每台机器先 push 到自己的分支然后定期把master合并进来。这样做的好处是即使某台机器的改动有问题也不会直接影响另一台。缺点是操作更复杂需要手动合并分支。适合对数据安全性要求极高的场景。6.2 定期备份裸仓裸仓虽然比工作目录安全但也不是万无一失。如果裸仓所在机器坏了所有版本历史都没了。建议定期把裸仓打包备份到另一个地方cd /path/to/workbuddy-sync.git git bundle create /backup/workbuddy-sync-$(date %Y%m%d).bundle --allgit bundle会把整个仓库打包成一个文件恢复时用git clone workbuddy-sync.bundle就行。6.3 监控同步状态如果你有多台机器频繁同步可以写一个简单的监控脚本每天检查一次裸仓的 commit 数量和各机器的最后同步时间。如果某台机器超过 48 小时没同步就发个提醒。这个脚本用git log和git show就能实现不需要额外工具。关键是养成定期检查的习惯不要等到出问题了才去看。6.4 什么时候该放弃这个方案说实话这个方案不是万能的。如果你满足以下任一条件可能不值得折腾只有一台机器没有跨机需求。WorkBuddy 的数据量极大比如几十 GB 的缓存Git 处理起来很慢。你完全不熟悉命令行每次操作都要查教程。这种情况下手动拷贝配置文件可能更省事。或者等 WorkBuddy 官方推出云同步功能直接用官方的更省心。我个人在实际操作中的体会是这套方案最大的价值不是“省了多少钱”而是“让你对自己的数据有完全的控制权”。你知道哪些数据在同步、哪些不在出了问题能定位到具体是哪个 commit 导致的。这种掌控感是网盘同步给不了的。最后再分享一个小技巧如果你在同步脚本里加上git log --oneline -1的输出每次同步后就能看到最新 commit 的哈希和消息方便快速确认同步是否成功。