Git提交前到底该做什么?一套避免代码丢失和冲突的安全工作流
Git提交前到底该做什么?一套避免代码丢失和冲突的安全工作流
很多人把 Git 当成“改完代码,git add .、git commit、git push”的三连工具。直到某一天:密钥进了仓库,别人的修改被覆盖,冲突文件被误删,或者本地改了两天的内容在切分支时消失。
Git真正难的不是记住命令,而是知道每一步在保护什么。本文给出一套先观察、再修改、可撤销的提交工作流。
一、先理解四个区域
工作区 → 暂存区 → 本地仓库 → 远程仓库 git add git commit git pushgit add .不是保存代码,而是把改动全部放入暂存区,可能连日志、构建产物和配置密钥一起加入。
二、提交前先看状态和差异
gitstatus--short--branchgitdiff--statgitdiff--name-only如果看到不认识的文件,先确认来源,不要删除或覆盖。查看具体改动:
gitdiff-- path/to/file.pygitdiff--cached-- path/to/file.py第二条查看的是已经进入暂存区的内容。
三、按文件或按补丁暂存
gitaddpath/to/file.py path/to/test_file.pygitadd-pgitdiff--cached--checkgitdiff--cachedgit add -p可以逐块选择改动。提交前必须确认每一处变化都属于本次任务。
四、密钥检查不能省略
重点检查 .env、私钥、云服务凭据、数据库导出、内部日志、构建目录和个人配置:
gitdiff--cached--name-onlygitrestore--stagedpath/to/secret.env.gitignore只能阻止尚未被跟踪的文件。如果密钥已经提交或推送,应先轮换凭据,再清理历史。
五、一次提交只表达一个意图
不要把修接口、全项目格式化、升级依赖和重命名目录塞进一个提交。提交信息要说明对象和结果:
gitcommit-m"fix: reject empty order items before payment"六、同步远程前不要覆盖本地改动
gitstatus--shortgitfetch origingitlog--oneline--decorate--graphHEAD..origin/maingit fetch只更新远程跟踪信息,不会自动修改当前分支。不要把git reset --hard当作普通清理命令。
七、冲突时不要盲选“我的版本”
gitstatusgitdiff--name-only --diff-filter=Ugitdiff--checkgitaddpath/to/resolved_file.py冲突表示 Git 无法判断两边修改的意图。解决目标是符合业务规则的第三份结果,而不是机械选择一边。合并方向错误时,可以确认状态后执行git merge --abort。
八、提交后发现错误怎么办
未推送的最近提交可以使用git commit --amend修改。已经共享的提交通常使用:
gitrevert<commit-id>gitreflog--date=localrevert保留协作历史;reflog用于寻找本地引用曾经指向的位置,但不是远程备份。除非团队明确允许,不要使用git push --force改写共享历史。
九、每天提交前的检查清单
□ 当前分支与任务一致 □ 我知道每个改动文件的来源 □ 暂存区没有密钥、日志和构建产物 □ 我看过 git diff --cached □ 本次提交只表达一个意图 □ 相关测试或手动验证已完成 □ 推送前已了解远程是否有新提交 □ 出问题时知道用 revert、merge --abort 或 reflog总结
可靠的 Git 习惯不是记住更多命令,而是每次操作前都知道它会改变什么、失败后如何回来:先看状态,再看差异;只暂存本次任务需要的内容;共享历史用 revert,本地误操作用 reflog寻找恢复点。
参考资料
- Git官方文档,git-status,2026-08-31核验。
- Git官方文档,git-diff,2026-08-31核验。
- Git官方文档,git-restore,2026-08-31核验。
- Git官方文档,git-fetch,2026-08-31核验。
- Git官方文档,git-revert,2026-08-31核验。
- Git官方文档,git-reflog,2026-08-31核验。
