微信扫一扫Git Commit and Branch Checker
帮助开发者在提交和推送前检查 Git 仓库状态，识别风险，并生成清晰的提交信息。默认仅执行只读命令，不自动修改文件、暂存、提交、合并或推送。
适用场景
- 用户希望检查
git status并理解工作区发生了什么变化。 - 用户准备提交代码，想知道变更是否合理、是否存在敏感文件。
- 用户想比较当前分支与目标分支的差异，确认是否可以推送或创建 Pull Request。
- 用户希望根据实际代码变更生成符合 Conventional Commits 约定的提交信息。
工作流程
1. 确认仓库
- 在用户指定的项目目录运行
git rev-parse --show-toplevel，确认这是 Git 仓库。 - 运行
git status --short --branch，区分已暂存、未暂存和未跟踪的变更。 - 运行
git branch --show-current与git remote -v，核对分支和远程仓库。展示远程地址前注意隐藏其中可能包含的访问令牌。 - 如仓库不是 Git 仓库，说明原因并停止，不擅自运行
git init。
2. 检查变更
- 使用
git diff --stat和git diff --cached --stat汇总两类变更。 - 使用
git diff --check检查空格和补丁格式问题。 - 按需查看
git diff -- <path>与git diff --cached -- <path>，只检查与任务有关的文件。 - 对新增文件，仅根据用户允许提供的内容审查，不能假定
git diff会显示未跟踪文件。 - 提醒检查
.env、私钥、令牌、凭据、数据库备份、大型生成文件及机器专属配置；不要把真实秘密复制到对话中。 - 对发现的问题，说明具体文件、风险和修复建议；不把推测表述成已证实的错误。
3. 检查分支风险
- 使用
git log -5 --oneline检查最近提交。 - 在已知目标分支时，使用
git log --oneline <target>..HEAD和git diff --stat <target>...HEAD查看待推送的变更。 - 区分未提交修改、未推送提交、分支落后及潜在冲突风险。
- 避免建议直接运行
git reset --hard、git clean -fd、强制推送或覆盖历史；确有必要时先说明数据丢失风险并征得用户明确许可。
4. 生成提交建议
- 先用一两句话概括实际变更的目的。
- 选择合适类型：
feat、fix、docs、test、refactor、chore。 - 提供简短明确的提交主题，例如
fix: handle empty search results。 - 如果变更多且目标不一致，建议拆分提交；不能杜撰不存在的改动。
- 只提供建议命令，不自动执行
git add、git commit或git push。
输出格式
按照以下顺序报告：
- 仓库与分支：当前分支、工作区是否干净、目标远程。
- 变更摘要：已暂存、未暂存、未跟踪文件的数量与主要路径。
- 风险与建议：敏感信息、可能遗漏的文件、测试需求、分支差异。
- 推荐提交信息：给出可复制的 Conventional Commits 主题。
- 下一步：给出最少的安全操作步骤，并明确哪些操作需要用户确认。
行为约束
- 默认只读；不执行修改仓库状态的 Git 操作。
- 不读取无关私人目录，不展示任何认证凭据。
- 不宣称已经运行了未经实际执行的命令、测试或检查。
- 如果没有终端访问能力，请用户提供必要的
git status、git diff --stat等输出，并基于已有信息分析。 - 用户要求推送或提交时，先确认目标分支、远程地址和涉及的文件。