这里所指的博客，包括传统的博客，比如新浪博客，CSDN技术类博客，也有随着时代变迁，博客的某种变体，比如微博，轻微博等。
博客早期推动了传统纸媒向网媒的发展，让很多人有了可以记录自己生活点滴的东西，同时在某种形态上，也是一种自媒体，给人平台展示自己的思想，技术，心得等。
博客具有的性质:
- 媒体性质
- 内容载体
博客兴起10余年，形态也发生过变化，比如微博就是一个。但是微博并没有取代传统博客，而是作为传统博客的一个延伸。微博可以有效的加快信息的流动。但是信息的沉淀仍然依赖于传统博客。
在互联网时新日异，各种竞争者层出不穷的情况下，博客这种不变却依然坚挺，主要是因为其作为知识的载体，能够承受很大的冲击。 博客的形态本身很难改变，而且经历这么多年，用户已经接受甚至依赖这种形式。但任何一种事物，都应该思变，跟上时代步伐。 博客痛点
博客作为内容的最终呈现形式，无法沉淀过程，难以从特定点重新开始 作为内容的一个载体，博客其实应该记录内容产生的的过程。所谓数易其稿，被易的稿子便是其轨迹，到目前为止，博客没能解决这个问题。
我们希望博客能够成为内容变化记录的载体
现有的博客基本都没有协作功能。如果有，也是极其有限的。 作为内容的载体，协作是不可避免的。协作不仅仅是指的，多个人完成一篇内容，还包括同一篇内容不同的人可以衍生出更多的内容。但是这种关系需要被记录下来，这种关系是客观存在的，只是现在都是被割裂开来。好比现在的转发。很多原创作者讨厌转发，可以理解。因为’坏的制度可以让一个原本可以很好的行为变坏‘，而好的制度可以让某个被人讨厌的行为变得找人喜欢。同样是转发，微博就让转发变成了一种受欢迎的东西。
我们希望博客能够作为创作的载体
通常在架构设计里，我们会前后分离。后端服务化，前端只是作为展现和交互层。 同样，在博客进化的过程中，我们也需要运用这种思想。
我们保留博客现有的交互模式以及外在表现形态，但是后端采用git技术进行存储。
后端方案可以采用：
- 一个博主就是git仓库。一篇博文是仓库中的一个文件。
- 一篇博文就是一个git仓库
两个方案都能解决 记录变化过程 ，但是第一种方案只能部分解决多人协作的问题。因为只有仓库能够fork,单个文件无法做到。
引入Git后：
- 传统的博客形态得以延续
- 将创作的结果和过程统一在了博客平台
- 多人协作将会得到完美解决
采用该方案，我们大脑模拟一遍未来博客的一种使用形态:
打开博客，写了一大段，每隔一段时间，系统会 自动保存，保存的过程中系统会按时间戳commit到git存储引擎中。此时右侧会出现记录列表，用户可以随时点击某个时间戳看到刚才写的东西的某个状态，时间戳可以修改成有意义的文字。
过了两天，用户再过来写，觉得后面有一段写的不好，于是点击commit历史记录列表，从其中的某个状态重新写，会形成一个分支。
最后用户写完，点击发表。其他的阅读者可以看到这篇文章的最终状态。当然，作者可以选择其他用户是不是可以看到这篇文章在任何一个时间的时间状态。 这篇文章很受欢迎，于是我点击了侧边的 ‘转载’ 按钮，这篇博文自动以当前状态进入我的博文列表。接着我修改了这篇转载的博文，我觉得我改的很好，于是我点击我侧边的 PR(请求合并)按钮，希望我修改得，能得到源作者同意，合并进他的文章里。
对于一篇需要精心打磨的内容，这种协助方式很好，并且有效的带动了博主之间的互动，优化了‘转载’的内涵。
当我们记录了原创和转载的关系后，我们可以对流量进行控制。比如通过标签聚合内容的时候，当点击一篇转载的内容时，自动跳转到原创的内容中。这样，转载就成了原创的流量渠道，我估计这个时候，是没有人会怨恨转载了吧
其实CSDN code 平台的文档项目已经有类似的性质，但是变革依然不够彻底。