القائمة
Git初始化新仓库、提交与推送规范指南。执行git init/commit/push前必须调用，确保遵循用户审核、原子提交、精准文件选择等原则。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
结构化代码审查框架，覆盖代码质量、安全性、性能和测试标准。适用于 PR 审查、代码质量检查、安全审计、性能分析等场景。
GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line.
استنادا إلى تصنيف SOC المهني
| name | git-commit-push |
| description | Git初始化新仓库、提交与推送规范指南。执行git init/commit/push前必须调用，确保遵循用户审核、原子提交、精准文件选择等原则。 |
本skill总结了Git初始化新仓库、提交与推送的最佳实践、核心原则和工作流规范，所有操作都基于实际错误案例总结。
在 git init 之后、第一次 git add 之前，必须创建 .gitignore 文件，排除不需要版本控制的文件。
应该忽略的内容：
temp/*.log*.test.*build/、dist/、coverage/.vscode/、.idea/node_modules/❌ 禁止在本地落后于远端的情况下创建新分支或提交 ✅ 创建新分支前先执行
git fetch检查本地是否落后 ✅ 发现落后时先执行git pull --rebase再操作无远端仓库（纯本地仓库）时跳过此步骤。典型错误场景：本地 main 已落后远端多个 commit 就直接创建新分支，导致分支基于过时代码。
git pull --rebase保持线性历史，避免多余的 merge commit。
❌ 禁止擅自执行 git commit 或 git push ✅ 提交前必须执行基本测试通过 ✅ 每次提交前必须征询用户意见 ✅ 让用户审核 commit message 内容 ✅ 如果没有特别说明，用户的同意只针对一次操作，下次需重新询问
❌ 禁止使用 git add -A 或 git add . ✅ 明确指定要提交的文件 ✅ 提交前必须执行 git status 检查 ✅ 临时文件应创建在
<workspace_dir>/temp/目录下 ✅ 提交前如果发现有临时文件，必须先将它们移动到<workspace_dir>/temp/目录下 ✅ 确认只有核心业务逻辑文件
注意：workspace_dir 是工作区根目录，通常不是特定的仓库根目录，而是包含多个仓库，但如果仓库本身是工作区根目录，则应在.gitignore中忽略temp目录。
1. 明确指定文件
# 方式1：明确指定文件
git add src/weread/catalog.ts src/weread/outline.ts
# 方式2：交互式添加
git add -p
2. 提交前检查
# 查看待提交文件
git status
# 如果发现有临时文件，先移动到 `<workspace_dir>/temp/` 目录下
mv temp-file.txt <workspace_dir>/temp/
# 查看暂存区差异
git diff --cached
3. 规范的 Commit Message
<type>(<scope>): <subject>
类型：
- feat: 新功能
- fix: 修复bug（如果bug来自issue，请引用issue编号，例如：#123，但如果bug来自其他来源，比如PR review，请勿使用"#"符号）
- refactor: 重构
- docs: 文档
- style: 格式
- test: 测试
- chore: 构建/工具
重要： 如果Commit Message超过2行，必须在 <workspace_dir>/temp/目录下创建commit message临时文件，提交方式为 git commit --file=<workspace_dir>/temp/git-commit-msg.txt 。
1. 盲目使用 git add -A
# ❌ 错误：添加所有文件（包括临时文件、文档等）
git add -A && git commit -m "..."
# ✅ 正确：明确指定文件
git add src/file1.ts src/file2.ts
2. 临时文件混入提交
❌ 临时文件创建在工作目录：
.git-commit-msg.txt、.pr-description.md✅ 使用<workspace_dir>/temp/临时目录：<workspace_dir>/temp/git-commit-msg.txt
3. 替换已创建PR的commit 如果commit已被push，且该分支已创建PR，禁止直接amend。
正确做法是创建新的commit，不要amend。
场景：将主分支更新合入功能分支时
❌ 不推荐：使用 merge
# （在功能分支上执行）
git merge master
# 问题：会产生额外的 "Merge branch 'master' into feature/xxx" commit
# PR 中会显示多余的合并提交，历史不够线性
✅ 推荐：使用 rebase
# 步骤1：更新本地主分支
git checkout master && git pull origin master
# 步骤2：切回功能分支并变基
git checkout feature/your-feature
git rebase master
# 步骤3：如果之前已经推送过，需要强制推送（必须先征询用户意见）
# ⚠️ force push 会重写远程历史，必须获得用户明确同意后才能执行
git push --force-with-lease origin feature/your-feature
优势：
⚠️ 注意事项：
# ✅ 撤销特定文件的暂存
git restore --staged <file>
# ✅ 撤销所有暂存
git restore --staged .
# ✅ 撤销提交，保留修改
git reset --soft HEAD~1
# ⚠️ 撤销提交和暂存，保留工作区
git reset HEAD~1
# ❌ 危险：撤销并丢弃所有修改
git reset --hard HEAD~1
# ✅ 从Git中移除，保留本地文件
git rm --cached <file>
# ❌ 删除文件并从Git中移除
git rm <file>
每次修改后，沿依赖方向走一遍：谁依赖了我改的东西？它们还正确吗？
git diff --cached）<workspace_dir>/temp/目录下？