git add后文件未进暂存区，主因是路径错误、不在仓库目录、被.gitignore忽略或shell通配符误展开；应先用git status -s确认状态，再检查路径、忽略规则及权限。
git add 之后文件没进暂存区？检查路径和状态
执行 git add 后运行 git status 仍显示“untracked”或“modified”，大概率是路径写错了，或者用了通配符但当前 shell 提前展开了。比如在 zsh 中输入 git add *.js，如果当前目录没有 .js 文件，zsh 会原样传给 git，而 git 不识别这种未匹配的通配符，直接忽略——结果就是什么都没加。
实操建议：
- 用
git status -s确认文件是否真出现在 “A”（新增）或 “M”（修改）列 - 添加单个文件优先用完整相对路径：
git add src/utils/helper.js - 想递归添加某目录下所有变更，用
git add --all src/或git add -u src/（后者只加已跟踪文件的修改） - 避免在有空格或中文路径下依赖 shell 通配，改用
git add .（注意：它不包含新文件夹下的未跟踪文件，除非该文件夹里已有被跟踪文件）
git commit -m 提交后发现漏了文件，怎么补救
刚 git commit 完就发现少 git add 了一个关键文件？别急着 push，用 git commit --amend 可以把暂存区最新改动合并进上一次提交，连 message 都能一起改。
但要注意：这个操作会重写提交哈希（commit hash），如果已经 git push 过，强行 amend 再 push 会触发拒绝（non-fast-forward），必须加 --force-with-lease（比 --force 更安全）。
实操建议：
- 确认还没 push：
git log --oneline -3看最近几条，再git status确保漏掉的文件现在在暂存区 - 执行
git commit --amend -m "fix: add missing config.json" - 如果已 push 过且无人基于你这次提交开发，可用
git push --force-with-lease origin main - 团队协作中，一旦 push 完就不建议 amend，宁可另起一次 commit 并写清楚原因
git push 推送失败：rejected master -> master non-fast-forward
这个错误说明远程分支的最新提交不在你本地分支的历史链上，常见于别人先 push 了新提交，而你本地还停留在旧 HEAD。Git 拒绝覆盖，防止丢记录。
不是所有情况都该强制覆盖——多数时候你需要先同步别人的工作。
实操建议：
- 先拉取更新：
git pull origin main（假设远程主干叫 main） - 如果 pull 失败提示“refusing to merge unrelated histories”，说明本地和远程无共同祖先，加
--allow-unrelated-histories - 如果 pull 触发冲突，解决后
git add . && git commit，再git push - 极少场景需覆盖远程（如自己临时分支误推），用
git push --force-with-lease origin feature/login，切勿对 main/develop 等共享分支使用
远程分支名和本地不一样，怎么让 git push 默认推到指定分支
执行 git push 时没带参数却推到了意料之外的远程分支，是因为 Git 默认按 push.default 配置行为走。老版本默认是 matching（推所有同名分支），新版本默认是 simple（只推当前分支到同名远程分支，且要求名字一致）。
如果你本地分支叫 dev，但想默认推到远程的 main，不能靠改配置绕过逻辑，得明确建立追踪关系。
实操建议：
- 首次推送时显式指定：
git push -u origin dev:main，其中-u会把本地dev设置为追踪远程origin/main - 之后再
git push就会自动推到origin/main - 查看当前追踪关系：
git branch -vv，星号旁显示的 upstream 就是目标 - 手动修改追踪分支：
git branch --set-upstream-to=origin/main dev
