同事偷偷git commit导致分支被污染怎么办?

2,597 阅读6分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第18天,点击查看活动详情

前言

随着前后端交互规范的发布,各位前后端研发同学都对自己的接口代码按照规范进行了整改,对于这次整改组内要求是前后端分别用一个分支统一进行管理,待所有研发的接口代码都整改完毕后统一合并入dev和test分支。

时间回到某日,测试同学在更新了 xxx 版本的代码包后发现功能性的 bug,同时还有 xxx、xx等界面的字段展示不全了。

随后研发同学查看后发现某研发同学提交在dev分支的代码出现在test分支了。

于是造成了git的分支代码污染~🐶

问题排查历程

  • 由于前后端规范整改涉及的代码提交量较大,加之后端研发流程要求需要在 feature 分支统一开发完毕后再合入 test 。所以一开始排查的方向是查找是否有研发同学在 jira 还没审查通过的情况下将feature 分支的代码合入了 test,也就是找是否在git log中有没有Merge branch '前后端规范整改feature' into test这样的记录。经过一番搜索后发现并没有从feature分支合入到test的记录,只有从feature分支合入到dev(问题①)的记录

如图:

image.png

  • 由于从git上无法知道本地的操作记录,从分支图上无法确定push的时间点,所以只能在这次从feature分支合到dev分支的研发同学机器上执行git reflog --date=iso,git reflog origin/test --date=iso指令查看本地的引用日志

关于reflog可以参考

研发A  git reflog --date=iso

image.png

  • 从git reflog --date=iso指令的结果可以看到在4月12号10:23:32在本地xg/EMR-1736进行了规范修改的commit操作,并于4月12号13:04:03进行了解决冲突的commit操作,这与分支图的展示一致,然后在git reflog origin/test --date=iso结果中我们可以看到在4月12号13:04:10进行了push origin/dev的操作,从而确定了这位研发同学确实把前后端交互规范整改的代码push到了dev。

研发A  git reflog origin/test --date=iso

image.png

  • 由于没有从feature分支直接合入到test的记录,那么就只有一种情况,一定是某位研发同学将dev的代码合入了test分支从而导致test分支出现了feature分支的代码。于是接下来的排查点就是查找在4月12号13:04之后从dev分支merge到test分支的操作,仔细分析分支图后发现在**4月22号21:57研发同学的fetch操作使得他本地的dev与本地的test合并(问题②)**了。那么在这之前这位同学一定在本地做过从dev合并到test的操作,并且在这之后进行了push操作。

  • 分别在该同学的机器上执行git reflog --date=iso,git reflog origin/test --date=iso。我们分别看下本地的引用日志

  • 从git reflog --date=iso结果可以看到,4月22日21:46这位研发同学在本地从dev切到了test分支,随后做了merge dev的操作,也就是把本地的dev代码合到了本地test中。然后在21:57将origin/test合并到了本地test,也就是在这里使得本地dev跟origin/test进行了合并(问题②)。这个时间点与分支图里的时间点是对得上的,说明两个分支的合并确实是在这步操作的。

研发B git reflog --date=iso

image.png

  • 现在本地的test分支已经被污染,接下来我们从reflog里面看看这位研发同学是在什么时候将本地test分支push到origin/test的,从git reflog origin/test --date=iso截图可以看到,这位同学在4月23号23:43将本地test分支push到了origin(问题③)。

研发B git reflog origin/test --date=iso

image.png

总结

从上述的排查过程我们可以找到三个问题点。

  • 问题一就是做前后端代码规范修改的研发同学没有遵守规定在所有后端同学都整改完成再将代码合入dev分支,这为之后从dev合到test的误操作埋下了隐患。若要避免此类问题再次发生其一是研发同学自身要提高对代码提交操作的谨慎性,如果还有相同情况发生那么就需要考虑是否要对dev分支进行保护,所有push origin/dev的操作都需要专人来操作,普通研发同学只能提交MR请求;
  • 问题二就是研发同学将dev的代码直接合入了test代码,这是导致这次问题发生的关键操作,在现阶段的git分支管理中这是绝对禁止的。dev分支与test分支都只能从feature分支合并过来,不能直接把dev合入test。因为对于现阶段的git分支管理来说,dev的代码有很大的不稳定性,直接合入test会导致test打出的release包不稳定。由于此操作纯粹是在本地环境进行,要对此类问题进行管控只能加强研发同学的分支管理培训,增加误操作的犯错成本。
  • 问题三是将被污染的本地test分支push到了origin/test,这就直接导致了测试同学打的包是有问题的包。要避免此类问题的再次发生与问题一的处理方式相同,需要对test进行保护,由专人进行合并操作。

综上所述,在现阶段的git分支管理体系中,要避免上述问题的发生如果对feature->dev,feature->test都进行保护的话管理成本会非常之高,MR的审核人将会成为瓶颈。各位研发同学都会等着这位审核人将代码合至dev进行联调,合至test进行发版。所以现阶段比较合适的方式是对test分支进行保护操作,所有研发同学对test分支只能进行MR请求合并,由专人进行push操作。这样即使dev被污染,要合并至test也能由审核人进行最后一道把关。