@herozzm 折扣了多少？对访问速度影响多大？

@herozzm 我说个恶心的做法。
装上 ESXi ，开俩虚拟机，做 p2v 把原来的环境打包进来，另一个做新环境，然后内网打通以后反代。

@herozzm Nginx 反代 Apache 就好了。无非就是 LANMP 的架构。新系统运行在 Nginx 上就行。
而且这样迁移也方便，你可以一个一个把网站从 Apache 搬进 Nginx 里。（当然也可以就这么放在原处）

@gdtv 是的，魔术头。不过也有一些是根据实际语义去探测的。
比如 docx 是一个 zip 文件，但是判断成 zip 意义不大。所以工具可能会继续探究其中包含的 xml 文件的结构，来判断具体的文件类型。

Linux 有 file 工具。 http://linux.die.net/man/1/file

@xAx 我司的 Merge 乱的不行，要 Revert 或者 Blame 的时候蛋疼无比。
不过你说的没错，这主要是团队管理上的需求。

@owt5008137 GitHub 上 Rebase 上游才是标准做法吧？我倒是很少见到 PR 要 Merge update 的。
至于你提到 hg 我就觉得更好玩了。
我觉得 hg 最为人诟病的地方就是开分支有代价而且不能随便 Rebase 。
我之前维护 hg 版的 x265 mod ，需要自己维护一个补丁串，最后只能在 bitbucket 上开一个 Patch series 项目，每次上游更新了，本地就要弹出所有补丁， update 到 tip ，然后再把补丁一个一个打回去，打出问题了还要被 mq 恶心一通然后去处理合并冲突。然后每一个想 fork 和想贡献代码的人都跑来问我这货到底要怎么用在官方 repo 上，要怎么 fork ，要怎么 pr 。
我很想知道你用 hg 的时候是怎么解决这些问题的。
反正我是醉得不行，维护了几个月实在受不了了，老老实实切到他家的 Git 镜像上开分支 Rebase 了。

最后上一张我司的 History 。三五人的小团队的项目。作为处女座我忍不了 Merge 。然而 YMMV 。
https://i.imgur.com/8Xa6TTa.png

@owt5008137 rebase 和 merge 的用途本来就不同，不管是该 merge 的时候 rebase ，还是该 rebase 的时候 merge ，都不太合适。
我不知道你是怎么得出「不要 rebase 」这种结论的。
svn 的分支切换和 git 的分支切换差得太远了，所以我更不知道你怎么得出「为什么不用 svn 」这种结论的。
至于为了让 git 表现得像 svn 才开 rebase ，我就呵呵了。
是不是贵司觉得 history 太单调了不好看所以让大家多玩玩 merge 把 history graph 搞复杂点才好啊。

@Threezj 那可以了，值这个价钱。

30 块还好吧，这 30 块是多久的。

@Mayuyu 你需要读写分离，多机写入。
但是不管怎么搞，这样的设计都还是有问题的。

Ruby Metaprogramming II

@owt5008137 git 最大的特色是分支管理，又不是 merge ，为什么不能动不动就 rebase ？
能频繁 rebase 才能体现出 git 的分支管理特色。

1. 我从初中开始 715 ，早上去学校晚上看技术，周末可以睡晚点不过晚上基本也是 12 点 1 点。
现在身体状况已经大不如前了，晚上 2 点睡早上 8 点起感觉很困。
2. 上班以后 965 的原因主要是公司会希望你好好休息，这样工作时间效率可以大大提高。
人疲劳的时候犯错几率极高，这也是为什么应该严格避免疲劳驾驶，因为会出人命。
疲劳工作出人命的几率低些，但是出代码命的几率会高得多。
等你哪天熬夜不小心删了数据库或者崩了哪个系统的时候你就知道休息有多重要了。
3. 下班以后的时间可以学习新技术和黑科技，给公司带来的好处比坐在电脑前写代码来得多。

看看大企业就知道了，除非是初创阶段的合伙人（最后至少应该能分到上百万美金吧），否则大家都是正常作息。
就连抠门的亚马逊也是正常作息+OnCall 。
如果 996 真的那么有用，为什么那些大公司不这么干呢。

其实我只是来看看撸主有没有出新的四格漫画单行本的。

@bsns 这是个悖论。如果被罚了一千万，那这就不是造谣，因此不能被罚一千万。

@holyzhou 抄袭作业但不署名是重罪。