把同一组动作在两套工具里各跑一遍，比看概念介绍更容易判断：每天真正会碰到的无非建分支、切换、提交、看历史、回退这几件事。差异往往集中在两处——提交记录是按一次改动一条，还是按一段工作一条；切换时是即时改变工作区，还是需要先处理未提交内容。这两点决定你会不会改掉手上的习惯，其余差异多数只影响阅读舒适度，不影响能不能继续用。

判断顺序建议这样走：先在本地仓库副本上确认当前分支怎么显示（提示符或状态命令），再确认一次提交对应多少条历史记录，最后确认多人协作时别人看到的是不是同一份前提。若某条说法来自别人转述，就把它记成待确认，写清缺哪台机器或哪个仓库才能验证。凡是本机 help、状态输出、历史输出里看不到的，不要写进自己的操作习惯。

先列出自己每天真正会用的几个版本控制动作

先把范围收窄。下面五类动作足够覆盖大部分日常，也正好作为后面那张对照表的行。不要一上来就对比标签、钩子、子模块这些低频能力，它们会把判断拖偏。

• 建分支：新功能或修复起一个独立线。
• 切换：在两条线之间来回，工作区跟着变。
• 提交：把一次改动写进历史，并附上一句说明。
• 看历史：翻最近几条记录，确认顺序和说明。
• 回退：撤销一次改动或回到上一个状态。

每类动作只记三样东西：命令骨架、执行后屏幕上出现什么、这个输出是否和 Git 一致到可以照抄旧习惯。命令名字先不猜，用工具自带的帮助去查。

# 先在仓库副本里确认命令面，不要直接在主工作目录试
cd /path/to/repo-copy
git `--version`
scion help
scion <子命令> `--help`    # 若帮助形式不同，按本机输出为准

在同一份仓库副本上分别建分支并切换

两边都从同一个目录状态出发，避免一边干净一边有未提交改动，否则观察到的差异可能来自脏工作区，而不是分支模型本身。Git 侧的骨架比较固定：

git switch -c topic-a        # 老版本可用 git checkout -b topic-a
git status -sb               # 确认当前分支与改动清单
git branch `--show-current`    # 只输出分支名

Scion 侧只给骨架，子命令名以本机帮助为准：

scion branch create topic-a   # 也可能叫 new / add / start
scion switch topic-a          # 也可能叫 checkout / go / update
scion status                  # 观察提示与当前所处位置

要抄录的观察点只有两个。第一，当前所处分支是显示在提示符里，还是必须敲一条状态命令才能看到；如果是后者，你的肌肉记忆要改。第二，切换时工作区是否立即变化，还是要求先提交、先搁置、先放弃改动。若帮助里根本没有 branch 或 switch 这类子命令，说明它可能不按分支组织工作，这时不要硬套 Git 的词汇，把它记为待确认项，而不是当成缺陷。

各提交一次改动，对比历史的呈现方式

两边各改同一个文件的同一处，提交说明写一样的一句话，然后看历史。Git 的读法：

git add -p
git commit -m "docs: adjust nav"
git log `--oneline` `--graph` `--decorate` -n 10

Scion 侧骨架：

scion status
scion commit -m "docs: adjust nav"   # 参数拼法以帮助输出为准
scion log                            # 也可能叫 history / list

重点看三件事：提交说明能不能原样显示出来；时间顺序是自上而下还是自下而上；一条记录对应的是你刚刚那一次改动，还是把中间保存的若干次中间态合并成了一条。如果一条工作被折成一条记录，日常阅读会更干净，但你在回退时能选的最小单位就变粗了，这会改变习惯。另外记下记录标识的形态和可截断长度，别人贴给你一段 id 时你要能对上。

把差异分成影响日常和不影响日常两栏

分栏的判断依据建议只留两条：是否改变提交粒度，是否改变多人协作的前提。只要命中其中一条，就归到影响日常；两条都不命中，先归到可忽略，等真遇到问题再翻出来。

多人协作那条要单独确认：别人拿到的历史里，是否看到和你本机相同的顺序与说明。如果只有本机能对上，就把共享仓库那一步标成待确认，不要先按 Git 的方式同步给同事。

把无法在本机验证的说法单独标为待确认

从群聊、同事或旧笔记里听来的说法，不要直接写进操作习惯。按固定格式记一条，比留在脑子里可靠：

待确认项：
听来来源：人 / 群 / 文章（不写具体日期）
本机已做：scion help、scion log、切换后状态输出
还缺什么：第二台机器 / 第二个仓库副本 / 他人协助验证
当前判定：未在本机复现

验证所需的前置条件通常有三类：另一台机器上装同版本工具，确认行为是否随环境变化；另一个仓库副本，确认历史呈现是否受仓库结构影响；他人协助，确认协作端看到的结果与你本机一致。这三类都不具备时，可以先按影响日常的那一栏保守操作，把待确认项挂着，而不是提前改掉整套流程。等条件具备再逐条划掉，比一开始就相信一段转述要稳。