“我的代码被同事覆盖了!”——帮群里的同学解决 Git 问题

本站 2024 年招商持续进行中,欢迎各位老板前来投放:

https://blog.meathill.com/ad/advertise-on-this-site.html

刚才,群里有位同学提问:

我把我的分支合到 B 分支上了,然后另外一个同事将他的代码合到 B 分支将我的代码覆盖了,然后 B 分支又有很多提交记录,不能回退了,我的分支再合到 B 分支不显示冲突和修改了

大佬们,这种情况怎么解决呀

可能大家都有过被同事误操作丢失代码的经验吧,群里群情激愤,纷纷谴责起这位同事。也有不少同学七嘴八舌的开始支招,有说找责任人的,有说一个一个还原的,有说 rebase 的。大家很热心,可惜都没说到点子上。

要用好 Git,绝对不能靠背套路,更不能瞎试,成了也不知道咋成的,败了也不知道为啥不行。要理解 Git 的设计和实现,遇到问题先分析,再寻找最佳方案,然后小心谨慎的实施。

我们先分析一下问题的原因:

  1. 最大的可能是,同事合并代码时,遇到冲突,他在解决冲突时,选择保留自己的代码,丢弃了同学的代码(最恶心的情况)。
  2. 我们不考虑归责。同学现在要提交自己的代码,但是因为他的代码版本比较“旧”,所以 git 拒绝合并。也无法提交新的 PR。
  3. 如果前面推测没错,那么同事就不是用的 push -f
  4. 所以同学的代码应该有一部分在库里,只是冲突的部分可能没了。

如此一来,除了一个文件一个文件比对(效率太低),那么就是把所有修改全部找出来,然后做成新的提交。因为部分代码已经在库里,这部分代码大概率会直接被 git 接受;只有少部分之前冲突的代码需要解决之后才能提交,总量应该不多。所以,这该会是最快的方法。

想清楚该怎么做之后,就该制定方案了:

  1. 先备份代码。
  2. 回退到启动开发时,切出来的分支。假设 commit 是 b1:git reset b1 --mixed。这一步会将 b1 之后的变更,作为未提交的部分,集中起来,排除版本信息。
  3. 保留这部分的代码到暂存区:git stash
  4. 切到开发分支的最新版本:git checkout B
  5. 弹出暂存的代码 git stash pop
  6. 可能会失败,因为存在冲突。那就解决冲突。
  7. 解决冲突后,重新提交 PR,然后合并分支。

总结一下。Git 原理很简单:

  1. 按行对比。
  2. 每次提交都会产生新版本。
  3. 版本是单向的,Git 负责维护版本历史。
  4. 两个无法分辨先后的版本修改了同一行,就有冲突。Git 无法解决冲突,会交给人处理。
  5. 人处理后,产生新版本。
  6. 分支是指针,指向某个版本,并随提交自动前进。

在此基础上,可能衍生出各种问题,比如开头的那一幕。但是不管问题如何,都离不开根本原理。所以我们面对 Git 问题,不要背套路,要认真分析前因后果,然后选择解决方案,再根据方案制定流程。

希望这次分享对大家有帮助。如果你对 Git 操作还有什么不清楚不明白的,欢迎提问。如果我上文有错误,也欢迎指出。希望 2024,大家共同进步,再没有会乱搞别人代码的同事。

如果您觉得文章内容对您有用,不妨支持我创作更多有价值的分享:


已发布

分类

来自

标签:

评论

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据