<p>git checkout -- .仅丢弃工作区中未暂存的已跟踪文件修改，不触碰暂存区、提交历史及未跟踪文件；恢复目标为HEAD版本（若文件已暂存则为暂存区版本），执行后不可逆。</p>
git checkout -- . 会丢掉所有未暂存的修改
这个命令只影响工作区，不碰暂存区和本地提交历史。它把所有已跟踪文件（即之前 git add 过或已提交过的文件）恢复成当前分支 HEAD 的样子。
常见错误现象：
- 执行后发现新创建的文件没被删——因为
git checkout -- .不处理未跟踪文件 - 改了但没
git add的代码消失了，而你其实想保留——这是最典型的误操作
使用场景：确认本地改动完全不要了，且远程最新版就在当前分支 HEAD 上（比如刚拉完、还没任何提交）。
安全建议：
- 先运行
git status确认输出里没有Untracked files——有就说明还有新建文件，得手动删 - 如果只是想丢掉某几个文件的修改，用
git checkout -- path/to/file.py更精准
git reset --hard HEAD 会清空暂存区 + 工作区
它比 git checkout -- . 更彻底：不仅重置工作区，还把暂存区（index）也一并清空，让本地状态完全回到上一次提交那一刻。
关键区别：
-
git checkout -- .不动暂存区；git reset --hard HEAD连暂存区都重置 - 如果已经
git add了某些修改但还没commit，用checkout不会撤销这个add，但reset --hard会
性能 / 兼容性影响：无特殊影响，但风险更高——一旦执行，所有未提交的改动（包括已 add 的）全部不可逆丢失。
容易踩的坑：
- 误以为它能同步远程——它只作用于本地 HEAD，跟远程无关。执行完还得再
git pull才能拿到远程最新 - 在非快进（fast-forward）情况下，直接
reset --hard origin/main可能跳过中间提交，需确认是否真要丢弃全部本地提交
git fetch + git reset --hard origin/ 是真正“强制同步远程”的组合
这才是放弃本地所有改动、完全对齐远程指定分支的标准做法。分两步走：先取远程最新元数据，再硬重置到那个状态。
实操步骤：
- 运行
git fetch origin（确保拿到远程分支最新 commit ID） - 确认目标分支名，比如
main或develop，然后执行git reset --hard origin/main - 如果当前不在该分支，先
git checkout main再重置
为什么不能跳过 fetch 直接 reset --hard origin/main？
- 本地的
origin/main指针可能已过期，reset会按旧指针重置，结果不是真正的“最新” -
git fetch是唯一能更新远程分支引用的操作，git pull是fetch + merge，不适合这里
注意：此操作会丢弃所有本地提交、暂存、工作区修改。务必确认分支名拼写正确，否则可能重置到错误分支。
遇到 unrelated histories 报错时怎么强制覆盖
空仓库首次拉取远程代码时，常出现 fatal: refusing to merge unrelated histories。这不是“放弃本地修改”的问题，而是 Git 拒绝合并两个毫无交集的历史。
此时不能靠 reset 或 checkout 解决，必须用 pull 命令加参数：
- 先确保远程分支名正确：
git ls-remote --heads origin - 执行
git pull origin main --allow-unrelated-histories（把main换成实际分支名） - 如果只想取远程文件、不要任何提交历史，更干净的做法是删掉整个
.git文件夹，重新git clone
容易忽略的一点：这个报错只在首次拉取时出现，后续更新不会触发。所以它本质是初始化问题，不是日常协作中的“放弃修改”场景。
