任何软件都会有bug。即使再全面的测试，再细致的代码review，也不能保证线上的每一段代码都bug-free。但是已经识别到的bug，为什么还会重复翻车呢？归根结底，git多分支开发模式会导致bug扩散。引入bug和发现和修复bug的时间异步，口头沟通确认bug易疏漏。
很多人看到前言的故障可能会认为，这只是“不小心”犯了个错误，下次再“细心”一点儿就好了。其实不是的，在百人规模的团队中，人犯错可以说是必然的。
图1 (Baron Schwartz "Approaching the Unacceptable Workload Boundary")
上图形象展示了人与人之间的协同成本。10人团队的整体协同一次的沟通次数为90/2=45次，那么100人则是4650次。这个次数只是相互协同一次，大多数场景下，由于bug和bugfix是随时出现的，再加上人的失误 (沟通中忘了某些bug等)，所以一般来讲，一个发布流程至少需要前后同步三次，沟通成本巨大。所以谁能打包票，在这个流程中不犯错？只有通过工具来进行自动化管理才能保证从“不做错”到“做不错”。
如何使用
git-poison基于go-git的分布式源码管理，实现bug的追溯、查询和反馈，灵活&&可复制性高，适用于任何开发模式以及任意代码仓库。另外，git-poison不依赖人与人之间的协作沟通，减少认知负担沟通成本，自动化精准召回bug中毒域，实现poison commit发布阻塞。
图6 git-poison 投毒/解药/银针 （yum install git-poison）
对于开发者，只需要记住一件事：抓紧投毒！
回到前言说到的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管理。
