因为要经常和主分支保持一致, 所有其他开发分支都经常的和主分支做 merge 操作,签入一个隐性 bug 以后很容易导致其他分支也被感染, 各个分支在修好之前会产生非常多的脏数据, 应该如何避免或者减少发生这种情况?
1
shoaly 2017-03-20 17:59:39 +08:00
合并分支的时候 认真查看是否符合你的标准.
bug 也是本身就是一段文本, 到底是不是 bug 还真取决于 观察者视角. 有可能你觉得文本格式没对齐也是 bug. 当然其他逻辑错误类的 bug , 可以通过各种单元测试跑一遍来避免, 这个单元测试理论上应该在 commit 提交到主 repo 的之前, 自动跑的, 没通过测试, 根本不让入主 repo |
2
purebluesong OP @shoaly 是一个完全能通过单元测试但是过不了回归测试的隐性 bug, 合并分支的时候从代码上很难看出来, 其实主要麻烦价值又低的地方在于修复这些脏数据. 现在使用的是缓冲的策略避免大范围波及, 可是缓冲分支的脏数据也蛮头疼的
|
3
shoaly 2017-03-20 23:20:56 +08:00
@purebluesong 这...不属于 bug 了吧. 可以定性为缺了一个 test, 所以修复完这个 bug 之后, 重新添加一个 test
然后客观的说 这其实就是 开发的过程. 不停的加功能, 不停的修补 bug 想要开发过程跟设计跟女友生日约会一样完美, 其实想要每一次 commit, 都是一次完美的照片, 没有闭眼没有 2b 抢镜 , 漂亮的像个 ppt. 倒不如就让那些 2b 的代码留在 commit 里面, 时不时 git checkout 或者 git blame 一波, 1 可以嘲讽队友 2 可以用来当作教科书, 教育后人: 老夫当年就是在这里, 这里 2, 这里 3 挂过. |
4
purebluesong OP @shoaly 2333 说的极是
|
5
SoloCompany 2017-03-21 00:30:48 +08:00
没经过回归测试,甚至开发分支就直接上线了吗?
如果开发分支仅仅是开发分支,又何来脏数据呢 你如果把开发分支直接灰度了产生脏数据,这只能 eat your dog food 了 |
6
purebluesong OP @SoloCompany 测试也会产生脏数据, 灰度发布的情况也有,毕竟有些热修复会导致更多的 bug
|
7
SoloCompany 2017-03-21 10:29:46 +08:00
@purebluesong #6 那叫线上测试,不叫测试
|
8
purebluesong OP @SoloCompany 666
|