busic-git-commit

何时使用

• 准备提交代码，但想先确认当前仓库的 Git 事实和提交格式
• 需要给改动写清晰、可回溯的 commit message
• 需要避免把无关文件、危险命令或旧分支流程带进来

先看这些真源

• docs/20-workflows/dev-workflow.md
• docs/20-workflows/release-workflow.md
• .github/workflows/ci.yml
• scripts/release.py

当前 Git 事实

• 当前长期分支事实以 main 为准
• 不要默认仓库存在或依赖 develop
• 发布标签格式是 vX.Y.Z
• 版本号和发布动作的详细规则交给 busic-version-management 与 busic-release

提交信息格式

<type>(<scope>): <subject>

常用 type：

• feat：新增功能
• fix：Bug 修复
• refactor：重构
• docs：文档更新
• test：测试相关
• chore：工具、构建、依赖或辅助脚本

示例：

feat(playlist): 添加歌单排序
fix(player): 修复播放暂停后进度条不同步
docs(skills): 重构本地skills结构

推荐提交流程

1. 用 git status --short 看清楚工作区
2. 只 stage 本次任务相关文件，优先 git add <path>
3. 提交前跑最低验证：

flutter analyze
flutter test

4. 再执行提交：

git commit -m "type(scope): subject"

Agent 执行时，本地只读 Git 如 git status、git log、git diff 通常可先在沙箱内尝试；git add、git commit、git push 等写入型或远程 Git 通常需要提权到沙箱外。完整分类见 busic-harness-workflow。

明确禁止

• 不要用 git add . 把无关改动一锅端走
• 不要默认使用 git reset --hard、git checkout -- 这类破坏性命令
• 不要为了迁就旧文档而构造 develop -> main 的假流程
• 不要把功能改动、版本 bump、发布资产改名混成一个难以审查的提交

相关 Skill

• busic-main-workflow
• busic-testing
• busic-version-management
• busic-release
• busic-harness-workflow