【git重案组】如何逃避git blame的追踪?
收藏





导语:程序员的血腥复仇——论如何偷偷修改代码而不被别人发现...


背景介绍

上周笔者在工作中发现git仓库出现了一个奇怪的问题,master分支中某文件的一次commit丢失掉了,但diff中没有任何记录,这让笔者一度怀疑是git或者code平台自己出了问题。


在code平台一条条比对后发现变动发生在feature分支merge master分支之后。


原本SHA为8950d的edit.vue 文件最近一次修改是在一周前。


在merge之后该文件回滚到了两周前。


通过查询该文件的commit记录,可以看到最近的一次SHA为49c1a的commit确实丢掉了。


先明确前提,这是在一次merge中丢失的,而非经历了rebase或者reset操作,并没有对历史记录进行修改。


这里回顾下整个过程中的git 操作流,先从master checkout一个feature分支,在该分支提交了几次commit,merge master 到 feature,然后在master再次merge feature。


应该说这里虽然有不规范之处(没有提交merge request而是本地直接在master上merge然后push),但整体还算常规操作,即使是在merge中发生了冲突,不小心操作失误,按道理也不会没有diff记录。


merge的parent-1和parent-2

google一下找到了一篇相似的文章https://blog.laisky.com/p/git-merge/

该文章是在master分支上git pull,由于pull 的默认行为是 pull —merge,所以其实也是在merge中丢失的。


原文作者给出了一个比较清晰的解释:

众所周知,merge 是将两个 branch 合并为一个,所以每一个 merge commit 拥有两个 parents。当我们在 gitlab 或者 source tree 查看一个提交的具体修改时,其实就是将本次提交和其 parent 做 diff。而由于 merge commit 有两个 parent,并会将其排序为 1 和 2,当你试图查看一个 merge commit 的修改时,其实显示的是相对于 parent-1 的 diff。这样的一个问题是,如果 remote 不幸成为了 parent-2,那么你就可以通过巧妙的构造 parent-1 来实现一次“隐身”的代码修改。



我们提取原文核心,重点在于merge时的diff记录是相对于当前分支,假如当前分支是两周前的版本,而外来分支是一周前的版本,当merge时放弃掉一周前的版本,对原分支来说这次merge之后与之前并未发生改变,所以diff中自然也没有记录。


merge request 的不同之处

这个解释似乎也说的过去,不过在合并到master分支之前必然要本地merge一下master才可以快速合并,这个操作是逃避不了的,如果在本地merge时错误解决冲突会被隐藏下来,这岂不是git一个很大的缺陷吗?那code平台的merge request后的code review还有意义吗?


笔者自己搭建了一个测试仓库发现如果提交merge request,在code review的diff界面是看得到这次修改的,在提交之后也能在history中看到diff。难道gitlab(code平台应该是基于gitlab开发的)平台自己的diff算法更高级,所以才能发现这次错误?


笔者到这里产生了一个猜测,在本地操作的时候git 的diff算法有缺陷,它简单地把每一次commit的diff patch在一起,而code平台是老老实实做了两个文件夹的diff。


git diff的差异

在google之后,果然发现了不同(其实并不然…)!


在几个stackoverflow的问答和github的issue中笔者发现 github平台的pull request(虽然gitlab是merge request,实际上差不多)是使用了git diff的三点操作,而直接diff是两点操作,区别如下:

笔者一度以为突破口就在这里,但是仔细分析了git log —graph之后发现在merge request之前本地feature分支就已经merge了一次master,在这个情形下git diff的两点操作和三点操作根本没什么不同。


链接:
What are the differences between double-dot “..” and triple-dot “…” in Git diff commit ranges? - Stack Overflow

https://github.community/t5/How-to-use-Git-and-GitHub/GitHub-pull-requests-showing-invalid-diff-for-already-merged/td-p/3000


merge的原理和fast-forward

Git merge采取三路合并策略,三路分别是基准分支(分叉的节点)、mine、theirs。


如果mine和theirs相对基准都发生了改变 那git 就报冲突,然后让你人工决断。否则,git将取相对于base变化的那个为最终结果。


一次普通的merge会新建一个commit节点(7号节点)。

而如果在feature分支从master checkout之后,master并未出现新的commit,就会出现三种策略。

默认git merge会采取第三种策略,直接将master指针移到feature的头上即可,这里不会出现一个message为“merge xxx into xxx”的commit。


回到问题发生的场景上,在feature分支上执行git merge master的时候发生了一次普通的合并,生成一个“merge xxx into xxx”的commit,由于上文说到的原因,这个commit节点没有记录diff。当checkout回master再从master merge feature分支的时候,满足了fast-forward的条件,所以没有再次进行diff操作,没有对上次失误进行再次检查。


而code平台merge request默认的操作是—no-ff(这里补充一下,github是有squash选项的,但是code平台不支持),所以会强制再次进行一次diff,这时候上次merge中隐藏的错误得到了一个再次暴露出来的机会,在code review中就可以发现了。


解决方案
这个问题出现的根本原因有两个:
  • 浅层原因:merge时错误处理了冲突

  • 深层原因:没有走code平台merge request,没有禁止master分支直接pull

笔者回顾这个问题时想到,假如别有用心的人利用这种机制上的漏洞,在merge中故意修改代码,这些修改将不会出现在git的任何一次commit diff中,除非对master分支上一个挨一个commit排查。

甚至于在merge时采取squash或者rebase等方法,把这次commit 与其他commit混淆起来,是否就可以彻底把自己隐匿起来呢?

为了避免重现此次错误,强烈建议提高master分支敏感性,设置为protected分支禁止直接操作,所有对master分支的merge统一走merge request!

额外提一句,还应该避免在公用开发机上设置code平台 ssh 密钥,防止被盗用身份提交commit。

是否真的发生过利用这种方案恶意报复公司的案例呢?笔者也是很好奇。


    公众号
    关注公众号订阅更多技术干货!