“我的代码被同事覆盖了！”——帮群里的同学解决 Git 问题
内容提要
同事合并时解决冲突误删了同学的代码，导致其分支无法再合并。解决办法：先备份，用 git reset 回退到开发起点并保留改动，git stash 暂存后切到最新分支，再 stash pop 并解决冲突，重新提交 PR。核心是理解 Git 按行对比、版本单向、冲突需人工处理的原理，而非死记套路。
延伸解读
理解 Git 的按行对比与冲突本质
文章指出，Git 按行对比代码，每次提交产生新版本，版本历史单向。当两个无法分辨先后的版本修改同一行时，就会产生冲突，Git 无法自动解决，必须人工处理。这解释了为什么同事合并时可能误删代码：解决冲突时选择了保留自己的版本，丢弃了同学的修改。理解这一点，就能明白冲突不是 Git 的缺陷，而是其设计使然。
代码被覆盖后的恢复思路
文章提出的恢复方案是：先备份，然后 git reset 回退到开发起点并保留改动，用 git stash 暂存，切换到最新分支后 stash pop，再解决冲突并重新提交 PR。这种方法的核心是把所有修改集中起来做成新提交，因为部分代码可能已在库中，Git 会直接接受，只有少量冲突代码需要手动解决，总量不多，因此效率较高。
避免死记硬背，注重原理分析
作者强调，用好 Git 不能靠背套路或瞎试，而应理解其设计和实现。遇到问题先分析原因，再寻找方案，最后谨慎实施。例如，同事误操作可能不是 push -f，而是解决冲突时丢弃了他人代码。只有从原理出发，才能选择正确方法，而不是盲目尝试 rebase 或逐个还原。
Q&A
同事合并代码时把我的代码覆盖了，导致我的分支无法合并，这是什么原因造成的？
最可能的原因是同事在合并时遇到冲突，解决冲突时选择保留自己的代码，丢弃了你的代码。这导致你的代码版本较旧，Git 拒绝合并，也无法提交新的 PR。
我的代码被同事覆盖后，如何恢复并重新提交？
先备份代码。然后回退到开发起点：git reset b1 --mixed（b1 是切分支时的 commit）。接着 git stash 暂存改动，切换到最新分支 git checkout B，再 git stash pop 弹出暂存。如果冲突则解决冲突，最后重新提交 PR 并合并。
为什么解决 Git 冲突不能靠背套路，而要理解原理？
因为 Git 问题千变万化，但都基于根本原理：按行对比、每次提交产生新版本、版本单向、冲突需人工处理。只有理解原理，才能分析前因后果，选择最佳方案并谨慎实施，而不是盲目尝试。
Git 的基本工作原理是什么？
Git 按行对比文件；每次提交产生新版本；版本是单向的，Git 维护版本历史；两个无法分辨先后的版本修改同一行时产生冲突，Git 无法解决，需人工处理；分支是指针，指向某个版本并随提交自动前进。
同事覆盖我的代码后，我的代码是全部丢失了吗？
不一定。如果同事不是用 push -f 强制推送，你的代码应该有一部分还在库里，只是冲突的部分可能被丢弃了。因此可以通过回退和重新提交来找回大部分修改。
除了一个个文件比对，有没有更高效的方法找回被覆盖的代码？
有。把所有修改全部找出来，做成新的提交。因为部分代码已经在库里，这部分大概率会被 Git 直接接受；只有少部分之前冲突的代码需要解决冲突后提交，总量不多，所以这是最快的方法。
