@fov6363 已经那么干了的话先让他认识到问题，然后 feature 分支直接 reset 回到 origin/feature 即可，如果 D' 之后又开发了东西，rebase 回去

@fov6363 我觉得你没看我的回答

顺便，这个过程的实际操作是 git fetch && git rebase （取代 git pull ），现在 git pull 增加了 `--rebase` 开关可以直接用

Bob 在已知 github 的状态的情况下，不应该做这个把 feature 从 D rebase 成 D'的操作（已经 push 到 remote 的 commit 不应该 rebase ），更不需要解决 Anna 的什么东西（因为 Anna 的 E 压根没有 push，Bob 也不可能得知 E 的信息）

rebase 更多解决的是 Anna 线 push E 到 github，Bob 同时（未拉取最新修改）在 D 上 commit 了变更 F 后，发现 push 失败

此时用 rebase 把 ABDF 变成 ABDEF 再 push,使 feature branch 的结果为一直线，避免增加 merge commit

湿布擦吧，等更好的

考察能力，而非知识
考察经验，而非经历
试探对方能做什么，能力边界在哪里，是否能够突破，而不是遍历对方不能做什么，在能力边界八丈远的地方刁难对方

我觉得面试官不好当的一个很大的因素在于，作为面试官太难得到对面试质量本身的反馈了，面试和招人本身频率就低，入职与否，入职后表现和面试本身的质量相关性不高（除非入职后发现是个雷，那很明显是面试需要改进），更别说反向来说，筛掉的人是不是有面试不合理导致的误筛几乎不可能得知，要改进提高面试能力，更多只能靠自己 YY

个人更倾向反过来，代码生成文档，毕竟让程序员写代码和让程序员写文档的难度差了不止一个数量级

另外，想换节点可以趁早换，或者 at livid 处理，换节点重发一样的帖子不好

你要和 redux vuex 抢饭碗，或者是想整合一起用，凭啥，建议在 readme 第一屏内显著写明白

另外点进去看了看，出 promise 不 return 造成 uncaught reject 的 sample code 不敢恭维

暂时先不 star 了

我现在基本形成了本能反应：看到这种开头一张图，内容里面大量副标题和加粗的公众号文笔 就自动判定成垃圾水文，速读垂直扫几眼直接拉到底，看到一排链接，嗯，枪毙，再见

SAP?

想去互联网公司趁早，等你简历上有了两家三家非互联网的公司，再跳阻力就大了，可以再找找

不想去互联网公司的话，autodesk 风险小，另一家你得自己去调研确认是有核心竞争力而不是风口上的裸泳公司

对于高端 /稀缺的职位来说，一家公司在招聘换句话说有职位空缺这件事本身就是某种意义上的商业秘密，猎头的一个作用就是保护客户公司的商业秘密，尽量避免无谓的信息泄露

当然也有的是虚张声势，类比中国有 5 所 top3 大学，10 所 top5

嗯嗯，算力分布好做，数据分布难做，事务分布 (还要自动地，业务无关地) 那是地狱难度了

window tidy / mosaic

@RoyGo "以上"

想到哪写到哪儿

1. “时间预估” 对于外包和公司自有项目的意义和含义是不一样的。前者是真的雷打不动的 deadline，而且基本不能以客户需求变更或其他意外为借口来打破，但后者相反，有合理的问题发生 delay 是正常的，但代价是绝对不能用乘法（至少我认为这属于不负责任） 个人没做过外包所以对外包的描述是瞎猜的，下面所有的看法都是基于公司自有项目

2. 时间预估之所以叫预估就是因为不准。实际上每个任务的完成时间都不是一个数字，而是一个概率模型（ 30% 半天做完 40% 一天做完 25%两天做完 5% 需要更长时间）而你给出的那个实际的数字，一般应当是 80%左右能做完，10%左右稍微超一些时间 or 加班 能做完的一个预期时间

3. 一份好的时间预估中，任何一天以上的任务都是不被接受，需要进一步拆分的

4. 以月为单位的项目当中，用几天的时间来做技术文档，并最终给出详细的时间预估是合理且必要的，这样的项目中表结构都没有定，技术文档都没有，你就给我时间预估我是不信的

5. 如果你有技术 leader，可以和他直接沟通你的困难，包括技术的选型和时间预估的困难，另外你的时间预估必须和你的搭档核对，并且写清楚你们所有的配合的时间点，什么时候定公共的数据结构、你们内部的接口形式和字段，什么时候你们两部分可以联调等

6. 题外话，要不是看到下面的数字列表还算整齐，我看到第一行其实就有关窗口的冲动。重复 3 遍想表达什么？你用什么语言和项目时间预估也关系不大。 包括你后面 7 里面写的一堆，你以为会呛你一句风凉话让你离职的人会仔细看你写的那么多东西？或者是看了以后他们就会认真给建议了？ 论坛里面的一些信息噪音当作没看到就好（ V2EX 甚至有 block 功能），不要和他们战斗，更不要这样因为他们影响其他人的阅读体验，要不是有数字列表方便我扫一眼就跳过，我可能就跑了

没去过大厂选大厂，更何况是营收部门

去过大厂还问出这样的问题的话…那还是蹲在大厂混日子吧

建立自己的知识体系

“建立自己的” - 不是去搜一下看一个脑图完事儿，也不是死记硬背，而是真正自己理解的，即使忘了也能从头在白板上稀里哗啦画出差不多的知识体系
“体系” - 不是线性的清单，而是有组织的，从上级概念慢慢具体到知识点的体系

别人叫你看源码你就去看源码是没有用的，也大概率看不懂，就算看懂了你还是想问“我看懂了 vue 的代码，迷茫了，不知道该学什么”，不如说你可能都无法判断自己是否看懂了

技术水平还是其次，最要命的是心智根本不成熟