嘛，反正我不知道你是怎么得出「动态资源不做 cdn 」的。
cdn 系统里动态资源加速才是技术核心，静态托管反而是小事，因为没啥技术含量。

@owt5008137
1. 你这张图里我只看到一个 Merge 。
2. 冲突要解决很多次所以才选择 Merge 听上去像是为了偷懒而选择 Merge 一样？

@aa45942 别闹。
然而我不想多解释了要睡觉了。请自行查阅相关资料。

@aa45942 你说的那是静态资源托管。动态网页部分不能这么玩的。

写这么长，肯定不是给 HR 看的简历。

DNS 根本就是 HTTP 之前的问题。
你说的承载数据二次跳转，也是有做的。比如度娘盘就有自己的跳转中心，跳到某个节点去。
但是你别忘了，跳转的前提是你能承受地址变更。
你好好的网站 www.example.com 突然 CDN 画风一变给你跳转到 www.example.com.lax-node2459-edge.premium.akamai.net 你能接受吗？

@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