git add . 添加未跟踪、已修改、已删除文件（忽略.gitignore）；-u 仅添加已跟踪的修改/删除文件；-A 等价于两者之和。日常推荐用 -u，新增文件时再用 . 并先 git status 确认。
git add 怎么选：.、-u、-A 三个参数的区别
很多人一上来就 git add .，结果把不该提交的文件（比如 node_modules/、.env、编译产物）也加进去了。关键不是“能不能加”，而是“该加什么”。
git add . 会递归添加当前目录下所有「未跟踪 + 已修改 + 已删除」的文件，但不包括被 .gitignore 显式忽略的——前提是 .gitignore 已生效（即那些文件之前没被 Git 跟踪过）。
git add -u 只添加「已跟踪且被修改/删除」的文件，完全跳过新创建的未跟踪文件。适合日常改代码后想只提交变更，不带新增文件。
git add -A 等价于 git add . + git add -u，即覆盖全部状态（新、改、删），但实际和 . 在绝大多数场景下行为一致，没必要刻意换。
建议日常用 git add -u；初始化或补提新文件时才用 git add .，并务必先 git status 确认列表。
git commit -m 提交前必须检查的三件事
提交不是终点，而是协作的起点。很多 push 失败、CI 报错、同事拉不到新逻辑，根源都在这一步没做对。
- 运行
git status，确认暂存区里只有你真想提交的文件（尤其注意有没有误加的二进制文件或日志） - 运行
git diff --cached，看暂存区里的改动是否和预期一致（比如是否漏掉了某个关键if分支的修复） - 提交信息别写
update或fix bug这种空泛描述；要说明「改了什么 + 为什么改」，例如：fix: prevent null pointer in UserAuthService#login when token is expired
跳过暂存区直接提交？慎用 git commit -a
git commit -a -m"xxx" 看起来省事，但它只会自动 stage 所有「已跟踪」文件的修改和删除，完全不管新文件。也就是说：
如果你刚加了一个 utils/date-format.js，用 -a 是不会把它带上提交的——你会以为提交成功了，结果别人 git clone 后直接报 Module not found。
更隐蔽的问题是：它绕过了 git add 的显式确认环节。你没法在暂存前用 git diff 逐个核对每个文件，容易把调试用的 console.log 或临时注释一起推上去。
除非你非常确定当前只有已跟踪文件的修改，且已反复验证过 diff，否则不要用 -a。
push 前发现暂存错了？用 git reset 回退最安全
刚 git add . 完，git status 一看发现多了两个不该提交的配置文件，这时候别删文件、别关终端，直接用 git reset HEAD <file></file> 撤出暂存区就行。
常见操作：
- 撤单个文件：
git reset HEAD config.local.yml - 撤所有暂存（回到修改后未暂存状态）：
git reset（不带参数，默认作用于 HEAD） - 如果已经
commit了但还没push，可以用git reset --soft HEAD~1回退到暂存区，保留工作区改动
注意：git reset --hard 会同时丢弃工作区修改，除非你明确想放弃全部本地改动，否则别碰。
真正卡住人的从来不是命令记不住，而是不知道哪一步该停、该看、该反悔。每次 add 后多敲一次 git status，比事后花半小时排查 merge conflict 划算得多。
