Git提交代码到本地仓库的本质是将工作区修改存档进.git对象数据库，需经git add暂存、git commit提交、git status/git log验证三步；常见错误是漏执行git add，导致commit不包含未暂存更改。
Git 提交代码到本地仓库，本质是把工作区的修改“存档”进本地 .git 目录里的对象数据库。关键不是“点提交按钮”，而是理解三步：暂存（git add）、提交（git commit）、确认结果（git status 或 git log）。
为什么 git commit 后看不到新提交？
最常见原因是忘了 git add —— git commit 只提交已暂存（staged）的文件，不提交工作区里“刚改完还没加”的文件。
- 运行
git status，如果看到文件在 “Untracked files” 或 “Changes not staged for commit” 区域，说明它们没被add -
git add .会暂存当前目录下所有已跟踪文件的修改，但不会自动包含全新未跟踪文件（除非加-A或-u参数） - 误用
git commit -a以为能跳过add：它只对“已跟踪且已修改”的文件自动暂存，对全新文件（Untracked）完全无效
git add 的路径和通配符怎么写才安全？
路径写错会导致漏加、多加甚至暂存错误文件（比如意外把 node_modules 加进去了）。
- 用相对路径更可控：
git add src/utils.js比git add ./src/utils.js更简洁，也避免因 shell 展开出问题 - 慎用
git add *：shell 先展开通配符，可能把.gitignore里忽略的文件也传给git add（Git 不会自动过滤） - 想加所有变更（含新文件），用
git add -A；只想加已跟踪文件的修改，用git add -u；两者区别直接影响后续commit内容
提交信息写太简略，后期查问题很痛苦
一句 git commit -m "fix" 看似省事，但三个月后没人记得修的是哪个 bug、影响范围在哪。
- 第一行（subject）控制在 50 字以内，用动词开头：
git commit -m "refactor: extract validation logic from handler" - 空一行后写 body，说明“为什么改”“怎么改的”“是否需人工验证”，用普通句子，不用代码块
- 如果本次提交修复某个 issue，加上
Fixes #123，GitHub/GitLab 会自动关联并关闭该 issue
真正容易被忽略的点是：提交只是本地操作，不涉及远程；很多人以为 git commit 就等于“上传成功”，其实还差 git push 这一步。另外，.gitignore 是在 add 阶段起作用的——一旦文件已被 Git 跟踪，再往 .gitignore 里加规则也没用，得先 git rm --cached。
