要安全提交代码，先用git status确认改动范围，再用git diff逐行核对修改内容，接着git add -p分批暂存，最后规范提交并git push推送。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想在 Codex 里安全地提交代码，又怕改错后找不到回退点，或者不确定哪些文件真被改了、哪些只是临时缓存——这时候不能靠猜，得用 Git 命令亲眼确认每一步改动再动手。
确认当前改动范围
先运行 git status，它会告诉你哪些文件是“已修改未暂存”，哪些是“已暂存待提交”，哪些是“未跟踪的新文件”。这步漏掉，后面可能把 .env 或 node_modules 一起提交上去。
如果看到大量红色文件名（未暂存），别急着 git add .。Codex 默认不会帮你过滤生成文件或敏感配置，【必须手动核对列表】——尤其注意有没有 *.log、*.swp、dist/、build/ 这类目录混在里面。
想快速定位某类文件，比如只看 JavaScript 变更：运行 git status -- '*.js'。
逐行比对真实修改内容
光看文件名不够，得看代码到底动了哪几行。执行 git diff，终端会高亮显示所有未暂存的增删改，+ 是新增，- 是删除，灰色是上下文。
方法一：检查单个关键文件
git diff src/auth/login.ts
这能避免全局 diff 信息刷屏，特别适合改完核心逻辑后快速复核。
方法二：跳过空格和注释变动（聚焦实质逻辑）
git diff -w -U0
-w 忽略空格变化，-U0 只显示变更行不带上下文，适合快速扫一遍函数体是否被误删。
⚠️ 注意：如果 diff 输出为空但 git status 显示有修改，大概率是文件权限或换行符（CRLF/LF）被系统自动转换了，不是你写的代码变了。
分批暂存确保粒度可控
第一步：只暂存确定要提交的部分
git add src/auth/login.ts
不要用 git add .，Codex 协作中一次混入十几个文件会让 review 完全失效。
第二步：对大文件做交互式拆分
git add -p
终端会逐块询问：“这块要不要加？” 按 y（是）、n（否）、s（拆更小块）。比如一个 200 行的 config.js，你只改了其中 3 行，就该用这个命令精准捕获。
第三步：撤回误加的文件
git restore --staged secrets.json【这条命令不可逆，执行后该文件立刻从暂存区移除】，但工作区代码保留不变，还能继续编辑。
写提交信息并完成提交
运行 git commit（不加 -m 参数），Codex 会自动打开默认编辑器（通常是 nano 或 vim），让你手写提交信息。
第一行必须是简明动词开头的标题，长度不超过 50 字：
fix(auth): prevent token reuse after logout
空一行后写正文，说明： • 为什么改（比如“旧逻辑未清除 refresh token 导致重放攻击”） • 怎么改（比如“在 logout 接口增加 redis DEL 操作”） • 影响范围（比如“仅影响 /api/v1/auth/logout 路径”）
保存退出后，Codex 会校验格式：标题超长、缺少空行、正文没说明原因，都会报错并退回编辑器。这不是限制，是防止你写出 “update code” 这种无效信息。
如果刚提交完发现信息写错，立刻运行：
git commit --amend -m "fix(auth): prevent token reuse after logout"【仅限未推送前修改，push 后再改会触发 force push 风险操作】。
推送到远程分支
先确认当前分支名：
git branch --show-current
再推送：
git push origin feature/auth-logout-fix
Codex 会自动检测远程分支是否存在，不存在就创建；存在则校验是否有冲突。
如果提示 “rejected — non-fast-forward”，说明远端已有新提交。此时不要强行 --force，先执行：
git pull --rebase origin feature/auth-logout-fix
解决完可能的冲突后，再 git push。
