背景
CVS、SVN、Git、ClearCase和VSS这五种常见的代码管理工具。
当你想发布自己的想法，或者学习内容时。这个时候可能你的选择就是在各大平台发布，比如说：简书、csdn、掘金等一些公开的平台。但是这样你的数据就是属于别人了，如果有一天那个平台关闭了，那不是你的多年记录的内容都没有了。可想而知你当时的心情是多么丰富多彩。转念一想那我自部署一个项目，那你不是需要购买服务器，拥有一个随时可以访问的节点。但是这只是以一个个人记录的博客，感觉没有必要额外出现一笔开销。
简介a
涉及到gitlab、git、hexo的使用，然后其使用方法了大家可以自己在百度上去了解一下。关于hexo使用方法了，我在本文的结束地方粘贴了对应的文档。
简单的介绍一下我们会用到的git、gitlab、hexo的起源。
git：2005 年的时候，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux的缔造者 林纳斯·托瓦兹）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。
gitlab: GitLab由乌克兰程序员DmitriyZaporozhets和ValerySizov开发，它使用Ruby语言写成。
hexo：Hexo 最初由Tommy Chen于 2012 年创建和维护。从那时起，它已经帮助成千上万的人建立了他们梦想的网站/博客。
正文
所以了这是个时候你就可以结合hexo与github/gitlab仓库做一个个人博客的快速部署，基本三分钟搞定。搞不定的话，那就说明你还需要提高自己的手速了。
进入正题：直接上操作指令
# 首页安装hexo-cli，如果你没有npm指令，请下载安装nodejsnpm install hexo-cli -g# 查看hexo的版本信息，看是否安装成功了hexo -v #创建项目，blog是你的项目名hexo init blog#进入创建的项目cd blog#安装依赖npm i#创建你的第一篇博客hexo new "hello world" # INFO Validating config# INFO Created: ~/Desktop/open_source_project/blog/source/_posts/hello-world-1.md# 编译内容hexo g#启动服务，查看编写 内容hexo s |
会自动给你生成对应的md文件，可能这个你需要熟悉下markdown语法了。
这个时候你的本地项目就已经建好了，现在只需要提交到gitlab了。（我这里只说明了gitlab，github的可以研究一下，比这个简单一点）
在gitlab创建 一个公开的项目，项目名：<你的 GitLab 用户名>.gitlab.io
# 在你的项目根目录下创建.gitlab-ci.yml，然后添加如下内容。注意这个node的版本最好和你本地的一致,only的值最好是你要展示的分支image: node:10-alpine # use nodejs v10 LTScache: paths: - node_modules/before_script: - npm install hexo-cli -g - npm installpages: script: - hexo generate artifacts: paths: - public only: - main |
把你的项目添加到创建的gitlab仓库中
#初始化本地仓库git init#添加远程git地址，jevonk是我的gitlab用户名git remote add origin https://gitlab.com/JevonK/jevonk.gitlab.io.git#添加需要管理文件git add . #提交内容git commit -am "page"#强行推送到远程, 注意可能遇到主分支是受保护的，无法推送。自行百度处理git push -f origin main |
其实上面跟大家说到关于.gitlab-ci.yml文件的配置文件，这个文件就是你的项目自动部署到gitlab上他需要的部署方式。
然后其实这个是过程如果只是在服务器上有一个git的服务端仓库，也是可以实现类似的效果的，就是可能需要写的东西变多了。
这个时候我们就可以了解一下关于git的钩子函数了，他可以监听你的push操作，然后做对应的部署操作，当然你定义好函数的
现在可以https://<你的 GitLab 用户名>.gitlab.io去访问你的blog了。这里域名也是可以更换的，大家有兴趣可以去学习一下。
最后说明一下hexo还有很多不一样的主题，大家可去任意挑选。如果有时间的话，也可以自主开发主题。
其官方地址：Hexo
扩充
git的钩子函数
pre-commit、prepare-commit-msg 、commit-msg 、post-commit 、applypatch-msg 、pre-applypatch、post-applypatch、post-checkout、post-merge、pre-rebase、post-rewrite 、pre-push、pre-receive、post-receive、update
提交工作流钩子
前四个钩子涉及提交的过程。
pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。
prepare-commit-msg 钩子在启动提交信息 编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。
commit-msg
post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
电子邮件工作流钩子
你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。
第一个运行的钩子是 applypatch-msg
下一个在 git am 运行期间被调用的是 pre-applypatch 。 有些难以理解的是，它正好运行于应用补丁 之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。
其它客户端钩子
pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase 钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程不匹配。
post-rewrite 钩子被那些会替换提交记录的命令调用，比如 git commit --amend 和 git rebase（不过不包括 git filter-branch）。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。
在 git checkout 成功运行后，post-checkout
在 git merge 成功运行后，post-merge 钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
pre-push 钩子会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更新操作（一个非零的退出码将终止推送过程）。
Git 的一些日常操作在运行时，偶尔会调用 git gc --auto 进行垃圾回收。 pre-auto-gc 钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。
服务器端钩子
除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器， 或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态， 所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。
