Back to Details

git-visual-squash-summary

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Visual Squash Summary

Git Visual Squash Summary

This skill turns a stack of commits into a curated grouped summary without touching the index, the worktree, or git history. It is the wording companion to 
git-visual-commits
: same opinionated emoji and prefix language, but non-mutating and optimized for the grouped summary shown beneath a PR title or in a squash-and-merge description field.
This skill is non-mutating: it inspects history and diffs, then returns grouped summary lines only.
此技能可将一系列提交转换为经过整理的分组总结，且不会对暂存区、工作区或Git历史造成任何修改。它是
git-visual-commits
的措辞配套工具：使用相同的专属表情符号和前缀语言，但为非修改型，针对PR标题下方显示的分组总结或压缩合并描述字段进行了优化。
此技能为非修改型：它仅检查历史记录和差异，然后返回分组总结条目。

Non-Negotiable Rules

不可协商规则

  • Never stage, commit, amend, rebase, or otherwise mutate git state.
  • Read 
    references/commit-language.md
    before choosing any emoji or prefix.
  • Keep 
    references/commit-language.md
    byte-for-byte aligned with the 
    git-visual-commits
    copy; the validator and CI both enforce that sync contract.
  • Preserve technical identifiers exactly where possible.
  • Group by intent, not chronology.
  • Retain only distinct high-signal change groups.
  • Merge repetition and overlapping commits into their parent group.
  • Drop low-signal noise such as typo-only, fixup-only, and trivial follow-up commits unless they materially change a retained group.
  • Prefer strong concrete verbs and concise phrasing.
  • Favor readable GitHub and terminal output over cleverness.
  • Avoid vague filler such as "various improvements".
  • Do not treat the result as a changelog entry or a dump of commit subjects.
  • Do not invent unsupported changes.
  • Return grouped lines only, never a title or body.
  • Keep every output line at or below 72 characters.
  • 绝不执行暂存、提交、修正、变基或任何其他会修改Git状态的操作。
  • 在选择任何表情符号或前缀前，请阅读
    references/commit-language.md
    。
  • 确保
    references/commit-language.md
    与
    git-visual-commits
    的副本完全一致；验证器和CI都会强制执行此同步约定。
  • 尽可能精准保留技术标识符。
  • 按意图而非时间顺序分组。
  • 仅保留独特的高信号变更组。
  • 将重复和重叠的提交合并到对应的父组中。
  • 剔除低信号噪声，如仅修正拼写错误、仅修复问题或无关紧要的后续提交，除非它们对保留的组产生实质性影响。
  • 优先使用明确的实义动词和简洁措辞。
  • 优先保证GitHub和终端输出的可读性，而非追求花哨。
  • 避免使用“各类改进”这类模糊的填充语。
  • 不要将结果视为变更日志条目或提交主题的堆砌。
  • 不要编造未实际发生的变更。
  • 仅返回分组条目，不要标题或正文内容。
  • 确保每条输出行不超过72个字符。

Workflow

工作流程

Step 1: Resolve the commit set

步骤1：确定提交集

Use the most explicit source the user gave you:
  • If the user provided a commit range, branch comparison, PR branch, or base branch, use that.
  • Otherwise, try the current branch against its upstream merge-base.
  • If no upstream is configured, try 
    main
    , then 
    master
    .
  • If you still cannot determine a safe comparison point, stop and ask for the range or base branch instead of guessing.
Helpful read-only commands:
bash
git status --short --branch
git rev-parse --abbrev-ref HEAD
git rev-parse --abbrev-ref --symbolic-full-name @{upstream}
git merge-base HEAD @{upstream}
git merge-base HEAD main
git merge-base HEAD master
使用用户提供的最明确的来源：
  • 如果用户提供了提交范围、分支对比、PR分支或基准分支，则使用该来源。
  • 否则，尝试将当前分支与其上游合并基准进行对比。
  • 如果未配置上游分支，尝试
    main
    ，再尝试
    master
    。
  • 如果仍无法确定安全的对比点，请停止操作并询问用户提交范围或基准分支，不要猜测。
实用的只读命令：
bash
git status --short --branch
git rev-parse --abbrev-ref HEAD
git rev-parse --abbrev-ref --symbolic-full-name @{upstream}
git merge-base HEAD @{upstream}
git merge-base HEAD main
git merge-base HEAD master

Step 2: Inspect the actual changes

步骤2：检查实际变更

Do not summarize from commit subjects alone when the range is noisy or long. Inspect both history and net effect so the final message reflects what actually changed.
Helpful read-only commands:
bash
git log --reverse --oneline <range>
git log --reverse --stat --format=medium <range>
git diff --stat <base>..HEAD
git diff <base>..HEAD
当提交范围杂乱或较长时，不要仅根据提交主题进行总结。同时检查历史记录和实际影响，确保最终信息能准确反映实际发生的变更。
实用的只读命令：
bash
git log --reverse --oneline <range>
git log --reverse --stat --format=medium <range>
git diff --stat <base>..HEAD
git diff <base>..HEAD

Step 3: Collapse to semantic intent

步骤3：提炼为语义意图

Before drafting the summary, reduce the range into the smallest truthful set of retained groups:
  • Collapse repeated fixups into the group they support.
  • Merge overlapping commits into the clearest final intent.
  • Prefer the net effect over the path taken to get there.
  • Drop typo-only, whitespace-only, and other low-signal cleanup unless it materially changes a retained group.
  • Keep documentation-only work separate in your reasoning, but include it only when it represents a meaningful unique change.
  • Highlight distinct meaningful efforts instead of forcing one dominant umbrella theme.
Ask yourself: "If I had to explain the real work in 2-5 compact lines, what are the distinct changes that mattered?"
在起草总结前，将提交范围精简为最真实的最小保留组集合：
  • 将重复的修复提交合并到对应的支持组中。
  • 将重叠的提交合并为最清晰的最终意图。
  • 优先体现实际影响，而非实现过程。
  • 剔除仅修正拼写错误、仅调整空白字符或其他低信号的清理操作，除非它们对保留的组产生实质性影响。
  • 在思考过程中将仅涉及文档的工作单独区分，但仅当它代表有意义的独特变更时才将其包含进来。
  • 突出不同的有意义工作，而非强行归为一个大主题。
问问自己：“如果我必须用2-5条简洁的条目解释实际完成的工作，哪些是重要的独特变更？”

Step 4: Draft the grouped summary

步骤4：起草分组总结

Use this exact output shape:
text
<emoji> <optional-prefix> <short summary line>
<emoji> <optional-prefix> <short summary line>
<emoji> <optional-prefix> <short summary line>
Formatting rules:
  • Return grouped lines only. Do not prepend a title.
  • Use one line per retained high-signal group.
  • Keep every line at or below 72 characters.
  • Use the shared prefix and emoji guidance in 
    references/commit-language.md
    .
  • Do not add bullets, numbering, a body, rationale paragraph, or chronology recap.
  • Do not append weak glue like "with", "plus", or "and" just to force several top-level intents into one line.
  • Favor clean lines that scan well in GitHub and terminal views.
  • Condense to the real grouped effort without dropping important identifiers.
使用以下精确的输出格式：
text
<emoji> <可选前缀> <简短总结条目>
<emoji> <可选前缀> <简短总结条目>
<emoji> <可选前缀> <简短总结条目>
格式规则：
  • 仅返回分组条目。不要添加标题前缀。
  • 每个保留的高信号组对应一条条目。
  • 确保每条条目不超过72个字符。
  • 使用
    references/commit-language.md
    中的共享前缀和表情符号指南。
  • 不要添加项目符号、编号、正文、理由段落或时间顺序回顾。
  • 不要为了将多个顶级意图合并到一条条目而添加“with”“plus”或“and”这类无力的连接词。
  • 优先保证在GitHub和终端视图中易于浏览的简洁条目。
  • 在不遗漏重要标识符的前提下，精简为实际的分组工作内容。

Step 5: Return the grouped lines only

步骤5：仅返回分组条目

Output the finished grouped summary lines and stop. Do not run 
git commit
, 
git bot commit
, 
git add
, or any other mutating command.
输出完成的分组总结条目后停止操作。不要运行
git commit
、
git bot commit
、
git add
或任何其他修改型命令。

Good Output Characteristics

优秀输出特征

  • Reads like a curated grouped summary, not a stitched list of commits.
  • Reads like a curated, human-written condensed history.
  • Uses the same emoji and prefix language as 
    git-visual-commits
    .
  • Keeps distinct meaningful efforts on separate lines.
  • Drops noisy fixups and typo-only churn instead of preserving them.
  • Fits naturally beneath a PR title or in compact GitHub and terminal views.
  • Includes only claims supported by the inspected diff.
  • Preserves names such as commands, types, files, APIs, flags, and paths.
  • Keeps each line compact enough to scan at a glance.
  • 读起来像是经过整理的分组总结，而非拼接的提交列表。
  • 读起来像是经过整理的、人工编写的精简历史记录。
  • 使用与
    git-visual-commits
    相同的表情符号和前缀语言。
  • 将不同的有意义工作放在单独的条目上。
  • 剔除杂乱的修复提交和仅修正拼写错误的无效操作，而非保留它们。
  • 自然适配PR标题下方或紧凑的GitHub和终端视图。
  • 仅包含经检查的差异所支持的内容。
  • 保留命令、类型、文件、API、标志和路径等名称。
  • 每条条目足够简洁，便于快速浏览。

Bad Output Characteristics

糟糕输出特征

  • Changelog-like wording or release-note phrasing.
  • Chronological narration of each commit in order.
  • Dumping raw commit subjects line by line.
  • Collapsing several unique top-level efforts into one stitched sentence.
  • Filler such as "misc cleanup", "various improvements", or "updates".
  • Losing or renaming important technical identifiers unnecessarily.
  • Inventing refactors, fixes, or docs changes not supported by the diff.
  • Adding a title, body, bullets, or numbered outline.
  • Exceeding 72 characters on any output line.
  • 采用变更日志式措辞或发布说明式表述。
  • 按时间顺序逐一叙述每个提交。
  • 逐行堆砌原始提交主题。
  • 将多个独特的顶级工作合并为一个拼接的句子。
  • 使用“杂项清理”“各类改进”或“更新”这类填充语。
  • 不必要地遗漏或重命名重要的技术标识符。
  • 编造未被差异支持的重构、修复或文档变更。
  • 添加标题、正文、项目符号或编号大纲。
  • 任何条目超过72个字符。