整体看上去还挺不错的，888 还是三星的工艺就拉跨啊，这是一点硬伤。

事实上 iOS 已经有类似的功能了。打开旁白和相关设置，进入放大器 App 会为你描述当前镜头场景，B 站有 up 做过相关视频。

code-server

@Cielsky 京吹准确的说是京阿尼的吹响上低音号

@sagaxu #22 😎同，还有次解密活动官方送了好几个月

这和是什么地方的有关系么...难不成送个兵马俑比较好？

目前在用 MX Master3

@statumer #5 我也觉得确实是 cherry-pick 才会出现这种情况，为什么我会认为是 merge 呢，这里有两个原因。

第一个原因是 https://martinfowler.com/articles/branching-patterns.html#release-branch 这一节中 release 的 fixes 到 mainline 的时候的用词是“merge”（ Any fixes to these defects are created on the release branch and merged to mainline.）。

第二个原因是 Martin 回我的时候 F1 和 F2 到 mainline 的时候也是用的 merge 。

所以我先入为主的认为是用的“merge”命令，如果用 cherry-pick 的话确实就说得通，两条线没有形成树形结构，M7 那里 merge 回 release 的时候确实有可能产生冲突。

但是如果 F1 和 F2 使用“merge”命令合到 mainline 到话形成了树形结构，M7 合回来的时候确实不会有冲突（如果不加--no-ff 的话 release 指针直接快进到 M7 结点了）。

@msg7086 #1 我又实际试了一下，我觉得从 M7 那里合并回来的时候，会不会因为 F1 和 F2 产生 merge conflict 分两种情况。
第一种：F1 或 F2 向 mainline 合并（ merge ）的时候有冲突，这时候在 mainline 产生的 merge commit 解决了冲突，最后再向 release merge 的时候确实直接快进了（可以想象成 release 指针到了树的前面），git 确实自己就可以处理好。
第二种：F1 或 F2 向 mainline 合并（ cherry-pick ）的时候有冲突，解决冲突后产生了 F1'和 F2'，最后再向 release merge 的时候确实可能产生冲突（因为这时候并没有产生树形历史）。

@msg7086 #2 具体这个例子来说，“reset hard 到 mainline”是不是指 reset hard 到 M7，然后再 reset soft，再提交？可这感觉不就是复制了一个 M7 这个提交吗？

我也想再买个安卓板，用来玩玩游戏。Matepad 11 应该不支持 Google Play 吧？所以不打算考虑了，还是等小米平板 5 。

@ericwoflskin #14 优先消耗电池壳的电，不会流经电池

搜简中内容后面一般都会加特定网站的关键字

@qinxi #14 昨天试了下，docker 和 plugin 形式的都试过了。在 iPad 的浏览器上有 bug，时不时的会突然的局部放大。

@tqyq88 #89 还是你秀，哈哈

还有违反一点点这一说，真实笑死了

@xrr2016 #6 command+shift+5 自带的录屏，iPhone 语音备忘录录音，最后在 iPad 上用 iMovie 合成导出。

@registerrr #1
@dot2 #2
谢谢~