Git报错“Your local changes would be overwritten by merge”是安全保护机制，非bug；它因工作区修改与远端同名文件内容冲突而中止拉取，解决路径只有暂存（git stash）、提交或丢弃，强制覆盖（如git reset --hard）仅适用于确认无价值的修改。
git pull 报错 “Your local changes would be overwritten by merge” 怎么办
Git 拉取失败不是它出错了，而是它在认真拦你——它发现 service/pro_service.go 这类文件，你改了但没提交，而远端也动了同一处，强行合并会丢你的修改。它不覆盖，只报错，这是保护机制，不是 bug。
用 git stash 临时存起来再拉（最常用）
适合你本地改了东西、还想保留、又必须合入远端更新的场景。注意：默认 git stash 不收新建未跟踪文件（比如你刚建的 config.local.yaml），远端若也有同名文件，拉下来会直接覆盖它。
- 只暂存特定文件（推荐）：
git stash push -m "wip: pro_service" -- service/pro_service.go - 暂存所有已跟踪的修改（不含新建未
git add的）：git stash - 暂存时带上未跟踪文件（谨慎）：
git stash -u或git stash --include-untracked -
git pull成功后，用git stash pop恢复；如果有冲突，Git 会在对应行标出和 <code>>>>>> Stashed changes，手动改完记得git add再git commit
为什么 git checkout . 或 git reset --hard 是高危操作
这两个命令不会问你、不看暂存区、不校验状态，语义就是“全按远端/HEAD 覆盖”。一旦执行，你刚改的几十行代码、还没 git add 的调试日志、甚至刚 git add 但没 commit 的关键逻辑，全没了。
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
-
git checkout .：丢弃工作区所有未暂存修改，但暂存区内容还在 -
git reset --hard：丢弃工作区 + 暂存区全部未提交内容，回到HEAD状态 - 真正想“放弃修改”时，优先用
git restore .（Git 2.23+），它更明确、可逆性略强
拉之前先看远端到底改了啥，心里有底再动手
别等报错才行动。提前 fetch 并对比，能预判风险点，尤其当你不确定自己改的 utils/helper.js 是否和别人撞了。
- 只下载远端对象，不合并：
git fetch origin - 看当前分支和远端差异：
git diff HEAD..origin/main（把main换成你当前分支名） - 重点扫一眼输出里有没有你正在改的文件路径，如果有，就按上面
stash流程走 - 如果只是新增配置或文档，且你本地没动过它们，那
git pull大概率直接成功
最容易被忽略的是暂存区状态和未跟踪文件——git status 输出里带 modified: 的是工作区改了，带 staged for commit: 的才是暂存区有货；而完全没出现在 git status 里的新文件，git stash 默认不理它。这三块不一起看全，光靠报错提示容易救偏。
