Git原始提交哈希必须严格为40位小写十六进制字符，正则表达式为^[a-f0-9]{40}$，需配合trim、小写归一化及整串锚定校验。
Git 提交哈希值（commit hash）默认是 40 位十六进制字符串，由 SHA-1 算法生成。虽然 Git 支持缩写（如前 7 位），但原始完整哈希必须严格满足：长度为 40、仅含小写 a–f 和 0–9 字符。正则表达式是最轻量、高效的方式完成这一校验。
匹配完整原始 Git 哈希的标准正则
校验原始提交哈希的核心要求是：精确 40 位、全小写十六进制字符、无空格或前缀。对应正则表达式为：
^[a-f0-9]{40}$
说明：
- ^ 表示字符串开头，防止前缀干扰（如 "hash: abc..."）
- [a-f0-9] 匹配单个小写字母 a–f 或数字 0–9
- {40} 要求恰好重复 40 次（不是 ≥40 或 ≤40）
- $ 表示字符串结尾，防止后缀干扰（如 "...def0123\n"）
区分原始哈希与缩写哈希的校验逻辑
Git CLI 允许使用 7～40 位缩写（只要不冲突），但“原始哈希”特指完整 40 位。若需同时支持缩写校验（例如用于输入提示），可拆分为两个模式：
- 原始哈希（严格）：^[a-f0-9]{40}$
- 合法缩写（宽松）：^[a-f0-9]{7,40}$（注意：仍需确保无大写，否则可能误判）
实践中建议优先用严格模式校验“原始值”，缩写场景单独处理，并在业务层补充歧义检查（如调用 git rev-parse --verify <short></short> 确认是否唯一）。
常见校验陷阱与规避方法
实际使用中容易忽略的细节会导致误判：
-
大小写敏感：Git 内部存储和多数 CLI 输出为小写，但用户可能粘贴大写哈希（如
ABCD123...）。建议先转小写再校验，或改用 ^[a-fA-F0-9]{40}$ 并额外验证是否全小写（若协议强制要求小写） -
空白字符干扰：用户复制时常带换行或空格。务必在正则前对输入做
.trim()（JS）或.strip()（Python） -
前缀混淆：如日志中出现
commit abcdef0123456789...。此时不能只查子串，而要用 ^ 和 $ 锚定整字符串；若需从文本中提取，改用 \b[a-f0-9]{40}\b（配合单词边界）
各语言中的典型用法示例
正则本身跨语言通用，关键在正确调用：
-
JavaScript：
/^[a-f0-9]{40}$/.test(hash.trim()) -
Python：
re.fullmatch(r'[a-f0-9]{40}', hash.strip()) is not None -
Shell（grep）：
echo "$hash" | grep -qxE '[a-f0-9]{40}'（-x等价于 ^...$，-E启用扩展正则） -
Go：
regexp.MatchString(`^[a-f0-9]{40}$`, strings.TrimSpace(hash))
不复杂但容易忽略：始终 trim + 严格锚定 + 小写归一化，三者缺一不可。
