Menu
Git初始化新仓库、提交与推送规范指南。执行git init/commit/push前必须调用，确保遵循用户审核、原子提交、精准文件选择等原则。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle 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/目录下？结构化代码审查框架，覆盖代码质量、安全性、性能和测试标准。适用于 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.