如何避免签入一个 bug, 波及所有分支这种情况?

[purebluesong]

因为要经常和主分支保持一致, 所有其他开发分支都经常的和主分支做 merge 操作,签入一个隐性 bug 以后很容易导致其他分支也被感染, 各个分支在修好之前会产生非常多的脏数据, 应该如何避免或者减少发生这种情况?

[shoaly]

合并分支的时候 认真查看是否符合你的标准.
bug 也是本身就是一段文本, 到底是不是 bug 还真取决于 观察者视角.
有可能你觉得文本格式没对齐也是 bug.

当然其他逻辑错误类的 bug , 可以通过各种单元测试跑一遍来避免, 这个单元测试理论上应该在 commit 提交到主 repo 的之前, 自动跑的, 没通过测试, 根本不让入主 repo

[purebluesong]

@shoaly 是一个完全能通过单元测试但是过不了回归测试的隐性 bug, 合并分支的时候从代码上很难看出来, 其实主要麻烦价值又低的地方在于修复这些脏数据. 现在使用的是缓冲的策略避免大范围波及, 可是缓冲分支的脏数据也蛮头疼的

[shoaly]

@purebluesong 这...不属于 bug 了吧. 可以定性为缺了一个 test, 所以修复完这个 bug 之后, 重新添加一个 test
然后客观的说 这其实就是 开发的过程. 不停的加功能, 不停的修补 bug
想要开发过程跟设计跟女友生日约会一样完美, 其实想要每一次 commit, 都是一次完美的照片, 没有闭眼没有 2b 抢镜 , 漂亮的像个 ppt.
倒不如就让那些 2b 的代码留在 commit 里面, 时不时 git checkout 或者 git blame 一波, 1 可以嘲讽队友 2 可以用来当作教科书, 教育后人: 老夫当年就是在这里, 这里 2, 这里 3 挂过.

[purebluesong]

@shoaly 2333 说的极是

[SoloCompany]

没经过回归测试，甚至开发分支就直接上线了吗？
如果开发分支仅仅是开发分支，又何来脏数据呢
你如果把开发分支直接灰度了产生脏数据，这只能 eat your dog food 了

[purebluesong]

@SoloCompany 测试也会产生脏数据, 灰度发布的情况也有,毕竟有些热修复会导致更多的 bug

[SoloCompany]

@purebluesong #6 那叫线上测试，不叫测试

[purebluesong]

@SoloCompany 666