想试 Scion 又不想动到正在用的仓库，比较稳的做法是：先复制一份仓库副本，在副本里只验证「提交—查历史—回滚」这条最小链路，任一步对不上，就删掉副本、退回原仓库，而不是继续在原件上试。下面每一步都给可执行的命令骨架和判断信号；Scion 的具体子命令名一律以本机帮助输出为准，文中子命令位置都用占位符表示。

适用场景：只是验证 Scion 能否接管或配合一个 Git 仓库，不涉及共享仓库与多人协作。操作动作：复制仓库、读本机帮助、改一个已知文件并提交、回滚该提交。验证方式：每一步用 git status、git log、git diff 输出确认状态变化，并保留报错原文。风险边界：所有写操作只发生在副本目录；命令名不确定时先看帮助，不凭记忆敲；原仓库只做只读检查。

在测试目录复制一份仓库并确认工作区干净

先把试错范围限制在副本里。复制有两种常用方式：直接复制目录，或用 Git 克隆。

# 方式一：目录复制，保留工作区里的未提交改动，适合原样搬迁
cp -a /path/to/origin-repo /tmp/scion-trial-repo

# 方式二：Git 克隆，只带已提交的历史，适合从干净点开始
git clone /path/to/origin-repo /tmp/scion-trial-repo
cd /tmp/scion-trial-repo

判断原始仓库没有被这次操作改动：执行前后各跑一次只读检查，两次输出一致即可。

git -C /path/to/origin-repo status `--porcelain`
git -C /path/to/origin-repo rev-parse HEAD

在副本目录里，进入操作状态时工作区应当是干净的：

cd /tmp/scion-trial-repo
git status -sb
# 预期形态：首行是当前分支，如 ## main...origin/main
# 其后没有 "M "、"?? " 这类条目，末尾提示 working tree clean

如果副本并不干净，先处理掉这些改动再往下走，否则后面很难区分是自己改的、Scion 改的，还是原本就存在的。同时把副本当前的提交号记下来，回滚阶段会用到：

git rev-parse HEAD > /tmp/scion-trial-base.txt
cat /tmp/scion-trial-base.txt

先看本机帮助输出，确认 Scion 实际可用的子命令

不同版本、不同安装方式下可用的子命令可能不一样，所以不要靠记忆或别处的示例敲命令。先拿顶层帮助，再拿子命令帮助。

scion `--help` > /tmp/scion-help.txt 2>&1
cat /tmp/scion-help.txt

# 顶层帮助里通常会列出子命令清单，对每个候选再确认一次
scion <候选子命令> `--help`

# 版本信息，命令名以本机为准，也可能是 scion version
scion `--version`

从输出里摘子命令清单的方法：看 Commands 或 Available Commands 这一段，只记下与本次目标相关的三类——提交、查看历史（或状态）、回退。每个子命令至少确认它的用法行和是否接受 -m 这类消息参数。把帮助输出和版本信息落到文件里，和仓库基线放在一起：

scion `--version` >> /tmp/scion-help.txt 2>&1
git -C /tmp/scion-trial-repo rev-parse `--short` HEAD >> /tmp/scion-help.txt

需要确认的点：这份帮助里是否存在回退类子命令；如果没有，回滚阶段就只走 Git 侧，不要临时拼一个不存在的命令名。

改一个已知文件并提交，确认提交链路可用

只读能连通不代表写入侧可用，所以要真改一个内容已知的文件。建议新建一个无关紧要的文本文件，避免碰业务代码。

cd /tmp/scion-trial-repo
printf 'scion trial\n' >> trial-note.txt

git status `--porcelain`
# 提交前：这里应看到 ?? trial-note.txt 这类条目

提交命令以第 2 步摘出的子命令名为准，下面只是骨架：

# 提交前再确认一次状态
git status `--porcelain`

scion <提交子命令> -m "trial: scion round-trip"

# 提交后
git status `--porcelain`
git log `--oneline` -3

观察点：提交后 git status `--porcelain` 不应再列出这个文件；git log `--oneline` -3 里，这条 trial 提交通常应出现在第一行，也就是最新提交在最上方。如果它出现在这里，说明提交链路落到了这个 Git 仓库；如果没有出现、但文件状态确实变了，说明改动可能写到了别处，或者还需要额外的同步动作，这时先停下来记录现象，不要接着做回滚。

回滚这一次提交，检查工作区与历史状态

先固化对比基线，再回退，回退后再比一次，这样才知道影响范围是不是只有这一次提交。

# 回退前：看这次提交改了什么
git show `--stat` HEAD
git diff HEAD~1 HEAD -- trial-note.txt

回退操作优先用帮助里确认过的 Scion 回退子命令；如果它只是在 Git 之上做了一层封装，也可以用 Git 自带的反向提交作为对照：

# 骨架，命令名以第 2 步的帮助输出为准
scion <回退子命令> <提交标识>

# 作为对照：Git 侧的反向提交
git revert `--no-edit` HEAD

回退后检查：

git log `--oneline` -3
git diff HEAD~1 HEAD -- trial-note.txt
git status -sb

判断信号：文件内容回到改动前，diff 输出为空或只剩反向差异；git status -sb 仍是干净工作区，或只多出一条反向提交；历史里除被回退的那一条之外，没有别的提交被牵连。如果回退动作把工作区改乱了，或者报错中断在中间，回到副本层面处理最快：

# 在副本目录里，先看能否回到基线
cat /tmp/scion-trial-base.txt
git reset `--hard` "$(cat /tmp/scion-trial-base.txt)"

# 最省事的兜底：删掉副本重新复制，原仓库不受影响
cd /
rm -rf /tmp/scion-trial-repo

注意：git reset `--hard` 会丢弃副本里未提交的内容，只在确认这是副本目录时使用，不要在正在用的原仓库里执行这个动作。

记录本次操作里失败的命令与原始报错

把猜测换成证据。每一步都保留完整命令、退出码和原始输出，尤其是标准错误：

scion <子命令> <参数> 2>&1 | tee /tmp/scion-run.log
echo "exit=$?"
git status `--porcelain` >> /tmp/scion-run.log 2>&1

判定失败发生在哪一步：找到最后一条成功命令之后的第一个非零退出码；如果命令本身返回 0 但状态没变，就以 git status `--porcelain` 与 git log `--oneline` -1 的差异为准，这属于「命令成功了但没生效」。摘录报错时保留原文，包括命令名、参数、报错行和当时所在目录，不要只转述成「提交失败」。

需要向他人确认的待查项，可以按这份清单问：Scion 的提交是直接写入该仓库，还是需要额外的同步或远端步骤；回退子命令的准确名称与参数顺序；帮助输出里的版本号与安装来源是否一致。把这些和 /tmp/scion-help.txt、/tmp/scion-run.log、副本的基线提交号放在一起，别人就能复现你的整条路径。