Cp 是做什么的？
在实现完成后，将此作为轻量级完成模式使用。
cp 是推送前的本地门禁：先验证，然后在当前分支上提交并推送预期的更改。
默认流程
- 检查：
git status- 当前分支
- 本次任务预期的文件
- 如有需要，检查最近的提交信息风格
- 运行仓库惯用的本地安全检查，优先于提交。
- 优先使用仓库原生命令，而非自行编造的命令。
- 优先运行最窄的安全检查：修改文件的 lint/格式化检查、受影响包测试或针对性构建。
- 如果仓库唯一可靠的检查是更广泛的，则运行更广泛的命令。
- 如果广泛的本地检查因预期更改集之外的不相关脏文件而失败，则停止并明确报告，而非修复或暂存那些无关文件。
- 仅显式暂存预期文件。
- 如果未提供提交信息，则生成一条简洁的、符合仓库风格的常规提交信息。
- 在当前分支上提交。
- 如果仓库或用户的工作流允许，可以直接提交到
main或master分支。 - 如果仓库明确要求使用短生命周期分支，则遵循该要求。
- 推送当前分支。
- 如果上游追踪缺少，则设置上游追踪后推送。
规则
- 绝不使用
git add .、git add -A或类似的广泛暂存命令。 - 绝不提交来自其他任务或会话的无关本地更改。
- 绝不意外提交秘密信息、
.env文件、凭据或生成的冗余文件。 - 绝不静默跳过验证；需说明运行了什么以及跳过了什么。
- 除非用户明确要求，绝不强制推送。
- 除非用户明确要求，绝不创建或要求 PR。
良好触发词
- "/cp"
- "커밋하고 푸시해줘"
- "메인에 올려"
- "이제 검증하고 바로 푸시해"
避免
- 如果用户明确只要求“仅提交”或“仅推送”，则不要使用此技能只执行其中一项操作。
- 不要推断有权推送当前分支以外的其他分支。
- 不要隐藏跳过或排除的文件；如果它们重要，应简要提及。
完成
返回：
- 推送的分支
- 验证是否运行或跳过
- 提交信息
- 提交哈希
- 故意排除的文件（如果有）