解决同步冲突
解决同步冲突
同一文件相对上次同步基线，在本地和远端都出现不同变化时会冲突。删除也算变化；覆盖选项不能修复授权或网络错误。
slothtool gstore status --json
slothtool gstore conflicts --json
slothtool gstore list --json
状态检查可能刷新远端到缓存，但不等于将远端文件恢复到真实目录。先核对冲突文件和全部绑定，备份双方有价值的内容，再选择处理方向。
无绑定参数的策略
| 选择 | 命令 | 影响 |
|---|---|---|
| 远端为准 | gstore pull --prefer-remote | 允许覆盖冲突的本地内容 |
| 本地为准 | gstore push --prefer-local | 允许覆盖冲突的远端内容 |
| 双向同步并选择冲突方向 | gstore sync --prefer-local 或 --prefer-remote | 对当前绑定集合应用指定策略 |
表中的命令前均加 slothtool。默认没有覆盖策略时，冲突会停止操作。普通 push 遇到尚未处理的远端变化，也可能要求先同步。
单绑定限制
2.10.0 基线中的 pull/push/sync <tool> <name> 服务仍会在冲突时直接停止，不能因为 CLI 接受 --prefer-* 就假定单绑定支持同样策略。
单绑定冲突优先备份后人工整理。只有确认所有绑定的影响范围，才考虑无绑定参数的覆盖操作；不要删除同步基线或缓存来绕过检查。
处理后重新查看状态和目标内容，再从另一台设备验证。若是 Git 合并、授权或网络问题，先运行 slothtool gstore doctor --json 定位。