文字来自【史图馆】中国历代疆域变化新版1 文明起源。
该篇所述时间从新石器时代早期到公元前1099年（周文王即位前）。
约公元前12000年～公元前7000年
新石器时代早期，陶器在中国境内出现。这一时期的部分遗址还出现了农作物栽培的痕迹。
于家沟遗址：距今约5000-14000年
转年遗址：距今10000年左右
东胡林遗址：距今约10000-9000年
南庄头遗址：距今约9700-10500年
上山遗址：距今约9000-11000年
仙人洞遗址：距今约8000-14000年
华垱遗址：距今约10000年
玉蟾岩遗址：距今约12000-8000年
甑皮岩遗址：距今约12000-8000年
在Hexo部署笔记这篇文章里，我用我自己的亲自实践详述了如何把Hexo部署在自己的服务器上。
但是有一天，我突然想到一个问题。为了写个博客，我要在电脑上装Node.js，装Hexo，装Git，还在服务器上煞有介事地建了一个git仓库，结果只是用来当一个静态文件的中转站，把自己电脑上的静态文件拉过来，然后触发git的钩子把这些静态文件再一股脑复制到Nginx的目录中。如果有一天我换了电脑，那个博客的源文件都在原来的电脑上，服务器上只有一堆傻乎乎的静态文件，想想都觉得很划不来。于是，我干脆把Hexo博客的源文件也通过git上传到了服务器上，换电脑或者需要用别的电脑工作时就用git把源文件clone下来，然后再像之前那样生成静态文件，上传到服务器来更新博客。
于是新的问题冒了出来：我都把源文件传到服务器上了，我为什么不能让服务器帮我做这些生成静态文件并部署到Nginx上的事情，非要在别的电脑上吭哧吭哧地安装Node.js、安装Hexo，然后执行hexo g、hexo d这样的重复操作？这样搞好后，换了新电脑，我唯一需要做的就是把源文件clone下来，改好了提交上去，别的都不用管。
我写博客这么想，写代码的程序员自然也会这么想，写好代码提交，编译测试发布一气呵成，根本不用在自己电脑上一套流程跑一通（对于许多大项目甚至是不可能在自己的小机器上执行编译测试这些操作的），这波操作就是程序员不时会提到的持续集成和持续部署，英语缩写分别是CI和CD。
现在，假设我的电脑上，除了系统本身、博客的源文件、Git客户端外，一无所有。而服务器上，什么都没有。博客的源文件是从老电脑那里复制出来的，所以hexo的那些框架，自己的老文章，都有。Git客户端要么是Linux、Mac系统可以很方便地安装，要么是Windows系统可以从网上下载一个绿色便携版。服务器上本来可以有一个存了静态文件的仓库，但是对于这个持续集成部署的教程来说，并没有什么用处，干脆就把它直接去掉了。
以下服务器的命令皆基于Ubuntu。如果你使用的是CentOS等系统，那么安装软件、软件配置文件的位置可能会有些不同。
如你所见，这个网站是基于Hexo的。现在基于我自己的部署步骤，记录一下整个部署过程。
本来，要搞一个个人博客，我之前想采用的是WordPress。但是在国内，不知道WordPress的官网抽了什么风，我当时在下载时动不动就来一个429 Too Many Requests错误，这就算了，在我要下载安装一些插件时，这个429 Too Many Requests错误便阴魂不散。所以干脆就用了hexo。
根据Hexo官网的说法，Hexo是一个快速、简单、强大的博客框架。我们可以用Markdown或其他标记式语言来写文章，Hexo将为我们生成静态的网页文件，并配上漂亮的主题。
重点在“静态”这两个字上。这意味着，与WordPress这样的有一个后台管理界面之类的动态网站不同，Hexo做的事情是把你用Markdown写的文章转换成浏览器可以直接查看的网页，所以，你要在本地写好你的Markdown文件，在本地用Hexo转换成网页，然后将这些网页文件上传到服务器的对应位置。因此，所有对文章的改动都是在本地进行，然后上传到服务器的，这和你登录服务器的后台界面写博客完全不同。也正因为如此，有许多人觉得Hexo比较麻烦，因为他们不熟悉从本地上传到服务器的工具比如git；而许多人则觉得Hexo特别简单方便，因为上传的是静态文件，因此服务器不需要进行太多的配置（比如安装数据库、PHP等），甚至只需要上传到GitHub Page、Coding等平台就能直接开一个属于自己的网站。
那么言归正传，开始Hexo的搭建。