用 git 管理 Hexo 博客源码，最常见的问题不是提交失败，而是多人协作或跨设备编辑时出现冲突，进而覆盖掉已经写好的文章。冲突本身不可怕，真正让人头疼的是在合并时选错版本，把辛辛苦苦写的草稿冲掉。下面从实际操作角度梳理几个避免冲突覆盖的关键点。
先明确仓库里的跟踪内容
Hexo 项目里既有源码，也有生成后的静态页面。用 git 管理时，建议只把源码纳入版本控制，public 目录和.deploy_git 目录加入 .gitignore。这样每次提交的是 Markdown 文章、主题配置、scaffold 等内容，不会因为多人同时执行生成命令而产生大量无关差异，降低冲突概率。
另外，注意 _config.yml 这类全局配置文件会被所有人使用。如果各自机器上环境路径或插件版本不同，不要频繁把本地环境相关的修改推送上去，以免合并时在配置层面出现无意义冲突，最终误伤文章源码。
按栏目拆分支，文章写完再合并
如果只有一个人写博客，直接在 master 分支上提交问题不大。但如果是多人共同维护，或者你经常在不同电脑间切换，建议按栏目或功能拆分支。比如写 Docker 笔记时新建一个分支，写完文章、检查无误后再合并到主分支。合并时用 git merge –no-ff 保留合并记录，发生冲突时也能知道是哪次合并产生的，便于回退。
更稳妥的做法是每个文章单独一个分支，文章合并后立即删除分支。这样能让每次变更范围很小，合并时 git 更容易自动合并，几乎不会出现覆盖整篇文章的情况。
pull 之前先看状态，避免本地改动被覆盖
很多冲突发生在拉取远端代码时，本地修改还没提交，git 直接要求你先 commit 或 stash。如果直接使用 git checkout . 或者 git reset –hard 强制拉取，本地未提交的文章就会被覆盖。正确流程是养成先 git status 的习惯，确认当前有未提交的修改后，优先执行 git stash 暂存，再 pull，然后 git stash pop 恢复自己的改动。
在恢复暂存内容时，如果 git 提示冲突，说明远端改动与你本地修改的是同一个文件。此时需要手动打开 Markdown 文件，检查冲突标记，保留自己的文章内容，再 git add 和 commit。千万不要在此时执行 git checkout — 文件名，那样会直接丢弃本地版本，相当于用远端覆盖了刚写完的文章。
用子模块或脚本规避 Hexo 特有的覆盖场景
Hexo 部署时一般会用 hexo clean 清理 public 目录，再执行 hexo generate。如果某些操作脚本在部署前自动执行 git pull，且与本地未提交的源码混在一起，极容易触发覆盖。建议把 hexo clean、generate、deploy 这类命令拆成单独步骤，不要写成一键脚本时直接连同拉取操作一起执行。
如果博客源码存放在两个设备上，比如公司电脑和家里电脑，经常忘记推拉，可以在写文章前先 git pull，写完立即 commit 和 push。关键在于保持本地仓库干净，不要让未提交的更改长期滞留。对于主题文件或改动的公共模板，也可以考虑用 git submodule 管理，这样主题升级时不会因为主仓库的冲突而波及文章目录。
总之，避免 git 管理 Hexo 时覆盖文章的要点是：忽略生成目录、控制合并频率、先暂存再拉取、勇敢面对冲突标记。只要不轻易使用强制重置命令，每次操作前看一眼仓库状态，文章源码就不会被意外覆盖。