直接说不行吗？别折腾这些有的没的，没意思。混熟了大大方方的表白呗。

尽量不要和父母一块住。没其他办法。中国父母我见过的，就没有能够真正尊重个人边界的。当然这也和六个钱包有一些关系。

化石和老旧的正牌游戏机。

作为从 Windows 转 MacOS 的人来说，我承认至少在 Jetbrain 产品里，MacOS 快捷键给力多了。比如 command + ->直接到句末，还有 option + ↑选中单词。Windows 下也有但是就没那么方便，这俩太常用了。

@ke2933 24
问题是没有滚动条，有时候我就压根不知道还有其他内容。

@yyfearth 16
是的后来我找到设置的地方了，但是细条好像没办法改粗？用了半年 MacOS 绝大部分都适应了，就这个还不行。

@villivateur 说得好，我现在对智能化家电十分警惕，最好都是傻瓜的。你一个洗衣机还要智能。。。

@SummerDruid 11

苹果的审美有些不错，但是滚动条我觉得一般，就那滚动条过细且有时候还隐藏起来的风格，实在是不适应。

@Scarletlens 10
求问是哪个功能？自带的似乎模拟的也不好，最多就是到 Win7 简洁版这样。

还是 Win95 的界面最舒服，现在搞平面化实在是不好用。还好没到苹果那样丧心病狂干脆把滚动条隐藏的。

换个方式，找个妹子出去骑车登山啥的要好多了，到时候荷尔蒙提醒你去练。

@aureole999 我觉得你说的有道理，应该就是这个原因，就是同一个修改用了两个 hash 。感觉真是棘手，就差这个场景不能解决了。

不用这么麻烦，不断发明新的词就行了，中文用完了可以用外文。。。

@aureole999 4
多谢，我其实更想知道 conflict 的原理，就是说，我能根据原理，判断出来这次 merge 一定有冲突，就行了。可是手册上似乎并没有写的很深入，也许我没找对地方。

现在的问题就是，不懂为什么第五步会有那个 merge conflict 。

我重写一下：

第一步：从 main 分支创立两个 feature 分支，B1 和 B2;

第二步：B1 分支会创建两个新文件，F1 和 F2 。然后 B1 push 到 origin/B1 ，建立 PR-merge 到 dev ，成功；

第三步：B2 开始工作，修改了一个旧文件 F9 ，然后照样 PR-merge 到 dev 分支，接着又把 B2 PR-merge 到 staging 和 main 分支；

第四步：回到 B1 分支，Looker UI 强制 Pull & Merge ，因为检测到 main 有变动。其实完全没必要，因为 B1 和 B2 处理的文件完全不同。而且更重要的一点，这个会造成下一步的合并冲突；

第五步：还在 B1 分支，对 F1 做了一定修改之后，再次 PR-merge 到 dev 分支，触发合并冲突。

@aureole999 1
不好意思我没说清楚，早知道用英文说了。所谓推送就是 B1->origin/B1 然后 PR-merge 进 dev 。

对，就是你说的这个流程，但是没有后半句本地那段，因为 Looker 就是本地。流程就是：Looker 里 create new branch B1 from main ，然后 B1 Commit & Push ，然后转到 GitHub 里，创建 B1->dev 的 PR ，最后 PR-merge ，大致就是这样，等等。