# dialectical-git-messages

> git生成

- Author: as3398145260-afk
- Repository: as3398145260-afk/skills
- Version: 20260122222037
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/as3398145260-afk/skills
- Web: https://mule.run/skillshub/@@as3398145260-afk/skills~dialectical-git-messages:20260122222037

---

---
name: dialectical-git-messages
description: git生成
---

---
name: dialectical-git-messages
description: git生成
---

---
name: dialectical-git-messages
description: 基于唯物辩证法的Git消息生成工具。使用辩证思维分析代码变更中的矛盾运动，生成高质量的Git Commit Message和Pull Request Description。
triggers: ["@gitmsg", "生成commit消息", "生成PR描述", "git commit message", "pull request description"]
---

# 辩证法Git消息生成器 (Dialectical Git Messages)

## 核心哲学

### 1. 物质决定意识 (Context is King)
- 拒绝“一刀切”的Git消息模板。一切消息生成必须基于代码变更的具体物质条件（变更类型、影响范围、业务价值、团队规范）。
- 没有绝对的“完美Git消息”，只有“在当前历史阶段最适合的Git消息”。

### 2. 对立统一规律 (Trade-off Analysis)
- Git消息生成的本质是管理矛盾（简洁性vs详细性，技术性vs业务性，个人理解vs团队协作）。
- 在生成消息前，必须识别当前的**主要矛盾**，并为了解决主要矛盾而果断牺牲次要矛盾。

### 3. 质量互变规律 (Scalability & Evolution)
- 预见Git消息的影响。当前的一条消息可能会影响未来团队对代码历史的理解，必须为未来的协作做好准备。
- 识别临界点（The Tipping Point），在过于简单的消息和过于冗长的消息之间找到平衡的“度”。

### 4. 否定之否定 (Critical Refinement)
- 初次生成的Git消息往往包含片面性。必须通过自我批判（检查完整性、准确性、可读性）来“扬弃”初稿，达到更高层级的协作效率。

## Git消息生成流程

### 阶段1: 唯物主义来源批判 (代码变更分析)

**核心任务：** 客观分析代码变更，收集真实数据

1. **变更类型识别**
   - 功能变更：新增功能、修改功能、删除功能
   - 修复变更：bug修复、安全修复
   - 文档变更：更新文档、添加注释
   - 重构变更：代码重构、性能优化
   - 其他变更：配置调整、依赖更新

2. **影响范围分析**
   - 单个文件变更
   - 多个文件变更
   - 单个模块变更
   - 跨模块变更
   - 影响核心功能
   - 影响非核心功能

3. **业务价值分析**
   - 直接业务价值：解决用户问题、提升用户体验
   - 间接业务价值：提高代码质量、降低维护成本
   - 长期业务价值：为未来功能奠定基础

### 阶段2: 矛盾分析与方案决断 (消息结构设计)

**核心任务：** 识别核心矛盾，确定消息结构

1. **矛盾识别**
   - 简洁性 vs 详细性：消息应该多简洁，又应该多详细？
   - 技术性 vs 业务性：消息应该面向技术人员，还是面向业务人员？
   - 个人理解 vs 团队协作：消息是方便个人记忆，还是方便团队理解？

2. **消息结构选择**
   - **Commit Message**：采用Angular Commit Message格式（类型+作用域+描述+正文+Footer）
   - **Pull Request Description**：采用结构化格式（标题+概述+变更内容+测试情况+影响范围+相关链接）

3. **消息侧重点确定**
   - 功能性变更：重点描述业务价值
   - 修复性变更：重点描述问题和解决方案
   - 重构性变更：重点描述改进点和影响
   - 文档性变更：重点描述文档更新内容

### 阶段3: 否定性测试与演进预判 (消息内容生成)

**核心任务：** 生成健壮的消息内容，预见未来影响

1. **消息内容生成**
   - **Commit Message**：生成符合规范的提交消息
   - **Pull Request Description**：生成详细的PR描述

2. **消息质量检查**
   - 完整性：是否包含所有必要信息？
   - 准确性：是否准确描述了代码变更？
   - 可读性：是否易于理解？
   - 一致性：是否符合团队规范？

3. **演进预判**
   - 未来团队成员是否能理解这条消息？
   - 这条消息是否能帮助未来的代码调试和维护？
   - 这条消息是否能适应团队规范的变化？

### 阶段4: 实践检验真理 (消息优化)

**核心任务：** 优化消息内容，验证效果

1. **消息优化**
   - 调整消息长度：确保简洁明了
   - 优化语言表达：使用清晰、准确的语言
   - 完善消息结构：确保符合规范

2. **消息验证**
   - 检查是否符合团队规范
   - 检查是否包含所有必要信息
   - 检查是否易于理解

3. **消息应用**
   - 将生成的消息应用到Git提交中
   - 将生成的消息应用到Pull Request中

### 阶段5: 否定之否定 (持续改进)

**核心任务：** 总结经验教训，持续改进消息生成

1. **消息效果评估**
   - 团队成员是否能理解生成的消息？
   - 生成的消息是否能帮助团队更好地协作？
   - 生成的消息是否能适应未来的需求变化？

2. **消息生成优化**
   - 基于反馈优化消息生成算法
   - 调整消息模板和结构
   - 改进消息生成流程

3. **团队能力提升**
   - 分享Git消息生成的最佳实践
   - 培训团队成员，提高Git消息编写能力
   - 建立Git消息生成的文化和规范

## Git Commit Message生成

### 1. 消息结构

**推荐格式：**
```
<类型>(<作用域>): <描述>

<正文>（可选）

<Footer>（可选）
```

**类型说明：**
- `feat`: 新功能
- `fix`: 修复bug
- `docs`: 文档更新
- `style`: 代码格式调整（不影响代码逻辑）
- `refactor`: 代码重构（不影响功能）
- `perf`: 性能优化
- `test`: 测试相关
- `build`: 构建或配置更改
- `ci`: CI/CD配置更改
- `chore`: 其他更改（不影响代码、构建或测试）
- `revert`: 回滚提交

**作用域说明：**
- 可选，用于指定变更的范围（如模块、组件、文件等）
- 例如：`feat(user): add login functionality`

**描述说明：**
- 简洁明了，不超过50个字符
- 使用命令式语气（如"add"而非"added"）
- 首字母小写，不使用句号结尾

**正文说明：**
- 可选，用于详细描述变更内容
- 每行不超过72个字符
- 解释"为什么这么做"，而不仅仅是"做了什么"

**Footer说明：**
- 可选，用于关联Issue、Breaking Changes等
- 关联Issue：`Closes #123`, `Fixes #456`
- Breaking Changes：`BREAKING CHANGE: <描述>`

### 2. 生成流程

1. **分析代码变更**
   - 识别变更类型（feat, fix, docs等）
   - 确定作用域（模块、组件、文件等）
   - 提取核心变更内容

2. **生成消息草稿**
   - 填写类型、作用域和描述
   - 根据需要添加正文和Footer

3. **优化消息内容**
   - 调整消息长度
   - 优化语言表达
   - 完善消息结构

4. **验证消息质量**
   - 检查是否符合规范
   - 检查是否包含所有必要信息
   - 检查是否易于理解

### 3. 示例

**简单示例：**
```
feat(user): add login functionality
```

**详细示例：**
```
fix(auth): resolve login failure for admin users

The login functionality was failing for admin users due to an incorrect permission check.
This fix corrects the permission check logic to properly handle admin users.

Closes #123
```

**带Breaking Changes的示例：**
```
refactor(api): change response format for user endpoints

BREAKING CHANGE: The user API endpoints now return a different JSON format.
Clients will need to update their code to handle the new format.

Closes #456
```

## Pull Request Description生成

### 1. 消息结构

**推荐格式：**
```
# <标题>

## 概述
<变更的简要概述，1-2句话>

## 变更内容
- 变更点1：详细描述
- 变更点2：详细描述
- 变更点3：详细描述

## 测试情况
- [ ] 单元测试已通过
- [ ] 集成测试已通过
- [ ] 手动测试已完成
- [ ] 性能测试已完成

## 影响范围
- 变更范围：模块、组件、文件等
- 影响功能：核心功能、非核心功能
- 兼容性：向后兼容、部分兼容、不兼容

## 相关链接
- Issue: #123
- 设计文档：[链接]
- 测试报告：[链接]

## 其他信息
<其他需要说明的信息>
```

### 2. 生成流程

1. **分析代码变更**
   - 识别变更类型和影响范围
   - 提取核心变更内容
   - 收集相关信息（Issue、设计文档等）

2. **生成PR描述草稿**
   - 填写标题和概述
   - 详细描述变更内容
   - 填写测试情况
   - 分析影响范围
   - 添加相关链接
   - 添加其他信息

3. **优化PR描述内容**
   - 调整描述长度
   - 优化语言表达
   - 完善描述结构

4. **验证PR描述质量**
   - 检查是否包含所有必要信息
   - 检查是否易于理解
   - 检查是否符合团队规范

### 3. 示例

```markdown
# Add user authentication functionality

## 概述
实现了基于JWT的用户认证功能，包括登录、注册、权限验证等核心功能。

## 变更内容
- 添加了User模型，包含用户名、邮箱、密码等字段
- 实现了JWT认证中间件，用于保护API端点
- 添加了登录和注册接口
- 实现了权限验证功能，支持不同角色的权限控制
- 更新了相关文档和测试用例

## 测试情况
- [x] 单元测试已通过
- [x] 集成测试已通过
- [x] 手动测试已完成
- [ ] 性能测试已完成

## 影响范围
- 变更范围：auth模块、user模块
- 影响功能：核心认证功能
- 兼容性：向后兼容

## 相关链接
- Issue: #123
- 设计文档：https://example.com/design/auth
- 测试报告：https://example.com/reports/auth

## 其他信息
- 需要更新客户端代码以支持新的认证机制
- 建议在发布前进行负载测试
```

## Git消息生成最佳实践

### 1. 针对不同变更类型的消息策略

**功能性变更**
- 重点描述业务价值
- 说明变更对用户的影响
- 关联相关需求或用户故事

**修复性变更**
- 描述问题的现象和根本原因
- 说明解决方案
- 关联相关Issue

**重构性变更**
- 说明重构的原因和目标
- 描述改进点和影响
- 说明是否影响现有功能

**文档性变更**
- 描述文档更新的内容和目的
- 说明更新对团队的价值

### 2. 针对不同影响范围的消息策略

**小范围变更**
- 保持简洁，重点描述变更内容
- 不需要过于详细的正文

**大范围变更**
- 提供详细的变更说明
- 解释变更的背景和目的
- 说明变更的影响范围

**核心功能变更**
- 提供详细的变更说明
- 说明变更的业务价值
- 描述测试情况

### 3. 针对不同团队规模的消息策略

**小团队（1-5人）**
- 可以相对简洁
- 可以使用团队内部的术语
- 重点关注个人理解

**中团队（6-20人）**
- 需要适中的详细程度
- 使用清晰的术语
- 平衡个人理解和团队协作

**大团队（20人以上）**
- 需要详细的变更说明
- 使用标准化的术语
- 重点关注团队协作

## 常见Git消息问题和解决方案

### 1. 消息过于简单

**问题：** 消息过于简单，无法理解变更内容

**根本原因：** 没有充分分析变更的影响和价值

**解决方案：**
- 增加消息的详细程度
- 说明变更的背景和目的
- 描述变更的影响范围

### 2. 消息过于冗长

**问题：** 消息过于冗长，难以快速理解

**根本原因：** 没有识别核心矛盾，包含了过多的次要信息

**解决方案：**
- 精简消息内容，聚焦核心变更
- 移除不必要的细节
- 使用清晰的结构和格式

### 3. 消息不清晰

**问题：** 消息使用模糊的语言，难以理解

**根本原因：** 没有使用准确、具体的语言

**解决方案：**
- 使用清晰、准确的语言
- 避免使用模糊的术语
- 提供具体的例子和细节

### 4. 消息不符合规范

**问题：** 消息不符合团队的Git消息规范

**根本原因：** 没有遵循团队的规范

**解决方案：**
- 学习并遵循团队的Git消息规范
- 使用工具辅助生成符合规范的消息
- 定期检查和更新团队规范

### 5. 消息缺乏业务价值

**问题：** 消息只描述了技术变更，没有说明业务价值

**根本原因：** 没有分析变更的业务影响

**解决方案：**
- 说明变更的业务背景和目的
- 描述变更对用户或业务的价值
- 关联相关的业务需求或用户故事

## Git消息生成工具推荐

### 1. 命令行工具
- **commitizen**: 交互式Commit Message生成工具
- **cz-conventional-changelog**: 符合Angular规范的Commit Message生成器
- **gitmoji-cli**: 带emoji的Commit Message生成工具

### 2. IDE插件
- **VS Code**: GitLens, Commit Message Editor
- **IntelliJ IDEA**: Git Commit Template, Conventional Commit
- **Eclipse**: Git Commit Template

### 3. Web工具
- **gitmessage.io**: 在线Commit Message生成工具
- **conventionalcommits.org**: 提供Commit Message规范和示例

## 技能使用指南

### 1. 如何生成高质量的Commit Message？

1. 分析代码变更的类型、影响范围和业务价值
2. 识别当前的主要矛盾
3. 选择合适的消息结构
4. 生成消息草稿
5. 优化消息内容
6. 验证消息质量
7. 提交消息

### 2. 如何生成高质量的Pull Request Description？

1. 分析代码变更的整体情况
2. 提取核心变更内容
3. 收集相关信息（Issue、设计文档等）
4. 生成PR描述草稿
5. 优化PR描述内容
6. 验证PR描述质量
7. 创建Pull Request

### 3. 如何适应不同团队的规范？

1. 了解团队的Git消息规范
2. 根据团队规范调整消息生成策略
3. 使用团队推荐的工具和模板
4. 定期更新对团队规范的理解

### 4. 如何持续改进Git消息质量？

1. 定期回顾和分析Git历史记录
2. 收集团队反馈
3. 优化消息生成策略
4. 分享最佳实践
5. 更新团队规范

## 结论

辩证法Git消息生成器不是一个具体的消息模板，而是一种思维方式和方法论。它要求我们用辩证的眼光看待Git消息生成，分析代码变更中的矛盾运动，识别核心问题，生成高质量的Git消息。

通过遵循这个流程，你可以生成符合项目需求的Git Commit Message和Pull Request Description，提高团队的协作效率，增强代码历史的可读性，为未来的代码维护和理解做好准备。

记住，Git消息是团队协作的重要组成部分，它不仅记录了代码变更，更记录了团队的协作历史和业务价值。只有掌握了辩证思维，才能在复杂的团队协作中生成最佳的Git消息，充分发挥Git的价值。