Hexo: 博客已经一键部署到github，本地源码丢失，怎么找回

Created on 16 Aug 2019 · 17Comments · Source: hexojs/hexo

博客已经一键部署到github，本地源码丢失，怎么找回，github源码和本地的是不一样的，是解析过的

question stale

Source

haocaiMP

Most helpful comment

@SukkaW 我觉得你还是没有明白我的意思，我就拿我的博客来举个例子吧：
仓库地址：https://github.com/yansheng836/yansheng836.github.io

有两个分支：

master分支：用于发布博客，即生成的页面，hexo-deployer-git
blog分支：用于备份博客的数据：博客配置、原生markdown……

当然，如果你不想你的博客的源数据公开，你可以新建一个私有的仓库用于保存备份数据。

每次写好博客，发布需要多加一个备份源文件的动作，如下：

# Writing
# 同步到master分支
hexo clean
hexo generate
hexo deploy

# 手动同步到blog分支上
git add . 
git commit -m "提交信息"
git push origin blog #如果设置了blog为默认分支，可以直接git push

yansheng836 on 23 Aug 2019

👍4

All 17 comments

如果你的博客有 RSS，你可以通过 hexo-migrator-rss 插件从 RSS 中重新得到 markdown 文件。

SukkaW on 17 Aug 2019

建站当初你就应该先做两手准备，部署的同时进行备份，用另一个仓库（或者同一仓库的另一个分支）存放博客的备份，如环境配置、源码等。

yansheng836 on 18 Aug 2019

谢谢大佬们的回复

haocaiMP on 19 Aug 2019

我都是把博客文件放到OneDrive里实时备份异地同步

kakarrot0109 on 21 Aug 2019

👍1

用git恢复

York618 on 23 Aug 2019

@York618
hexo-deployer-git 默认使用 --force，不可能通过 git 找回。

SukkaW on 23 Aug 2019

@York618
hexo-deployer-git 默认使用 --force，不可能通过 git 找回。

参考这个：https://github.com/hexojs/hexo/issues/3676#issuecomment-522299449

那个是发布分支的强制推送，但是他（她）的意思应该是用另一个备份文件的仓库（或者另一个分支）来进行恢复。

yansheng836 on 23 Aug 2019

我先挂了。要不然会有很多来自GitHub的邮件:)

York618 on 23 Aug 2019

@yansheng836 如果是 Git 备份也可能丢失，毕竟 hexo-deployer-git 默认分支是 master。

SukkaW on 23 Aug 2019

@SukkaW 我觉得你还是没有明白我的意思，我就拿我的博客来举个例子吧：
仓库地址：https://github.com/yansheng836/yansheng836.github.io

有两个分支：

master分支：用于发布博客，即生成的页面，hexo-deployer-git
blog分支：用于备份博客的数据：博客配置、原生markdown……

当然，如果你不想你的博客的源数据公开，你可以新建一个私有的仓库用于保存备份数据。

每次写好博客，发布需要多加一个备份源文件的动作，如下：

# Writing
# 同步到master分支
hexo clean
hexo generate
hexo deploy

# 手动同步到blog分支上
git add . 
git commit -m "提交信息"
git push origin blog #如果设置了blog为默认分支，可以直接git push

yansheng836 on 23 Aug 2019

👍4

我觉得一直是你没有明白我的意思。。。
我说的是即使用 Git 备份可能会发生什么、需要避免什么，并不是我不会做什么。

实际因为 hexo-deployer-git 的 force push 行为，所以我不使用 hexo-deployer-git，我使用的是自己编写的 deploy.sh：

SukkaW on 23 Aug 2019

其实我认为hexo-deployer-git 的 force push 行为并没有什么不妥。原因如下：

下面这张图是我对“hexo的主要工作流程”的理解（可能存在问题）：

我认为hexo的核心工作就是：markdown-->装换成-->HTML。在完成hexo环境配置后，我们只需要关注markdown，以及生成HTML页面效果。
一般情况下，都不会去看HTML内容，如果关注，我猜测也是在HTML页面用F12观察页面元素。对于原生的HTML，如果不格式化，会有很多空白；如果你使用了插件压缩文件，那么如果不格式化，可能会出现一行有很多代码的情况。基于这种情况，我认为你基本不会去看HTML文件的源码。
其实对于hexo-deployer-git的仓库，我们只想获得HTML页面，也就是HTML文件的展示效果。而hexo g每次都会生成有变化的文件，如果你本地有文件丢失，那么生成的HTML文件肯定会出现问题。但是出现问题后，你也几乎没有什么可能从hexo-deployer-git对于的仓库中找回你丢失的文件，因为该仓库的文件都是：node.js通过渲染markdown+样式+js生成的HTML文件，也就是说集成的，可能是几个配置文件都对一个HTML产生影响。
我们只需要hexo-deployer-git的仓库给我们提供HTML页面效果，如果本地文件变化，就是生产新的版本发布到仓库，而从未想过从该仓库拉取什么东西！那么问题来了，默认使用强推有什么问题吗？我觉得没有。

补充：

git push -f有什么弊端？最直接的弊端应该就是造成远程仓库的某版本丢失！丢失版本库会让我们的版本管理系统出现问题。
我认为版本管理系统的最大好处就是：可以利用版本回退来恢复数据；但是就针对hexo而言，我们基本上不会去pull部署（发布）仓库，也就是说基本上不会通过部署仓库来恢复数据，（或者说：我们仅仅只是需要简单的版本管理，标记写博客的时间），那么强推到仓库压根就没啥毛病，因为我们又不需要版本回退！
我们只需要备份好本地的配置文件和markdown博客源码。日常而言，每次写完博客，hexo g生成该篇博客的HTML页面，然后发布到部署仓库，展现HTML页面效果。
hexo的核心思想：让你只需要写简简单单的markdown，就可以获得“你想要的HTML页面（效果）”，让你玩的开心。

yansheng836 on 24 Aug 2019

This issue has been automatically marked as stale because lack of recent activity. It will be closed if no further activity occurs. Thank you for your contributions.