git-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Review — 工作复盘工具

Git Review — Work Retrospective Tool

分析当前 git 仓库指定时间范围内的所有 commits,生成结构化的工作复盘报告。适用于代码、文档、设计、调研等任何 git 管理的内容。
Analyze all commits within a specified time range in the current git repository and generate a structured work retrospective report. Suitable for any content managed by git, such as code, documents, designs, research, etc.

When to Use

When to Use

当用户请求以下操作时触发:
  • "复盘一下" / "今天做了什么" / "工作总结"
  • "review commits" / "git 回顾" / "daily review"
  • "这周干了什么" / "最近3天的工作" / "retrospective"
  • 任何涉及回顾 git 提交历史并进行分析的请求
Trigger when the user requests the following operations:
  • "Do a retrospective" / "What did I do today" / "Work summary"
  • "review commits" / "git review" / "daily review"
  • "What did I do this week" / "Work in the last 3 days" / "retrospective"
  • Any request involving reviewing git commit history and conducting analysis

Phase 0: 解析输入 — 确定时间范围

Phase 0: Parse Input — Determine Time Range

根据用户输入确定分析的时间范围:
默认值:昨天 22:00 到当前时间(覆盖跨午夜的工作段)
自然语言映射
用户输入--after--before
今天 / today今天 00:00now
昨天 / yesterday昨天 00:00昨天 23:59
这周 / this week本周一 00:00now
最近N天 / last N daysN天前 00:00now
具体日期 (如 2月20日)该日 00:00该日 23:59
日期范围 (如 2/20-2/23)起始日 00:00结束日 23:59
默认(无指定)昨天 22:00now
使用
date
命令计算具体时间戳,转换为 git log 可用的格式(如
2026-02-22T22:00:00
)。
Determine the analysis time range based on user input:
Default Value: 22:00 yesterday to current time (covers work segments spanning midnight)
Natural Language Mapping:
User Input--after--before
Today / today00:00 todaynow
Yesterday / yesterday00:00 yesterday23:59 yesterday
This week / this week00:00 Monday of this weeknow
Last N days / last N days00:00 N days agonow
Specific date (e.g., Feb 20)00:00 on that date23:59 on that date
Date range (e.g., 2/20-2/23)00:00 on the start date23:59 on the end date
Default (no specification)22:00 yesterdaynow
Use the
date
command to calculate the specific timestamp and convert it to a format usable by git log (e.g.,
2026-02-22T22:00:00
).

Phase 1: 数据采集

Phase 1: Data Collection

前置检查:先运行
git rev-parse --is-inside-work-tree
确认当前目录是 git 仓库。如果不是,告知用户并停止。
顺序执行以下 5 条命令(本地操作,无需并行):
Pre-check: First run
git rev-parse --is-inside-work-tree
to confirm the current directory is a git repository. If not, inform the user and stop.
Execute the following 5 commands in sequence (local operation, no parallel execution required):

1. 完整提交记录

1. Complete Commit History

bash
git log --after="{after}" --before="{before}" --format="%H|%an|%ai|%s|%b|||" --name-status
如果结果为空,必须立即停止所有后续步骤。不要尝试扩大时间范围、不要查找最近的提交、不要自行调整参数继续分析。只需:
  1. 告知用户该时间范围内无提交
  2. 展示最近 5 条提交的时间,帮助用户选择合适的范围
  3. 建议用户指定时间范围(如"复盘昨天"、"复盘 2/22"、"最近3天")
  4. 等待用户下一步指示
bash
git log --after="{after}" --before="{before}" --format="%H|%an|%ai|%s|%b|||" --name-status
If the result is empty, must immediately terminate all subsequent steps. Do not attempt to expand the time range, do not look for recent commits, do not adjust parameters on your own to continue analysis. Only need to:
  1. Inform the user that there are no commits within this time range
  2. Display the timestamps of the last 5 commits to help the user select an appropriate range
  3. Suggest the user specify a time range (e.g., "retrospect yesterday", "retrospect 2/22", "last 3 days")
  4. Wait for the user's next instruction

2. 提交统计

2. Commit Statistics

bash
git log --after="{after}" --before="{before}" --stat --format="%H %s"
bash
git log --after="{after}" --before="{before}" --stat --format="%H %s"

3. 时间段整体变更统计

3. Overall Change Statistics for Time Period

bash
git diff --stat $(git log --after="{after}" --before="{before}" --format="%H" | tail -1)^..$(git log --after="{after}" --before="{before}" --format="%H" | head -1)
如果只有一条提交,使用
git show --stat {hash}
替代。
bash
git diff --stat $(git log --after="{after}" --before="{before}" --format="%H" | tail -1)^..$(git log --after="{after}" --before="{before}" --format="%H" | head -1)
If there is only one commit, use
git show --stat {hash}
instead.

4. 分支信息

4. Branch Information

bash
git branch -a --sort=-committerdate | head -20
bash
git branch -a --sort=-committerdate | head -20

5. 当前未完成工作

5. Current Unfinished Work

bash
git status --short && echo "---STASH---" && git stash list
bash
git status --short && echo "---STASH---" && git stash list

Phase 2: 七维度分析

Phase 2: Seven-Dimension Analysis

基于采集到的数据,逐一完成以下分析。
Based on the collected data, complete the following analyses one by one.

维度 1: 工作总结

Dimension 1: Work Summary

  • 将 commits 按逻辑主题分组(而非简单按时间排列)
  • 用叙述式语言总结每组工作内容,说明做了什么、为什么做
  • 附上提交时间线表格:
    | 时间 | Hash (短) | 提交信息 |
  • Group commits by logical themes (instead of simply chronological order)
  • Summarize the content of each group in narrative language, explaining what was done and why
  • Attach a commit timeline table:
    | Time | Short Hash | Commit Message |

维度 2: 变更类型分布

Dimension 2: Change Type Distribution

按文件后缀和路径将变更分为以下类型,统计各类文件数和行数变更:
类型匹配规则
代码
.go
,
.py
,
.js
,
.ts
,
.java
,
.rs
,
.c
,
.cpp
,
.swift
,
.kt
测试路径含
test
/
spec
/
_test
,或文件名含
test
/
spec
文档
.md
,
.txt
,
.rst
,
.adoc
,
.doc
配置
.yaml
,
.yml
,
.json
,
.toml
,
.ini
,
.env
,
Dockerfile
,
Makefile
设计/调研路径含
design
/
research
/
rfc
/
proposal
/
audit
/
review
依赖
go.mod
,
go.sum
,
package.json
,
package-lock.json
,
requirements.txt
,
Cargo.toml
,
Gemfile
其他以上都不匹配的文件
输出分类表格和饼图式占比。
Classify changes into the following types based on file suffixes and paths, and count the number of files and line changes for each type:
TypeMatching Rules
Code
.go
,
.py
,
.js
,
.ts
,
.java
,
.rs
,
.c
,
.cpp
,
.swift
,
.kt
, etc.
TestingPath contains
test
/
spec
/
_test
, or filename contains
test
/
spec
Documentation
.md
,
.txt
,
.rst
,
.adoc
,
.doc
Configuration
.yaml
,
.yml
,
.json
,
.toml
,
.ini
,
.env
,
Dockerfile
,
Makefile
Design/ResearchPath contains
design
/
research
/
rfc
/
proposal
/
audit
/
review
Dependencies
go.mod
,
go.sum
,
package.json
,
package-lock.json
,
requirements.txt
,
Cargo.toml
,
Gemfile
OthersFiles that do not match any of the above
Output a classification table and pie-chart style proportion.

维度 3: 工作节奏

Dimension 3: Work Rhythm

  • 绘制提交时间线(用文本表示,如每小时一格)
  • 识别 Flow Session:连续提交间隔 < 30 分钟视为同一 session
  • 统计:首次提交时间、末次提交时间、总跨度、session 数、最长 session、最长间隔
  • 如果只有 1 条提交,跳过节奏分析,仅记录提交时间
  • Draw a commit timeline (represented in text, e.g., one grid per hour)
  • Identify Flow Sessions: consecutive commits with intervals < 30 minutes are considered the same session
  • Statistics: first commit time, last commit time, total span, number of sessions, longest session, longest interval
  • If there is only 1 commit, skip rhythm analysis and only record the commit time

维度 4: 提交实践评估

Dimension 4: Commit Practice Evaluation

对提交习惯进行 1-5 分评分:
评估项5分标准1分标准
Message 质量清晰描述 what + why模糊或无意义 (如 "update", "fix")
粒度 (Granularity)每次提交是独立的逻辑单元巨型提交混合多个不相关改动
Conventional Commits遵循
type(scope): description
无任何规范
给出每项的评分、好的示例(来自实际提交)和可改进的示例。
Score commit habits on a scale of 1-5:
Evaluation Item5-point Standard1-point Standard
Message QualityClearly describes what + whyVague or meaningless (e.g., "update", "fix")
GranularityEach commit is an independent logical unitGiant commit mixing multiple unrelated changes
Conventional CommitsFollows
type(scope): description
No adherence to any specification
Provide the score for each item, good examples (from actual commits), and examples for improvement.

维度 5: 技术决策识别

Dimension 5: Technical Decision Identification

扫描变更内容,识别以下类型的技术决策:
  • 新依赖引入:依赖文件的新增项
  • 架构变更:新目录结构、新模块、接口变更
  • 重构:大量文件重命名/移动、函数签名变更
  • 安全相关:涉及 auth、token、secret、permission 的改动
  • API 变更:路由、端点、schema 的修改
每项列出具体 commit 和影响评估。如果没有识别到技术决策,简要说明。
Scan the change content to identify the following types of technical decisions:
  • New Dependency Introduction: New entries in dependency files
  • Architecture Change: New directory structure, new modules, interface changes
  • Refactoring: A large number of file renames/moves, function signature changes
  • Security-Related: Changes involving auth, token, secret, permission
  • API Change: Modifications to routes, endpoints, schema
List specific commits and impact assessments for each item. If no technical decisions are identified, briefly explain.

维度 6: 完成度检查

Dimension 6: Completeness Check

以 checklist 格式检查:
  • 是否有未提交的改动(
    git status
  • 是否有 stash 中的暂存工作
  • 新增代码中是否包含
    TODO
    /
    FIXME
    /
    HACK
    /
    XXX
    注释
  • 新增代码文件是否有配套测试文件(检查同名
    _test
    文件是否存在)
对每项给出 Pass/Warning/Info 标记和具体内容。
Check in checklist format:
  • Are there uncommitted changes (
    git status
    )
  • Are there stashed works in stash
  • Does the new code include
    TODO
    /
    FIXME
    /
    HACK
    /
    XXX
    comments
  • Does the new code file have a corresponding test file (check if a
    _test
    file with the same name exists)
Mark each item with Pass/Warning/Info and specific content.

维度 7: 改进建议

Dimension 7: Improvement Suggestions

基于以上 6 个维度的分析结果,给出 3-5 条可操作的改进建议。每条建议需要:
  • 引用具体的分析数据作为证据
  • 提出明确的行动项
  • 说明预期效果
Based on the analysis results of the above 6 dimensions, provide 3-5 actionable improvement suggestions. Each suggestion needs:
  • Cite specific analysis data as evidence
  • Propose clear action items
  • Explain expected outcomes

Phase 3: 输出报告

Phase 3: Output Report

按以下格式输出完整报告:
markdown
undefined
Output the complete report in the following format:
markdown
undefined

Git 工作复盘

Git Work Retrospective

{时间范围} | {仓库名} | {提交数} commits | {文件变更数} files | +{新增行} -{删除行}
{Time Range} | {Repository Name} | {Number of Commits} commits | {Number of Changed Files} files | +{Added Lines} -{Deleted Lines}

核心发现

Key Findings

  1. ...
  2. ...
  3. ... (3-5 条要点)
  1. ...
  2. ...
  3. ... (3-5 key points)

1. 工作总结

1. Work Summary

{叙述式总结}
{Narrative summary}

提交时间线

Commit Timeline

时间Hash提交信息
.........
TimeHashCommit Message
.........

2. 变更类型分布

2. Change Type Distribution

类型文件数占比增删行数
............
{分析说明}
TypeNumber of FilesProportionLine Changes (Add/Delete)
............
{Analysis Description}

3. 工作节奏

3. Work Rhythm

  • 首次提交: ...
  • 末次提交: ...
  • 总跨度: ...
  • Flow Sessions: ... 个
  • 最长 session: ...
  • 最长间隔: ...
{时间线可视化}
  • First Commit: ...
  • Last Commit: ...
  • Total Span: ...
  • Flow Sessions: ... sessions
  • Longest Session: ...
  • Longest Interval: ...
{Timeline Visualization}

4. 提交实践评估

4. Commit Practice Evaluation

评估项评分说明
Message 质量⭐×N...
提交粒度⭐×N...
Conventional Commits⭐×N...
好的示例: ... 可改进: ...
Evaluation ItemScoreDescription
Message Quality⭐×N...
Commit Granularity⭐×N...
Conventional Commits⭐×N...
Good Examples: ... Areas for Improvement: ...

5. 技术决策

5. Technical Decisions

{决策列表,每项含 commit 引用和影响评估}
{List of decisions, each with commit reference and impact assessment}

6. 完成度检查

6. Completeness Check

  • [x/!/ ] 未提交改动: ...
  • [x/!/ ] Stash 暂存: ...
  • [x/!/ ] TODO/FIXME: ...
  • [x/!/ ] 测试配套: ...
  • [x/!/ ] Uncommitted Changes: ...
  • [x/!/ ] Stashed Work: ...
  • [x/!/ ] TODO/FIXME: ...
  • [x/!/ ] Test Coverage: ...

7. 改进建议

7. Improvement Suggestions

  1. {建议标题} — {具体内容}(证据:{引用分析数据})
  2. ...
  3. ...

将报告保存为 `git-review-{date}.md` 到当前工作目录,其中 `{date}` 为当天日期(如 `2026-02-23`)。
  1. {Suggestion Title} — {Specific Content} (Evidence: {Cited Analysis Data})
  2. ...
  3. ...

Save the report as `git-review-{date}.md` in the current working directory, where `{date}` is the current date (e.g., `2026-02-23`).

Edge Cases

Edge Cases

  • 无提交:Phase 1 第 1 步检测到空结果后,立即终止流程——展示最近 5 条提交时间供参考,提示用户重新指定范围。禁止自行扩大时间范围或继续后续 Phase
  • 单条提交:正常生成报告,但跳过维度 3(工作节奏)的 session 分析,简化为仅记录提交时间
  • 非 git 仓库:Phase 1 前置检查失败,提示用户当前目录不是 git 仓库
  • 二进制文件:仅在文件列表中标注为二进制,跳过行数统计,不尝试 diff 分析
  • 超大时间范围(>100 commits):正常分析,但在维度 1 中按主题分组时做更高层次的归纳,避免报告过长
  • No Commits: After detecting an empty result in Step 1 of Phase 1, immediately terminate the process — display the timestamps of the last 5 commits for reference, and prompt the user to re-specify the range. Prohibited to expand the time range on your own or proceed to subsequent Phases
  • Single Commit: Generate the report normally, but skip the session analysis in Dimension 3 (Work Rhythm), simplify to only record the commit time
  • Non-git Repository: Pre-check in Phase 1 fails, prompt the user that the current directory is not a git repository
  • Binary Files: Only mark as binary in the file list, skip line count statistics, do not attempt diff analysis
  • Oversized Time Range (>100 commits): Analyze normally, but perform higher-level induction when grouping by theme in Dimension 1 to avoid overly long reports