本站 2024 年招商持续进行中,欢迎各位老板前来投放:
https://blog.meathill.com/ad/advertise-on-this-site.html
刚才,群里有位同学提问:
我把我的分支合到 B 分支上了,然后另外一个同事将他的代码合到 B 分支将我的代码覆盖了,然后 B 分支又有很多提交记录,不能回退了,我的分支再合到 B 分支不显示冲突和修改了
大佬们,这种情况怎么解决呀
可能大家都有过被同事误操作丢失代码的经验吧,群里群情激愤,纷纷谴责起这位同事。也有不少同学七嘴八舌的开始支招,有说找责任人的,有说一个一个还原的,有说 rebase 的。大家很热心,可惜都没说到点子上。
要用好 Git,绝对不能靠背套路,更不能瞎试,成了也不知道咋成的,败了也不知道为啥不行。要理解 Git 的设计和实现,遇到问题先分析,再寻找最佳方案,然后小心谨慎的实施。
我们先分析一下问题的原因:
- 最大的可能是,同事合并代码时,遇到冲突,他在解决冲突时,选择保留自己的代码,丢弃了同学的代码(最恶心的情况)。
- 我们不考虑归责。同学现在要提交自己的代码,但是因为他的代码版本比较“旧”,所以 git 拒绝合并。也无法提交新的 PR。
- 如果前面推测没错,那么同事就不是用的
push -f
。 - 所以同学的代码应该有一部分在库里,只是冲突的部分可能没了。
如此一来,除了一个文件一个文件比对(效率太低),那么就是把所有修改全部找出来,然后做成新的提交。因为部分代码已经在库里,这部分代码大概率会直接被 git 接受;只有少部分之前冲突的代码需要解决之后才能提交,总量应该不多。所以,这该会是最快的方法。
想清楚该怎么做之后,就该制定方案了:
- 先备份代码。
- 回退到启动开发时,切出来的分支。假设 commit 是 b1:
git reset b1 --mixed
。这一步会将 b1 之后的变更,作为未提交的部分,集中起来,排除版本信息。 - 保留这部分的代码到暂存区:
git stash
。 - 切到开发分支的最新版本:
git checkout B
。 - 弹出暂存的代码
git stash pop
。 - 可能会失败,因为存在冲突。那就解决冲突。
- 解决冲突后,重新提交 PR,然后合并分支。
总结一下。Git 原理很简单:
- 按行对比。
- 每次提交都会产生新版本。
- 版本是单向的,Git 负责维护版本历史。
- 两个无法分辨先后的版本修改了同一行,就有冲突。Git 无法解决冲突,会交给人处理。
- 人处理后,产生新版本。
- 分支是指针,指向某个版本,并随提交自动前进。
在此基础上,可能衍生出各种问题,比如开头的那一幕。但是不管问题如何,都离不开根本原理。所以我们面对 Git 问题,不要背套路,要认真分析前因后果,然后选择解决方案,再根据方案制定流程。
希望这次分享对大家有帮助。如果你对 Git 操作还有什么不清楚不明白的,欢迎提问。如果我上文有错误,也欢迎指出。希望 2024,大家共同进步,再没有会乱搞别人代码的同事。
欢迎吐槽,共同进步