@xppppsfg 一开始是 CPU 、mem 反复横跳。找了人来检查说是主板内存相关的位置坏了。

@freetree 是主板坏了

@maolaohei 微星的主板

@maolaohei 是

北上广深有很多加班狗跑到成都，把成都的互联网环境搞的乌烟瘴气。你现在去成都，工作更累，工资更少。

@across 就是一方看起来在敲键盘，但实际上他们的人物都是电脑自动在操控。参考 Google 的 AI 在星际 2 上面已经可以碾压人类。

有一说一，辩论的意义不是辩出真理，而是比赛谁的说话更有技巧，更能煽动人心，更能颠倒黑白。面对面辩论的时候，一方说不过对方，但是不能下场打架，只有看起来和和气气继续到比赛结束。但是如果是线上，一个人辩论不过另一个人的时候，可能会气急败坏开始人身攻击。

用户不关心你新增了什么功能，他只关心原来用的好好的功能怎么找不到了。

@zxCoder 是的，所以第 6，7 步的间隔时间要短。

有几个基本原则：
1. master 分支不能直接修改代码。他里面的代码变动只能通过 merge 引入
2. 要增加新功能或者修改 bug 时。先把本地的 master 分支更新到最新。然后基于它创建一个开发分支 dev
3. 在开发分支 dev 修改代码。
4. 先把 dev 分支的代码 commit 。但不要 push
5. 切换回 master 分支，git pull 更新到最新
6. 切换到 dev 分支，把 master 分支 merge 到 dev 分支。如果有冲突，就解决冲突，然后继续 commit 。如果没有冲突，进入第 7 步。
7. 切换到 master 分支，把 dev 分支 merge 进来。第 7，8 步的时间间隔一定要短。正常情况下，这一步一定会成功。
8. 提交 master 分支到远程的 master 分支。完成。

如果团队有持续集成的流程。那么第 8 补是提交到持续集成专用的分支，CI 系统会自动发起 code review 给相关的人。他们审查完毕通过以后，CI 系统自动把代码合并进入真正的远程 master 分支。然后自动部署上线。

小红书的运营老大和产品老大天天撕逼，根本不认真做事情。而且还 996 。不要去。

我住在闵行区，整租一室一厅一厨一卫，72 平米。租金 6000 一月

@howeroc 八个大箱子，没法带

@LouXiaShiZhu 床是房东的，不用带走

@adgad2 去上海了

我马上就离开杭州了