<p>git log --oneline 输出不能直接作 Markdown 列表，因其无前置符号、缩进不一、commit hash 长度不固定（默认7位但可变），易导致正则匹配漏或误；应先用 --pretty=format:"%h %s" 提取纯净格式，再以 ^([0-9a-f]{7,})\s+(.+)$ 匹配替换为 - \2 (\1)，并清理冗余前缀、确保 UTF-8 编码。</p>
为什么 git log --oneline 的输出不能直接当 Markdown 列表用
因为默认格式是 abc1234 feat: add user profile，没有前置符号，缩进不一致，且 commit hash 长度不固定（Git 2.11+ 默认显示 7 位，但有时会更短或更长），直接替换容易漏匹配或误伤。关键不是“能不能换”，而是“怎么换才稳”。
实操建议：
- 先用
git log --pretty=format:"%h %s"统一提取精简格式，避免日志中混入Author或空行干扰 - 复制结果到 Sublime 后，确保文档编码为 UTF-8，关闭「自动换行」，否则正则跨行会失效
- 打开「正则模式」（
.*按钮），并勾选「匹配大小写」——多数提交前缀如feat、fix是小写，但有人写Feat，得按需决定是否开
用 ^([0-9a-f]{7,})\s+(.+)$ 匹配并转成无序列表
这是最稳的开头匹配：锚定行首 ^，捕获 7 位及以上 hex commit id（兼容 git log --abbrev=8 等自定义），跳过中间空格，再捕获剩余全部提交信息（.+ 要配合「单行模式」关闭，否则遇换行就断）。
替换为：- <code>\2（\1）
说明：
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
-
\2是提交信息主体，放前面更可读；\1是 hash，括号包裹作备注，符合常规日志习惯 - 别用
\t或多个空格对齐——不同 commit 信息长度差异大，纯靠视觉对齐反而难维护 - 如果某行没匹配上（比如空行或 merge 提交带
Merge:），它会原样保留，方便你肉眼扫一遍确认
批量清理冗余前缀，比如 feat:、chore(deps):
这类前缀语义重复（Markdown 列表本身已表达条目性），且风格不统一，删掉后更干净。但不能无差别删冒号——有些提交信息里有 URL 或版本号（如 Upgrade axios to v1.6.0）。
推荐两步走：
- 先删常见结构化前缀：
^(?:feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(?:\([^)]*\))?:\s*，替换为空。注意(?:\([^)]*\))?覆盖feat(api):这类带 scope 的情况 - 再处理残留空格：用
^\s*-\s+替换为-，统一列表项前导空格 - 别碰
Revert "或Merge branch这类特殊行——它们通常不含标准前缀，正则不会误伤，留着反而有助于回溯
遇到中文提交信息乱码或截断怎么办
Sublime 默认对非 ASCII 字符支持良好，但如果你看到 add 用户 或方块□，说明日志是从 Windows 的 cmd 或旧版 Git Bash 复制而来，用了 GBK 编码。
解决路径很直接：
- 不要从命令行窗口右键复制，改用
git log --pretty=format:"%h %s" | clip（Windows）或pbcopy（macOS）走剪贴板管道 - 在 Sublime 中粘贴前，确认右下角状态栏显示「UTF-8」；如果不是，点它 → 「Reopen with Encoding」→ 「UTF-8」
- 若已乱码，别用正则硬刷——先全选 →
Ctrl+Shift+P→ 输入「Convert to UTF-8」，再重做替换
真正容易被忽略的是：Git 自身对中文 commit message 的存储是 UTF-8，但某些 shell 的 LANG 设置（如 LANG=C）会让 git log 输出转义 HTML 实体。这时候得在命令里加 --no-decorate 和显式指定 --encoding=utf-8，不过 Sublime 里只需管好粘贴源和编辑器编码就够了。
