前言
在一个大型团队中，bug协同管理是一件复杂的事情，发布经理要追版本bug，运维同学要评估bug影响范围，开发同学要在多个开发分支同时修复同一个bug，很容易出现bug漏提交、漏确认等生产安全问题。
正常也会出现过一起不同分支漏提交bugfix导致的一起P1故障（最高等级），该bug在生产环境进行hotfix时，漏掉了少量集群导致该二次故障。举个相似的例子，某品牌汽车发现潜在安全隐患进行召回，但却遗漏了某个小地区，偏偏在遗漏的地区，发生了安全事故导致有人员伤亡。
我们基于go-git开发实现了通用化的git-poison，通过分布式源码管理bug追溯、查询，可复制性高，适用于所有git仓库，与分支模式和代码仓库无关。bug管理不依赖人与人之间沟通协调，降低了认知负担。
Bug为什么重复翻车
任何软件都会有bug。即使再全面的测试，再细致的代码review，也不能保证线上的每一段代码都bug-free。但是已经识别到的bug，为什么还会重复翻车呢？归根结底，git多分支开发模式会导致bug扩散。引入bug和发现和修复bug的时间异步，口头沟通确认bug易疏漏。
很多人看到前言的故障可能会认为，这只是“不小心”犯了个错误，下次再“细心”一点儿就好了。其实不是的，在百人规模的团队中，人犯错可以说是必然的。
回到前言说到的P1故障，使用git-poison就能简单有效避免“重复翻车”的场景：
- 值班：线上出现故障，定位问题。使用git-posion投毒。
- 开发：bug修复，使用git-poison解毒。
- 发布hotfix：发布完毕后，使用git-poison银针，确保线上所有带bug的版本，都带有本次的bugfix。
如何实现
每一次投毒/解毒，git-poison的poisons远程git仓库中都会生成/更新一条对应记录。不同代码仓库对应不同分支，隔离不同源的posions信息。
{ "poison":"1q234tre5467gcs7yui8ew13", "cure":"9875jgbsw32gtx6djri8sofi0h", "comment":"[to #12345678] service iohang", "editor":"Iris",}
check-commit则应用了git原生强大的history tree管理。
风险观测
运维平台可以集成git-poison来检查线上部署的服务版本是否存在中毒情况。线上风险一目了然。尤其是发现一个新bug后，值班同学可以立即投毒，并通过该页面获取该bug影响的范围。
Before |
After |
1.值班同学发现bug2.值班同学去代码仓库查找引入bug的commit对应时间3.获取线上所有模板找到对应的build版本4.人肉排查该bug是否在对应版本中 |
1.值班同学发现bug2.使用git-poison进行投毒查看影响范围 |
结语目前git-poison已经在公司内部开源，团队已经实现、使用并集成到发布平台管理Bug一年多。开发同学本地使用顺畅，学习成本低，发布流程中多次有效阻塞带bug的版本，并为定位bug影响范围提供极大便利。
