写博客这件事真正劝退我的不是“没东西写”而是“怕折腾出问题”。怕电脑一坏写了半年的文章全部蒸发怕改主题改到一半想回到昨天还能用的状态却回不去怕换了新电脑想把博客源码完整搬下来却不知道从哪下手。这篇是这个系列的第三篇就来专门解决这个核心痛点用 Git 管理博客源码再放到码云Gitee上做代码托管。也就是说从这一篇开始你的博客不再是一堆散落在硬盘角落里的文件夹而是一套有版本、有备份、有完整操作历史的工程。不管你是刚搭好 Hexo、Hugo 还是 VuePress接下来的内容都能直接用上我尽量把每一步背后为什么这么做也讲清楚让你不是照抄命令而是真正能独立玩转这套流程。1. 为什么个人博客也离不开代码托管1.1 博客自建流程里代码托管到底解决什么问题很多人觉得我自己写博客又不是团队协作有必要上 Git 吗这个想法我太理解了因为当初我也是这么想的。但等真正把博客源码交给 Git 之后我才发现它解决的不是“协作”问题而是三个更基础、更日常的问题——备份、回滚、多设备同步。先说备份。博客源码本质上就是一堆文本文件Markdown 文章、主题配置文件、脚本、图片。你当然可以每个月手动打包压缩一次扔到网盘里但问题是你会忘了定期做而且网盘上只有某一个时间点的快照中间那几天的改动丢了就是丢了。Git 不一样你每一次提交都是一次完整的历史记录它记录的是“过程”不是“结果”。哪怕你三个月没推送本地的提交历史也都在哪怕你把一个文件改得面目全非只要有一次提交还在就能拿回来。再说回滚。这个场景做博客的人迟早会遇到——主题更新后布局乱了插件装完网站直接白屏配置改错一个参数导致整个站点构建失败。没有版本管理的时候你只能靠备份文件或者凭记忆改回去心态很容易崩。有了 Git一条命令就能把整个项目恢复到任意一个历史状态这种“随时可以反悔”的安全感是个人博客能长期折腾下去的重要心理保障。最后是多设备同步。现在很多人不止一台电脑单位一台、家里一台有时还有笔记本。没有代码托管之前你要么用 U 盘拷来拷去要么手动比对哪个文件更新效率极低。把仓库推到云端之后换设备只需要 clone 一次之后在任意一台上写完文章push 一下另一台 pull 一下状态就对齐了。这也是“代码托管”里“托管”这两个字真正的价值——它把你的代码安全地放在一个随时可以取回的地方不需要你自己维护服务器也不用担心硬盘损坏。1.2 为什么选了 Git 码云这套组合选代码托管方案的时候很多人第一反应是 GitHub。GitHub 确实大但如果你人在国内、网络环境又不太稳定直连 GitHub 的速度和稳定性经常让人抓狂。相比之下码云Gitee是国内的老牌代码托管平台有两件事特别适合博客自建场景第一服务器在国内仓库操作速度明显更快push、pull、clone 都顺畅很多第二它提供了类似 GitHub Pages 的 Gitee Pages 服务可以把博客源码直接部署成一个静态网站这跟我们的博客自建路线是天然契合的。为什么是 Git 而不是 SVN 或者其他版本控制工具先说结论现在你几乎找不到一个现代代码托管平台不支持 GitGit 已经成为事实标准。更重要的是Git 是分布式的每个人的本地都有一份完整的历史仓库不用联网也能看历史、能提交、能回滚这对于个人开发者来说是极大的自由度。SVN 的集中式模式依赖中央服务器断网基本就废了而且分支操作笨重体验完全不一样。初学者不用纠结直接学 Git 就好它在博客、写代码、甚至写文档的场景里都是通用技能。有人可能会问那用 Dropbox、坚果云这类网盘同步文件夹不是也能备份吗能用但跟 Git 是两回事。网盘同步的是文件内容它不关心版本之间的逻辑关系你没法精确地给某个版本打标签也没法把某一次改动单独提取出来。更重要的是网盘容易出现同步冲突特别是两台电脑同时改同一个文件的时候最后可能生成一堆“冲突副本”。Git 的冲突处理机制虽然初期有学习成本但它是结构化的、可控的不会让你的仓库变得乱七八糟。2. 先从零装好 GitWindows 环境配置全流程2.1 Git 安装包来源与安装时的关键选项在 Windows 上装 Git最标准的做法是安装 Git for Windows 这个发行版。官网是 git-scm.com点 Download 就能拿到安装包。如果官网下载速度慢可以用清华大学的开源软件镜像站或者阿里云的镜像站搜“Git Windows 下载”都能找到对应路径下载速度会快很多。安装包是 exe 格式双击后一路 Next 其实也能装完但有几个关键选项我建议你不要一路盲点尤其是 PATH 环境变量、行尾转换和默认编辑器这三项。先说 PATH 环境变量。安装过程中你会看到 “Adjusting your PATH environment” 这一步里面有三个选项第一项是只在 Git Bash 里用 Git第二项是“Git from the command line and also from 3rd-party software”第三项是“Use Git and optional Unix tools from Command Prompt”。请务必选第二项。选第二项之后你以后在 CMD、PowerShell 或者任何 IDE 的终端里都能直接敲git命令IDE 也更容易自动识别到 Git 的安装位置。如果你选了第一项后面在 VSCode 或者 IDEA 里经常会遇到“找不到 Git”的报错还要手动去配置路径完全没有必要。第二个关键选项是行尾转换。Windows 用的是 CRLF 换行Linux 和 macOS 用的是 LF 换行如果处理不好你会遇到一种很崩溃的情况明明只改了一行代码git diff却显示整个文件全部变了。安装向导里的 “Line Ending Conversions” 建议选第一项 “Checkout Windows-style, commit Unix-style line endings”意思是文件从仓库拉出来时转成 Windows 的 CRLF提交回仓库时转成 LF。这样能最大程度避免换行符问题。第三个选项是默认编辑器新版本会让你选 Git 默认使用的文本编辑器默认是 Vim但对很多人来说 Vim 不太友好第一次git commit时可能卡在里面不知道怎么退出。如果你装了 VSCode这里直接选 VSCode 会比较省心如果你不确定保持默认也行后面可以用命令改。2.2 安装后的环境检查和基础配置装完之后你先别急着建仓库先验证一下 Git 是否真的进到了 PATH 里。打开任意一个终端CMD 或 PowerShell 都行输入git --version如果能看到一串类似git version 2.40.0的输出说明安装成功。如果提示“不是内部或外部命令”大概率是刚才 PATH 那一步选错了有两个解决办法重装一次 Git 选第二项或者手动把C:\Program Files\Git\cmd加入到系统环境变量 Path 里。这个手动操作路径是右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 找到 Path → 编辑 → 新增一行填 Git 的 cmd 目录。接下来是最重要的全局配置告诉 Git 你是谁。因为每次提交代码时Git 都会记录提交人的名字和邮箱如果没配置第一次提交会直接报错或者弹提示。打开终端执行这两行命令git config --global user.name 你的昵称 git config --global user.email 你的邮箱注意这里的邮箱可以不是真实邮箱但建议用一个你常收信的邮箱因为以后在一些协作场景里别人可能通过提交邮箱联系你。配置完成后可以用git config --list查看当前所有生效的配置。这里顺便说一个 Git 的配置优先级Git 的配置分三个层级依次是 system、global、local。system 是整台机器生效global 是当前用户生效local 是当前仓库生效。优先级是 local global system也就是说如果你在某个仓库里单独配置了一个不同的用户名它会覆盖全局用户名。这个特性在以后给不同项目设置不同身份时很实用。除了命令行还有一个 Windows 上很流行的图形化工具叫 TortoiseGit也就是很多人说的“小乌龟”它会在文件夹右键菜单里直接显示 Git 的各种操作适合不习惯命令行的人。我的建议是新手可以装它作为辅助但核心命令还是建议学一下因为你在网上搜到的绝大多数教程、报错解决方案都是基于命令行的纯依赖图形界面会限制你排查问题的能力。3. 码云实战第一步仓库创建与 SSH 密钥配置3.1 注册账号并新建第一个远程仓库本地 Git 装好之后我们需要一个远程仓库来承接代码托管这里我用码云来演示。打开 Gitee 官网用手机号注册一个账号。注册过程中会要求手机验证部分功能可能还会引导你完成实名认证建议按流程走完否则后续某些操作可能会受限这也是平台账号安全机制的一部分不是多此一举。登录之后在页面右上角找到“新建仓库”的按钮点进去会看到仓库创建表单。有几个字段要重点说一下。第一个是“仓库名称”它相当于给这个项目起的名字我用my-blog这类名字简单好记就行后面生成的项目路径会自动带上你的用户名。第二个是“仓库介绍”可填可不填但建议填上比如“我的个人博客源码”这样以后公开分享时别人一眼能看明白。第三个很关键“是否初始化仓库”。如果你本地已经有了博客源码这里建议把 “初始化仓库” 下面的几个选项比如自动创建 README、.gitignore、开源许可证全部取消勾选让码云生成一个真正意义上的空仓库。为什么要这样因为如果你本地仓库和远程仓库各自都有一次不相关的初始提交第一次推送时会出现“分叉历史”需要额外处理合并对新手来说是额外的坑。空仓库最干净直接推上去就行。还有一个“开源许可证”选项很多人不知道选什么。简单说如果你的博客源码不打算让别人随便复制使用可以不选如果你希望公开源码并允许别人在保留署名的情况下使用可以选 MIT 这种宽松许可证。个人博客一般不用纠结不选就好。仓库的私有和公开选项码云的私有仓库是免费的如果你不想让别人看到你的源码和文章草稿选私有如果以后想把这套源码作为作品展示给别人看就选公开。这个随时能改不用太纠结。3.2 SSH 密钥让你免密推送的关键远程仓库建好之后接下来要打通本地和码云之间的传输通道。这里我强烈建议用 SSH 方式而不是 HTTPS 方式。HTTPS 方式每次git push都可能让你输入账号密码而且码云对 HTTPS 的密码输入有各种验证要求体验很繁琐。SSH 方式本质上是用一对密钥做身份认证私钥留在本地公钥是公开的、可以上传到码云推送代码时 Git 会自动完成加密验证不需要输密码也安全得多。生成密钥的方法很简单。打开终端Git Bash 最好执行ssh-keygen -t rsa -b 4096 -C 你的邮箱如果你的系统支持 Ed25519 算法也可以把-t rsa -b 4096换成-t ed25519更现代、密钥更短。敲完命令后会问你保存路径直接回车用默认的~/.ssh/id_rsa就行然后又问你是否设置密码短语passphrase这里可以直接回车跳过如果你设置了每次使用密钥时都要输一遍密码个人开发环境没什么必要。执行完后在你的用户目录下的.ssh文件夹里会生成两个文件id_rsa是私钥永远不要给任何人、不要上传到任何网站id_rsa.pub是公钥就是接下来要交给码云的。怎么把公钥复制到码云Windows 下你可以直接用记事本打开C:\Users\你的用户名\.ssh\id_rsa.pub这个文件内容是一长串文本大概率以ssh-rsa开头以你的邮箱结尾。全选复制然后打开码云官网进入“个人设置” → “SSH 公钥”把内容粘贴进去填一个容易记得的公钥标题比如“我的主力电脑”保存即可。保存成功后回到终端测试一下连接ssh -T gitgitee.com首次连接时终端会提示确认主机指纹输入yes回车。如果看到类似 “Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.” 的提示就说明 SSH 配置成功了。这里有个小坑有些人复制公钥的时候会漏掉结尾的邮箱或者不小心多复制了一个空格会导致验证失败。如果测试报错先检查公钥内容是否完整、是否有多余空白字符这是一半以上新手会遇到的问题。4. 把本地博客源码推送到码云常用 Git 命令实战4.1 初始化本地仓库并关联远程仓库SSH 配置好之后就可以正式把本地博客源码变成 Git 仓库了。假设你的博客项目在D:\my-blog目录下打开终端切换到该目录。如果你用的是 Git Bash可以用cd /d/my-blog这样的方式如果你用 CMD 或 PowerShell直接cd D:\my-blog就行。然后执行git init这条命令会在当前目录下创建一个隐藏的.git文件夹这个文件夹就是 Git 的本地仓库数据库你的所有版本历史都存放在里面。执行完之后你还可以看到当前分支名的变化新版本 Git 默认可能会叫master或main具体取决于版本后面我们可以统一。接下来把远程仓库的地址关联到本地。回到码云的仓库页面复制 SSH 地址注意选 SSH 而不是 HTTPS。然后执行git remote add origin gitgitee.com:你的用户名/my-blog.git这里的origin是远程仓库的默认别名相当于给这个远程地址起了一个简短的名字以后推送、拉取时直接说origin就行不用再打一长串地址。执行完后用git remote -v确认一下能看到 fetch 和 push 两个 url 都指向码云仓库这就说明关联成功了。还有一种情况是你想先在码云建一个空仓库然后把它克隆下来如果你打算这么做就不需要git remote add了直接git clone gitgitee.com:你的用户名/my-blog.git它会自动帮你把远程关联好你只需要把源码文件复制进去就行。4.2 第一次提交与推送从 add 到 push仓库初始化好之后把博客源码加入 Git 管理核心操作是三个命令git add、git commit、git push。我逐个解释一下因为很多新手就是在这里迷路的。git add .的作用是把所有尚未跟踪的、或者有改动的文件加入暂存区。注意这里有个重要前提在第一次 add 之前最好先创建好.gitignore文件把不需要管理的目录和文件排除掉否则你可能会把node_modules这类庞大的依赖目录一股脑提交上去。关于.gitignore的具体内容我后面会单独讲这里先简要说一下像依赖目录、构建产物目录、日志文件这类不该进仓库的东西提前写进忽略规则。执行完 add 之后用git status看一下当前状态。你会看到一堆绿色文字的文件列表说明这些文件已经被 Git 纳入本次暂存。然后执行提交git commit -m first commit: 初始化博客源码-m参数后面跟的是本次提交的说明文字这个说明要简短清晰地描述本次改动方便以后回看历史。提交完之后本地仓库就有一条记录了。这里有个常见疑惑commit 是在本地完成的跟远程还没关系所以现在就算断网也不影响。接下来是把本地提交推到码云。第一次推送时需要把本地分支和远程分支关联起来我用这条命令git branch -M main git push -u origin main第一行git branch -M main是把当前分支重命名为main。如果你的 Git 默认分支已经是main这行可以跳过如果本地是master码云默认分支是main建议统一一下否则后面容易混乱。第二行里的-u参数非常关键它会把本地分支和远程分支的跟踪关系记录下来执行完这次之后以后直接敲git push就能推送不用再带origin main了。第一次推送完成后去码云仓库页面刷新一下看到源码文件出现在里面就说明你的博客源码正式完成了代码托管。4.3 日常更新博客的推送套路仓库跑起来之后日常维护其实只有固定的几步。比如你写完一篇新文章路径是source/_posts/my-new-post.md那么操作就是git add source/_posts/my-new-post.md然后git commit -m docs: 新增文章《xxx》最后git push。如果你改的是主题配置比如调整了导航栏那就git add _config.yml提交信息写成style: 调整导航栏样式。这套操作的核心思路是每次只提交跟本次改动相关的文件提交信息写清楚“做了什么”而不是笼统地git add .加一句“更新”。很多新手会把git add .当成万能操作随手就 add everything然后 commit 一句“修改”。这样不是不行但会带来两个问题一是以后回看历史时很难定位某次具体改动二是很容易把不想提交的文件比如编辑器临时文件、包含密钥的配置文件一起提交上去。我的建议是日常用git add 具体文件名或者git add 具体目录提交信息尽量用“类型: 描述”这种格式比如docs:、fix:、style:、refactor:。这个习惯在团队协作中是硬要求在个人项目里虽然没人要求你但养成了之后三个月后回看自己的提交历史会非常清晰。换新电脑或者从别的地方继续写博客时流程是先git clone gitgitee.com:你的用户名/my-blog.git把仓库完整拉到本地然后在新的电脑上正常编辑。如果离开了几天、码云上的仓库被别人或其他电脑更新过本地再次开始写之前先执行git pull把远程最新的改动拉下来。这里有一个必须注意的坑git pull之前先看看本地有没有未提交的改动如果有可以先git commit提交一次或者git stash暂存起来否则容易出现冲突提示。个人博客一般只有一台主力机在写冲突概率不高但养成习惯总没错。4.4 提交信息写错了怎么办git commit --amend写提交信息这件事谁都难免手误。比如 commit 完之后发现说明文字打错字了或者忘了把某个文件加进去这时候很多人第一反应是慌其实 Git 提供了非常贴心的补救命令git commit --amend。这个命令的作用是“修改最近一次提交”。如果你只是想把提交信息改一下直接执行git commit --amend -m 正确的新提交信息如果你是想把漏掉的文件补进这次提交里那就先git add 漏掉的文件然后执行git commit --amend不带-m也行Git 会打开编辑器让你修改提交信息保存退出后最近一次提交就包含了新增的文件和新的说明文字。这个操作不会新增提交历史而是把原来的提交“替换”成一个新的提交。不过有个注意事项amend会改写 Git 历史所以如果这次提交已经推送到远程了就不要随便用amend否则下一次git push会因为本地和远程历史不一致而报错需要强制推送才能解决这在多人协作里是很危险的操作。个人博客自己一个人玩影响不大但我还是建议你养成习惯提交还没推送之前随便 amend推送过之后想改就新建一个提交不要改写历史。还有一个常用补救场景是git reset系列比如你想撤销最近一次提交但保留文件改动可以用git reset --soft HEAD~1这个命令能让你回到提交前、文件还在暂存区的状态再重新组织提交内容。5. 博客部署里的 Git 进阶忽略规则、标签与查看历史5.1 .gitignore这些文件千万别提交前面几次提到.gitignore这一节专门说透。.gitignore是放在仓库根目录下的一个文本文件里面写的是 Git 应该忽略的文件和目录规则。为什么博客项目特别需要它因为大部分静态博客框架会在本地生成依赖目录和构建产物这些目录动辄几百 MB、几万个文件如果提交进仓库会让仓库体积变得巨大、clone 变慢而且完全没有意义——因为它们可以根据源码重新生成。不同博客框架的忽略规则略有差异但有一个通用基础模板。以 Hexo 为例你的.gitignore至少应该包含这些内容node_modules/ public/ .deploy_git/ db.json *.log .DS_Store .env解释一下node_modules/是 npm 安装的依赖需要忽略public/是 Hexo 生成的静态站点文件属于构建产物不需要进仓库.deploy_git/是 Hexo 部署时生成的临时 Git 目录一定要忽略db.json是 Hexo 的数据库缓存文件*.log匹配所有日志文件.DS_Store是 macOS 的文件夹元数据文件.env是环境变量文件里面很可能有敏感信息必须忽略。如果你用的不是 Hexo思路是一样的去框架文档里查一下“gitignore 推荐配置”把依赖目录、构建目录、缓存文件排除掉就行。还有一个更关键但容易被忽视的提醒千万不要把密钥文件提交进仓库。比如刚才生成的id_rsa私钥、各种 API Token、服务器密码、数据库连接字符串这些都绝对不能出现在仓库里。很多账号安全事件、云主机被入侵追根溯源都是因为有人在代码仓库里提交了.env文件或者密钥文件。万一你已经误提交了除了删除文件再提交一次之外还要意识到历史记录里可能仍然有这份密钥的痕迹最保险的做法是立刻去对应平台把密钥作废、重新生成然后清理仓库历史。新手的简单做法是把远程仓库删除重新建一个空仓库再推一遍。虽然粗暴但比留着隐患强。5.2 用 Git 标签给版本留个记号代码托管还有一个被个人开发者低估的功能标签tag。标签相当于给某个提交打上一个固定的、有意义的标记你可以把它理解成给版本历史贴便利贴。博客项目里什么场景适合用标签比如你完成了博客主题的一次大改版整个站点视觉风格焕然一新或者你把博客框架从旧版本升级到了新版本这种里程碑式的节点打一个标签非常合适。操作很简单git tag -a v1.0 -m 主题改版完成整体焕新-a表示创建一个附注标签-m是标签说明。执行完git tag可以列出所有标签能看到你刚才创建的v1.0。标签默认只在本地要推送到码云需要单独执行git push origin v1.0以后如果博客出了问题想看看 v1.0 这个版本到底长什么样可以用git checkout v1.0临时切到这个版本查看或者根据标签定位 commit再用git diff v1.0对比当前版本和 v1.0 的差异。标签有个非常好的特性它指向的是一个不可变的提交快照不会因为你之后继续提交而改变。也就是说标签就像是给“某个时刻的博客”拍了一张永久照片任何时候想回头都找得到。这个功能对个人项目来说比想象中有用得多。5.3 高效查看历史log、diff 和 status 的用法日常使用 Git 时git log、git diff、git status这三个命令你会反复用到我建议第一次接触 Git 就把它们刻在脑子里。git status是每次操作之前必看的命令它告诉你当前仓库处于什么状态哪些文件有改动、哪些文件已暂存、当前在哪个分支、和远程分支有没有同步偏差。遇到任何 Git 异常第一步永远是执行git status看现场而不是瞎猜。git log用来查看提交历史。简版用法git log --oneline会以一行的形式显示每条提交的哈希值和说明文字一眼扫过去就能看清项目演进脉络加上--graph参数还能看到分支合并的图形化展示。很多开源项目维护者喜欢用git log --oneline --graph --decorate组合这个组合值得你直接记住。git diff用来查看“改动的内容”。不带参数时它显示的是工作区和暂存区之间的差异也就是你改了但还没 add 的内容带--staged参数时显示的是暂存区和上一次提交之间的差异也就是你已经 add 但还没 commit 的内容。对博客写作场景来说git diff最实用的场景是改完主题配置后忘了自己改了哪些参数执行一下git diff所有改动一目了然这会比你在文件里反复找高效得多。为了方便日常使用我把博客维护中最常用的 Git 命令整理成一个速查表操作场景常用命令说明查看状态git status查看工作区、暂存区、分支状态查看改动git diff查看未暂存的改动内容查看历史git log --oneline以简洁格式查看提交历史暂存改动git add 文件名把指定文件加入暂存区提交git commit -m 说明把暂存区内容提交为一条记录推送git push把本地提交推送到远程拉取git pull把远程新提交拉取到本地打标签git tag -a 标签 -m 说明给当前提交打附注标签修改最近提交git commit --amend修改最近一次提交查看远程git remote -v查看远程仓库地址6. 常见问题与排查技巧实录6.1 fatal: not a git repository 到底怎么回事这个报错可能是新手遇到最多的一个。完整信息是fatal: not a git repository (or any of the parent directories): .git。看到这句话的时候先别慌它说明的是你当前所在的目录不是一个 Git 仓库而且它的上级目录也没有 Git 仓库。最常见的原因是终端当前位置不对。比如你在D:\根目录下执行git status这里没有.git文件夹所以 Git 就会这样报错。解决方法很简单先cd到你的博客项目目录再执行 Git 命令。如果你确认已经在项目目录里了但还是报这个错那就要检查项目目录下有没有.git文件夹了。Windows 下默认隐藏点开头的文件夹你可能看不到可以通过文件资源管理器的“查看 → 勾选隐藏的项目”看或者在终端里执行ls -a查看。如果.git文件夹确实不存在说明这个目录还没有被初始化过需要先执行git init初始化。还有一种少见但确实会发生的情况.git文件夹被人误删了那本地历史就没了只能重新git init再从远程 clone 或者重新关联远程地址。6.2 克隆远程仓库太慢或失败怎么办网络问题永远是国内开发者绕不开的话题尤其是从境外平台克隆仓库时速度忽快忽慢、甚至直接失败都有可能。如果你是从 GitHub 这类海外平台拉取博客主题或者代码一个非常实用的技巧是利用码云的“仓库导入”功能。码云支持从 GitHub、GitLab 等平台导入仓库你只需要在码云上选择“从 GitHub 导入仓库”填上原仓库地址码云服务器会先把代码拉取到自己这边然后你再从码云 clone 到本地。这样两个环节都是在国内网络环境内完成速度会稳定很多等于让码云帮你做了个中转和缓存。如果你是从码云本身的仓库克隆也慢那就要从自己这边找原因了。首先检查一下是不是有别的程序占用了大量带宽比如正在下载大文件、视频应用在后台跑着其次关掉系统代理之类的设置有时代理配置反而会让国内直连变慢。还有一个低级但常见的错误克隆时选错了地址。码云仓库页默认展示的可能是一个超级长的 HTTPS 地址你复制到一半或者手打导致漏字符就会克隆失败。一定要用仓库页右上角“克隆/下载”按钮旁边的复制图标一键复制完整地址避免手输。如果实在急着拿到代码仓库页也提供直接下载 ZIP 压缩包的选项但这样拿到的只是文件快照、没有 Git 历史只适合临时应急。6.3 码云账号被限制或仓库被屏蔽的常见原因与应对这个话题在热搜词里出现过说明不少人踩过坑。码云账号被限制访问、仓库被屏蔽原因其实大同小异绝大多数是仓库内容或者账号行为违反了平台规范。最常见的情况包括仓库里存放了违规资源、恶意脚本、涉及侵权的内容或者账号存在批量注册、恶意操作等异常行为。还有一种很多人忽略的情况仓库里意外提交了包含敏感信息的文件比如数据库密码、私钥、身份证号这类内容一旦被平台检测到也可能触发安全限制。如果不幸遇到账号或仓库被限制我的建议是分三步走。第一步先自查登录码云把所有公开的仓库挨个检查一遍重点看 README、资源文件、项目内容里有没有违规或敏感的东西一旦发现有问题的仓库立刻删除或者改为私有。第二步检查账号的实名认证状态码云要求用户完成手机验证、实名信息填报后才能使用全部分类功能如果你之前没走完认证流程某些限制其实只是功能未解锁不是被封禁。第三步如果确实没有违规、但账号仍然被限制那就通过码云的官方申诉渠道提交工单说明你的账号使用场景、被限制的时间点、已经完成的自查情况等待平台人工审核。这里要特别提醒不要在网上到处发帖骂平台或者问“为什么被封”那解决不了问题老老实实走官方渠道才是最快的。6.4 IDEA 或其他 IDE 里提交代码报错怎么办很多博客作者会用 VSCode、IDEA 这类编辑器来写文章和提交代码IDE 里集成 Git 确实方便但也经常出一些专属问题。最常见的报错是 “Cant run Git” 或者 “git not found”这种基本上就是 IDE 没有找到 Git 的安装路径。VSCode 的思路是打开设置搜索git.path把你本机git.exe的完整路径填进去比如C:\Program Files\Git\cmd\git.exe。IDEA 的路径是File → Settings → Version Control → Git → Path to Git executable选择同样路径然后点 Test 测试。一般测试通过就能正常使用。另一个常见问题是 IDE 提示登录失败、token 失效之类的典型提示类似 “login failed. check api token or gitlab version” 或者 “Authentication failed”。这种问题通常跟 SSH 配置没生效有关或者 IDE 里保存的账号密码已经过期。你可以在终端里先执行ssh -T gitgitee.com确认 SSH 免密是正常的如果终端能通过、但 IDE 报错那问题多半出在 IDE 的身份认证配置上——让 IDE 使用 SSH 而不是 HTTPS 方式拉取远程地址或者在 IDE 的凭据管理里删掉之前保存的旧登录信息重新触发认证。总之遇到 IDE 相关 Git 问题通用排查顺序是先在命令行验证 Git 本身没问题再检查 IDE 配置最后检查远程仓库地址是否正确一层层缩小范围不要一上来就断言是 IDE 坏了。6.5 其他我踩过的坑大小写、换行符和误提交密码最后分享几个我实际踩过的坑这些坑不在官方文档里被重点强调但撞上的人真的不少。第一个是文件名大小写问题。Git 在 Windows 和 macOS 上默认不区分文件名大小写如果你把一个文件名从About.md改成about.md直接提交可能不会生效Git 认为文件没变化。解决办法不是用文件管理器改名而是在终端里用git mv About.md about.md来移动/改名这样 Git 才能正确识别到变化。如果已经踩了坑文件在仓库里显示旧名字、磁盘上已经是新名字可以用git add -A后检查 status 再提交有时也能救回来但还是建议提前用git mv避免混乱。第二个是换行符问题。前面安装时我强调过选行尾转换但有些人是装完才发现问题的表现就是随便改一个文件git diff显示成千上万行都变了。如果不幸发生了可以写一个.gitattributes文件放在仓库根目录在里面声明* textauto或者针对特定目录指定换行符规则强制让 Git 统一处理。.gitattributes一旦提交并推送能让所有克隆这个仓库的人都用同一套换行符规则是从根本上解决换行符混乱的方案。不过这个文件里的语法规则比较多新手可以先用最基础的* textauto配合安装时的行尾选择后面遇到具体文件类型再慢慢补充规则。第三个是误提交敏感信息。比如我把一个测试用的服务器密码写进配置文件稀里糊涂就git push到了公开仓库。发现之后光在最新版本里删掉是没用的因为 Git 历史里还留着。对新手来说最省事的处理方式是马上登录码云把相关凭据在业务侧先作废掉如果仓库是公开的立即改成私有然后考虑清理历史。清理历史可以借助git filter-branch或者工具 BFG Repo-Cleaner但这些命令有难度、也有风险容易把仓库搞乱所以我给新手的建议是如果这个仓库刚建没几天、历史不多直接删除远程仓库重新建一个然后重新推送更干脆。这不是最优雅的方案但在个人项目里快速止损比追求优雅重要得多。这个系列走到代码托管这一步我自己最深的体会是把博客源码交给 Git 之后折腾起来心态完全不一样了。以前改一个配置要小心翼翼担心改坏了就完蛋现在随便改改完看效果不满意就回滚甚至拿分支当一个“草稿区”来实验各种想法好用就保留不好用就丢弃。最后再分享一个小习惯每次发布一篇文章提交信息都用统一的格式比如docs: 新增《个人博客自建指南三》一个月后回看提交记录所有文章的历史脉络清清楚楚。写博客这件事长期坚持靠的是流程顺手而 Git 这样的工具一旦用顺了你就再也回不去没有它的日子了。 用Git+码云托管博客源码：从零实现备份、回滚与多设备同步
写博客这件事真正劝退我的不是“没东西写”而是“怕折腾出问题”。怕电脑一坏写了半年的文章全部蒸发怕改主题改到一半想回到昨天还能用的状态却回不去怕换了新电脑想把博客源码完整搬下来却不知道从哪下手。这篇是这个系列的第三篇就来专门解决这个核心痛点用 Git 管理博客源码再放到码云Gitee上做代码托管。也就是说从这一篇开始你的博客不再是一堆散落在硬盘角落里的文件夹而是一套有版本、有备份、有完整操作历史的工程。不管你是刚搭好 Hexo、Hugo 还是 VuePress接下来的内容都能直接用上我尽量把每一步背后为什么这么做也讲清楚让你不是照抄命令而是真正能独立玩转这套流程。1. 为什么个人博客也离不开代码托管1.1 博客自建流程里代码托管到底解决什么问题很多人觉得我自己写博客又不是团队协作有必要上 Git 吗这个想法我太理解了因为当初我也是这么想的。但等真正把博客源码交给 Git 之后我才发现它解决的不是“协作”问题而是三个更基础、更日常的问题——备份、回滚、多设备同步。先说备份。博客源码本质上就是一堆文本文件Markdown 文章、主题配置文件、脚本、图片。你当然可以每个月手动打包压缩一次扔到网盘里但问题是你会忘了定期做而且网盘上只有某一个时间点的快照中间那几天的改动丢了就是丢了。Git 不一样你每一次提交都是一次完整的历史记录它记录的是“过程”不是“结果”。哪怕你三个月没推送本地的提交历史也都在哪怕你把一个文件改得面目全非只要有一次提交还在就能拿回来。再说回滚。这个场景做博客的人迟早会遇到——主题更新后布局乱了插件装完网站直接白屏配置改错一个参数导致整个站点构建失败。没有版本管理的时候你只能靠备份文件或者凭记忆改回去心态很容易崩。有了 Git一条命令就能把整个项目恢复到任意一个历史状态这种“随时可以反悔”的安全感是个人博客能长期折腾下去的重要心理保障。最后是多设备同步。现在很多人不止一台电脑单位一台、家里一台有时还有笔记本。没有代码托管之前你要么用 U 盘拷来拷去要么手动比对哪个文件更新效率极低。把仓库推到云端之后换设备只需要 clone 一次之后在任意一台上写完文章push 一下另一台 pull 一下状态就对齐了。这也是“代码托管”里“托管”这两个字真正的价值——它把你的代码安全地放在一个随时可以取回的地方不需要你自己维护服务器也不用担心硬盘损坏。1.2 为什么选了 Git 码云这套组合选代码托管方案的时候很多人第一反应是 GitHub。GitHub 确实大但如果你人在国内、网络环境又不太稳定直连 GitHub 的速度和稳定性经常让人抓狂。相比之下码云Gitee是国内的老牌代码托管平台有两件事特别适合博客自建场景第一服务器在国内仓库操作速度明显更快push、pull、clone 都顺畅很多第二它提供了类似 GitHub Pages 的 Gitee Pages 服务可以把博客源码直接部署成一个静态网站这跟我们的博客自建路线是天然契合的。为什么是 Git 而不是 SVN 或者其他版本控制工具先说结论现在你几乎找不到一个现代代码托管平台不支持 GitGit 已经成为事实标准。更重要的是Git 是分布式的每个人的本地都有一份完整的历史仓库不用联网也能看历史、能提交、能回滚这对于个人开发者来说是极大的自由度。SVN 的集中式模式依赖中央服务器断网基本就废了而且分支操作笨重体验完全不一样。初学者不用纠结直接学 Git 就好它在博客、写代码、甚至写文档的场景里都是通用技能。有人可能会问那用 Dropbox、坚果云这类网盘同步文件夹不是也能备份吗能用但跟 Git 是两回事。网盘同步的是文件内容它不关心版本之间的逻辑关系你没法精确地给某个版本打标签也没法把某一次改动单独提取出来。更重要的是网盘容易出现同步冲突特别是两台电脑同时改同一个文件的时候最后可能生成一堆“冲突副本”。Git 的冲突处理机制虽然初期有学习成本但它是结构化的、可控的不会让你的仓库变得乱七八糟。2. 先从零装好 GitWindows 环境配置全流程2.1 Git 安装包来源与安装时的关键选项在 Windows 上装 Git最标准的做法是安装 Git for Windows 这个发行版。官网是 git-scm.com点 Download 就能拿到安装包。如果官网下载速度慢可以用清华大学的开源软件镜像站或者阿里云的镜像站搜“Git Windows 下载”都能找到对应路径下载速度会快很多。安装包是 exe 格式双击后一路 Next 其实也能装完但有几个关键选项我建议你不要一路盲点尤其是 PATH 环境变量、行尾转换和默认编辑器这三项。先说 PATH 环境变量。安装过程中你会看到 “Adjusting your PATH environment” 这一步里面有三个选项第一项是只在 Git Bash 里用 Git第二项是“Git from the command line and also from 3rd-party software”第三项是“Use Git and optional Unix tools from Command Prompt”。请务必选第二项。选第二项之后你以后在 CMD、PowerShell 或者任何 IDE 的终端里都能直接敲git命令IDE 也更容易自动识别到 Git 的安装位置。如果你选了第一项后面在 VSCode 或者 IDEA 里经常会遇到“找不到 Git”的报错还要手动去配置路径完全没有必要。第二个关键选项是行尾转换。Windows 用的是 CRLF 换行Linux 和 macOS 用的是 LF 换行如果处理不好你会遇到一种很崩溃的情况明明只改了一行代码git diff却显示整个文件全部变了。安装向导里的 “Line Ending Conversions” 建议选第一项 “Checkout Windows-style, commit Unix-style line endings”意思是文件从仓库拉出来时转成 Windows 的 CRLF提交回仓库时转成 LF。这样能最大程度避免换行符问题。第三个选项是默认编辑器新版本会让你选 Git 默认使用的文本编辑器默认是 Vim但对很多人来说 Vim 不太友好第一次git commit时可能卡在里面不知道怎么退出。如果你装了 VSCode这里直接选 VSCode 会比较省心如果你不确定保持默认也行后面可以用命令改。2.2 安装后的环境检查和基础配置装完之后你先别急着建仓库先验证一下 Git 是否真的进到了 PATH 里。打开任意一个终端CMD 或 PowerShell 都行输入git --version如果能看到一串类似git version 2.40.0的输出说明安装成功。如果提示“不是内部或外部命令”大概率是刚才 PATH 那一步选错了有两个解决办法重装一次 Git 选第二项或者手动把C:\Program Files\Git\cmd加入到系统环境变量 Path 里。这个手动操作路径是右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 找到 Path → 编辑 → 新增一行填 Git 的 cmd 目录。接下来是最重要的全局配置告诉 Git 你是谁。因为每次提交代码时Git 都会记录提交人的名字和邮箱如果没配置第一次提交会直接报错或者弹提示。打开终端执行这两行命令git config --global user.name 你的昵称 git config --global user.email 你的邮箱注意这里的邮箱可以不是真实邮箱但建议用一个你常收信的邮箱因为以后在一些协作场景里别人可能通过提交邮箱联系你。配置完成后可以用git config --list查看当前所有生效的配置。这里顺便说一个 Git 的配置优先级Git 的配置分三个层级依次是 system、global、local。system 是整台机器生效global 是当前用户生效local 是当前仓库生效。优先级是 local global system也就是说如果你在某个仓库里单独配置了一个不同的用户名它会覆盖全局用户名。这个特性在以后给不同项目设置不同身份时很实用。除了命令行还有一个 Windows 上很流行的图形化工具叫 TortoiseGit也就是很多人说的“小乌龟”它会在文件夹右键菜单里直接显示 Git 的各种操作适合不习惯命令行的人。我的建议是新手可以装它作为辅助但核心命令还是建议学一下因为你在网上搜到的绝大多数教程、报错解决方案都是基于命令行的纯依赖图形界面会限制你排查问题的能力。3. 码云实战第一步仓库创建与 SSH 密钥配置3.1 注册账号并新建第一个远程仓库本地 Git 装好之后我们需要一个远程仓库来承接代码托管这里我用码云来演示。打开 Gitee 官网用手机号注册一个账号。注册过程中会要求手机验证部分功能可能还会引导你完成实名认证建议按流程走完否则后续某些操作可能会受限这也是平台账号安全机制的一部分不是多此一举。登录之后在页面右上角找到“新建仓库”的按钮点进去会看到仓库创建表单。有几个字段要重点说一下。第一个是“仓库名称”它相当于给这个项目起的名字我用my-blog这类名字简单好记就行后面生成的项目路径会自动带上你的用户名。第二个是“仓库介绍”可填可不填但建议填上比如“我的个人博客源码”这样以后公开分享时别人一眼能看明白。第三个很关键“是否初始化仓库”。如果你本地已经有了博客源码这里建议把 “初始化仓库” 下面的几个选项比如自动创建 README、.gitignore、开源许可证全部取消勾选让码云生成一个真正意义上的空仓库。为什么要这样因为如果你本地仓库和远程仓库各自都有一次不相关的初始提交第一次推送时会出现“分叉历史”需要额外处理合并对新手来说是额外的坑。空仓库最干净直接推上去就行。还有一个“开源许可证”选项很多人不知道选什么。简单说如果你的博客源码不打算让别人随便复制使用可以不选如果你希望公开源码并允许别人在保留署名的情况下使用可以选 MIT 这种宽松许可证。个人博客一般不用纠结不选就好。仓库的私有和公开选项码云的私有仓库是免费的如果你不想让别人看到你的源码和文章草稿选私有如果以后想把这套源码作为作品展示给别人看就选公开。这个随时能改不用太纠结。3.2 SSH 密钥让你免密推送的关键远程仓库建好之后接下来要打通本地和码云之间的传输通道。这里我强烈建议用 SSH 方式而不是 HTTPS 方式。HTTPS 方式每次git push都可能让你输入账号密码而且码云对 HTTPS 的密码输入有各种验证要求体验很繁琐。SSH 方式本质上是用一对密钥做身份认证私钥留在本地公钥是公开的、可以上传到码云推送代码时 Git 会自动完成加密验证不需要输密码也安全得多。生成密钥的方法很简单。打开终端Git Bash 最好执行ssh-keygen -t rsa -b 4096 -C 你的邮箱如果你的系统支持 Ed25519 算法也可以把-t rsa -b 4096换成-t ed25519更现代、密钥更短。敲完命令后会问你保存路径直接回车用默认的~/.ssh/id_rsa就行然后又问你是否设置密码短语passphrase这里可以直接回车跳过如果你设置了每次使用密钥时都要输一遍密码个人开发环境没什么必要。执行完后在你的用户目录下的.ssh文件夹里会生成两个文件id_rsa是私钥永远不要给任何人、不要上传到任何网站id_rsa.pub是公钥就是接下来要交给码云的。怎么把公钥复制到码云Windows 下你可以直接用记事本打开C:\Users\你的用户名\.ssh\id_rsa.pub这个文件内容是一长串文本大概率以ssh-rsa开头以你的邮箱结尾。全选复制然后打开码云官网进入“个人设置” → “SSH 公钥”把内容粘贴进去填一个容易记得的公钥标题比如“我的主力电脑”保存即可。保存成功后回到终端测试一下连接ssh -T gitgitee.com首次连接时终端会提示确认主机指纹输入yes回车。如果看到类似 “Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.” 的提示就说明 SSH 配置成功了。这里有个小坑有些人复制公钥的时候会漏掉结尾的邮箱或者不小心多复制了一个空格会导致验证失败。如果测试报错先检查公钥内容是否完整、是否有多余空白字符这是一半以上新手会遇到的问题。4. 把本地博客源码推送到码云常用 Git 命令实战4.1 初始化本地仓库并关联远程仓库SSH 配置好之后就可以正式把本地博客源码变成 Git 仓库了。假设你的博客项目在D:\my-blog目录下打开终端切换到该目录。如果你用的是 Git Bash可以用cd /d/my-blog这样的方式如果你用 CMD 或 PowerShell直接cd D:\my-blog就行。然后执行git init这条命令会在当前目录下创建一个隐藏的.git文件夹这个文件夹就是 Git 的本地仓库数据库你的所有版本历史都存放在里面。执行完之后你还可以看到当前分支名的变化新版本 Git 默认可能会叫master或main具体取决于版本后面我们可以统一。接下来把远程仓库的地址关联到本地。回到码云的仓库页面复制 SSH 地址注意选 SSH 而不是 HTTPS。然后执行git remote add origin gitgitee.com:你的用户名/my-blog.git这里的origin是远程仓库的默认别名相当于给这个远程地址起了一个简短的名字以后推送、拉取时直接说origin就行不用再打一长串地址。执行完后用git remote -v确认一下能看到 fetch 和 push 两个 url 都指向码云仓库这就说明关联成功了。还有一种情况是你想先在码云建一个空仓库然后把它克隆下来如果你打算这么做就不需要git remote add了直接git clone gitgitee.com:你的用户名/my-blog.git它会自动帮你把远程关联好你只需要把源码文件复制进去就行。4.2 第一次提交与推送从 add 到 push仓库初始化好之后把博客源码加入 Git 管理核心操作是三个命令git add、git commit、git push。我逐个解释一下因为很多新手就是在这里迷路的。git add .的作用是把所有尚未跟踪的、或者有改动的文件加入暂存区。注意这里有个重要前提在第一次 add 之前最好先创建好.gitignore文件把不需要管理的目录和文件排除掉否则你可能会把node_modules这类庞大的依赖目录一股脑提交上去。关于.gitignore的具体内容我后面会单独讲这里先简要说一下像依赖目录、构建产物目录、日志文件这类不该进仓库的东西提前写进忽略规则。执行完 add 之后用git status看一下当前状态。你会看到一堆绿色文字的文件列表说明这些文件已经被 Git 纳入本次暂存。然后执行提交git commit -m first commit: 初始化博客源码-m参数后面跟的是本次提交的说明文字这个说明要简短清晰地描述本次改动方便以后回看历史。提交完之后本地仓库就有一条记录了。这里有个常见疑惑commit 是在本地完成的跟远程还没关系所以现在就算断网也不影响。接下来是把本地提交推到码云。第一次推送时需要把本地分支和远程分支关联起来我用这条命令git branch -M main git push -u origin main第一行git branch -M main是把当前分支重命名为main。如果你的 Git 默认分支已经是main这行可以跳过如果本地是master码云默认分支是main建议统一一下否则后面容易混乱。第二行里的-u参数非常关键它会把本地分支和远程分支的跟踪关系记录下来执行完这次之后以后直接敲git push就能推送不用再带origin main了。第一次推送完成后去码云仓库页面刷新一下看到源码文件出现在里面就说明你的博客源码正式完成了代码托管。4.3 日常更新博客的推送套路仓库跑起来之后日常维护其实只有固定的几步。比如你写完一篇新文章路径是source/_posts/my-new-post.md那么操作就是git add source/_posts/my-new-post.md然后git commit -m docs: 新增文章《xxx》最后git push。如果你改的是主题配置比如调整了导航栏那就git add _config.yml提交信息写成style: 调整导航栏样式。这套操作的核心思路是每次只提交跟本次改动相关的文件提交信息写清楚“做了什么”而不是笼统地git add .加一句“更新”。很多新手会把git add .当成万能操作随手就 add everything然后 commit 一句“修改”。这样不是不行但会带来两个问题一是以后回看历史时很难定位某次具体改动二是很容易把不想提交的文件比如编辑器临时文件、包含密钥的配置文件一起提交上去。我的建议是日常用git add 具体文件名或者git add 具体目录提交信息尽量用“类型: 描述”这种格式比如docs:、fix:、style:、refactor:。这个习惯在团队协作中是硬要求在个人项目里虽然没人要求你但养成了之后三个月后回看自己的提交历史会非常清晰。换新电脑或者从别的地方继续写博客时流程是先git clone gitgitee.com:你的用户名/my-blog.git把仓库完整拉到本地然后在新的电脑上正常编辑。如果离开了几天、码云上的仓库被别人或其他电脑更新过本地再次开始写之前先执行git pull把远程最新的改动拉下来。这里有一个必须注意的坑git pull之前先看看本地有没有未提交的改动如果有可以先git commit提交一次或者git stash暂存起来否则容易出现冲突提示。个人博客一般只有一台主力机在写冲突概率不高但养成习惯总没错。4.4 提交信息写错了怎么办git commit --amend写提交信息这件事谁都难免手误。比如 commit 完之后发现说明文字打错字了或者忘了把某个文件加进去这时候很多人第一反应是慌其实 Git 提供了非常贴心的补救命令git commit --amend。这个命令的作用是“修改最近一次提交”。如果你只是想把提交信息改一下直接执行git commit --amend -m 正确的新提交信息如果你是想把漏掉的文件补进这次提交里那就先git add 漏掉的文件然后执行git commit --amend不带-m也行Git 会打开编辑器让你修改提交信息保存退出后最近一次提交就包含了新增的文件和新的说明文字。这个操作不会新增提交历史而是把原来的提交“替换”成一个新的提交。不过有个注意事项amend会改写 Git 历史所以如果这次提交已经推送到远程了就不要随便用amend否则下一次git push会因为本地和远程历史不一致而报错需要强制推送才能解决这在多人协作里是很危险的操作。个人博客自己一个人玩影响不大但我还是建议你养成习惯提交还没推送之前随便 amend推送过之后想改就新建一个提交不要改写历史。还有一个常用补救场景是git reset系列比如你想撤销最近一次提交但保留文件改动可以用git reset --soft HEAD~1这个命令能让你回到提交前、文件还在暂存区的状态再重新组织提交内容。5. 博客部署里的 Git 进阶忽略规则、标签与查看历史5.1 .gitignore这些文件千万别提交前面几次提到.gitignore这一节专门说透。.gitignore是放在仓库根目录下的一个文本文件里面写的是 Git 应该忽略的文件和目录规则。为什么博客项目特别需要它因为大部分静态博客框架会在本地生成依赖目录和构建产物这些目录动辄几百 MB、几万个文件如果提交进仓库会让仓库体积变得巨大、clone 变慢而且完全没有意义——因为它们可以根据源码重新生成。不同博客框架的忽略规则略有差异但有一个通用基础模板。以 Hexo 为例你的.gitignore至少应该包含这些内容node_modules/ public/ .deploy_git/ db.json *.log .DS_Store .env解释一下node_modules/是 npm 安装的依赖需要忽略public/是 Hexo 生成的静态站点文件属于构建产物不需要进仓库.deploy_git/是 Hexo 部署时生成的临时 Git 目录一定要忽略db.json是 Hexo 的数据库缓存文件*.log匹配所有日志文件.DS_Store是 macOS 的文件夹元数据文件.env是环境变量文件里面很可能有敏感信息必须忽略。如果你用的不是 Hexo思路是一样的去框架文档里查一下“gitignore 推荐配置”把依赖目录、构建目录、缓存文件排除掉就行。还有一个更关键但容易被忽视的提醒千万不要把密钥文件提交进仓库。比如刚才生成的id_rsa私钥、各种 API Token、服务器密码、数据库连接字符串这些都绝对不能出现在仓库里。很多账号安全事件、云主机被入侵追根溯源都是因为有人在代码仓库里提交了.env文件或者密钥文件。万一你已经误提交了除了删除文件再提交一次之外还要意识到历史记录里可能仍然有这份密钥的痕迹最保险的做法是立刻去对应平台把密钥作废、重新生成然后清理仓库历史。新手的简单做法是把远程仓库删除重新建一个空仓库再推一遍。虽然粗暴但比留着隐患强。5.2 用 Git 标签给版本留个记号代码托管还有一个被个人开发者低估的功能标签tag。标签相当于给某个提交打上一个固定的、有意义的标记你可以把它理解成给版本历史贴便利贴。博客项目里什么场景适合用标签比如你完成了博客主题的一次大改版整个站点视觉风格焕然一新或者你把博客框架从旧版本升级到了新版本这种里程碑式的节点打一个标签非常合适。操作很简单git tag -a v1.0 -m 主题改版完成整体焕新-a表示创建一个附注标签-m是标签说明。执行完git tag可以列出所有标签能看到你刚才创建的v1.0。标签默认只在本地要推送到码云需要单独执行git push origin v1.0以后如果博客出了问题想看看 v1.0 这个版本到底长什么样可以用git checkout v1.0临时切到这个版本查看或者根据标签定位 commit再用git diff v1.0对比当前版本和 v1.0 的差异。标签有个非常好的特性它指向的是一个不可变的提交快照不会因为你之后继续提交而改变。也就是说标签就像是给“某个时刻的博客”拍了一张永久照片任何时候想回头都找得到。这个功能对个人项目来说比想象中有用得多。5.3 高效查看历史log、diff 和 status 的用法日常使用 Git 时git log、git diff、git status这三个命令你会反复用到我建议第一次接触 Git 就把它们刻在脑子里。git status是每次操作之前必看的命令它告诉你当前仓库处于什么状态哪些文件有改动、哪些文件已暂存、当前在哪个分支、和远程分支有没有同步偏差。遇到任何 Git 异常第一步永远是执行git status看现场而不是瞎猜。git log用来查看提交历史。简版用法git log --oneline会以一行的形式显示每条提交的哈希值和说明文字一眼扫过去就能看清项目演进脉络加上--graph参数还能看到分支合并的图形化展示。很多开源项目维护者喜欢用git log --oneline --graph --decorate组合这个组合值得你直接记住。git diff用来查看“改动的内容”。不带参数时它显示的是工作区和暂存区之间的差异也就是你改了但还没 add 的内容带--staged参数时显示的是暂存区和上一次提交之间的差异也就是你已经 add 但还没 commit 的内容。对博客写作场景来说git diff最实用的场景是改完主题配置后忘了自己改了哪些参数执行一下git diff所有改动一目了然这会比你在文件里反复找高效得多。为了方便日常使用我把博客维护中最常用的 Git 命令整理成一个速查表操作场景常用命令说明查看状态git status查看工作区、暂存区、分支状态查看改动git diff查看未暂存的改动内容查看历史git log --oneline以简洁格式查看提交历史暂存改动git add 文件名把指定文件加入暂存区提交git commit -m 说明把暂存区内容提交为一条记录推送git push把本地提交推送到远程拉取git pull把远程新提交拉取到本地打标签git tag -a 标签 -m 说明给当前提交打附注标签修改最近提交git commit --amend修改最近一次提交查看远程git remote -v查看远程仓库地址6. 常见问题与排查技巧实录6.1 fatal: not a git repository 到底怎么回事这个报错可能是新手遇到最多的一个。完整信息是fatal: not a git repository (or any of the parent directories): .git。看到这句话的时候先别慌它说明的是你当前所在的目录不是一个 Git 仓库而且它的上级目录也没有 Git 仓库。最常见的原因是终端当前位置不对。比如你在D:\根目录下执行git status这里没有.git文件夹所以 Git 就会这样报错。解决方法很简单先cd到你的博客项目目录再执行 Git 命令。如果你确认已经在项目目录里了但还是报这个错那就要检查项目目录下有没有.git文件夹了。Windows 下默认隐藏点开头的文件夹你可能看不到可以通过文件资源管理器的“查看 → 勾选隐藏的项目”看或者在终端里执行ls -a查看。如果.git文件夹确实不存在说明这个目录还没有被初始化过需要先执行git init初始化。还有一种少见但确实会发生的情况.git文件夹被人误删了那本地历史就没了只能重新git init再从远程 clone 或者重新关联远程地址。6.2 克隆远程仓库太慢或失败怎么办网络问题永远是国内开发者绕不开的话题尤其是从境外平台克隆仓库时速度忽快忽慢、甚至直接失败都有可能。如果你是从 GitHub 这类海外平台拉取博客主题或者代码一个非常实用的技巧是利用码云的“仓库导入”功能。码云支持从 GitHub、GitLab 等平台导入仓库你只需要在码云上选择“从 GitHub 导入仓库”填上原仓库地址码云服务器会先把代码拉取到自己这边然后你再从码云 clone 到本地。这样两个环节都是在国内网络环境内完成速度会稳定很多等于让码云帮你做了个中转和缓存。如果你是从码云本身的仓库克隆也慢那就要从自己这边找原因了。首先检查一下是不是有别的程序占用了大量带宽比如正在下载大文件、视频应用在后台跑着其次关掉系统代理之类的设置有时代理配置反而会让国内直连变慢。还有一个低级但常见的错误克隆时选错了地址。码云仓库页默认展示的可能是一个超级长的 HTTPS 地址你复制到一半或者手打导致漏字符就会克隆失败。一定要用仓库页右上角“克隆/下载”按钮旁边的复制图标一键复制完整地址避免手输。如果实在急着拿到代码仓库页也提供直接下载 ZIP 压缩包的选项但这样拿到的只是文件快照、没有 Git 历史只适合临时应急。6.3 码云账号被限制或仓库被屏蔽的常见原因与应对这个话题在热搜词里出现过说明不少人踩过坑。码云账号被限制访问、仓库被屏蔽原因其实大同小异绝大多数是仓库内容或者账号行为违反了平台规范。最常见的情况包括仓库里存放了违规资源、恶意脚本、涉及侵权的内容或者账号存在批量注册、恶意操作等异常行为。还有一种很多人忽略的情况仓库里意外提交了包含敏感信息的文件比如数据库密码、私钥、身份证号这类内容一旦被平台检测到也可能触发安全限制。如果不幸遇到账号或仓库被限制我的建议是分三步走。第一步先自查登录码云把所有公开的仓库挨个检查一遍重点看 README、资源文件、项目内容里有没有违规或敏感的东西一旦发现有问题的仓库立刻删除或者改为私有。第二步检查账号的实名认证状态码云要求用户完成手机验证、实名信息填报后才能使用全部分类功能如果你之前没走完认证流程某些限制其实只是功能未解锁不是被封禁。第三步如果确实没有违规、但账号仍然被限制那就通过码云的官方申诉渠道提交工单说明你的账号使用场景、被限制的时间点、已经完成的自查情况等待平台人工审核。这里要特别提醒不要在网上到处发帖骂平台或者问“为什么被封”那解决不了问题老老实实走官方渠道才是最快的。6.4 IDEA 或其他 IDE 里提交代码报错怎么办很多博客作者会用 VSCode、IDEA 这类编辑器来写文章和提交代码IDE 里集成 Git 确实方便但也经常出一些专属问题。最常见的报错是 “Cant run Git” 或者 “git not found”这种基本上就是 IDE 没有找到 Git 的安装路径。VSCode 的思路是打开设置搜索git.path把你本机git.exe的完整路径填进去比如C:\Program Files\Git\cmd\git.exe。IDEA 的路径是File → Settings → Version Control → Git → Path to Git executable选择同样路径然后点 Test 测试。一般测试通过就能正常使用。另一个常见问题是 IDE 提示登录失败、token 失效之类的典型提示类似 “login failed. check api token or gitlab version” 或者 “Authentication failed”。这种问题通常跟 SSH 配置没生效有关或者 IDE 里保存的账号密码已经过期。你可以在终端里先执行ssh -T gitgitee.com确认 SSH 免密是正常的如果终端能通过、但 IDE 报错那问题多半出在 IDE 的身份认证配置上——让 IDE 使用 SSH 而不是 HTTPS 方式拉取远程地址或者在 IDE 的凭据管理里删掉之前保存的旧登录信息重新触发认证。总之遇到 IDE 相关 Git 问题通用排查顺序是先在命令行验证 Git 本身没问题再检查 IDE 配置最后检查远程仓库地址是否正确一层层缩小范围不要一上来就断言是 IDE 坏了。6.5 其他我踩过的坑大小写、换行符和误提交密码最后分享几个我实际踩过的坑这些坑不在官方文档里被重点强调但撞上的人真的不少。第一个是文件名大小写问题。Git 在 Windows 和 macOS 上默认不区分文件名大小写如果你把一个文件名从About.md改成about.md直接提交可能不会生效Git 认为文件没变化。解决办法不是用文件管理器改名而是在终端里用git mv About.md about.md来移动/改名这样 Git 才能正确识别到变化。如果已经踩了坑文件在仓库里显示旧名字、磁盘上已经是新名字可以用git add -A后检查 status 再提交有时也能救回来但还是建议提前用git mv避免混乱。第二个是换行符问题。前面安装时我强调过选行尾转换但有些人是装完才发现问题的表现就是随便改一个文件git diff显示成千上万行都变了。如果不幸发生了可以写一个.gitattributes文件放在仓库根目录在里面声明* textauto或者针对特定目录指定换行符规则强制让 Git 统一处理。.gitattributes一旦提交并推送能让所有克隆这个仓库的人都用同一套换行符规则是从根本上解决换行符混乱的方案。不过这个文件里的语法规则比较多新手可以先用最基础的* textauto配合安装时的行尾选择后面遇到具体文件类型再慢慢补充规则。第三个是误提交敏感信息。比如我把一个测试用的服务器密码写进配置文件稀里糊涂就git push到了公开仓库。发现之后光在最新版本里删掉是没用的因为 Git 历史里还留着。对新手来说最省事的处理方式是马上登录码云把相关凭据在业务侧先作废掉如果仓库是公开的立即改成私有然后考虑清理历史。清理历史可以借助git filter-branch或者工具 BFG Repo-Cleaner但这些命令有难度、也有风险容易把仓库搞乱所以我给新手的建议是如果这个仓库刚建没几天、历史不多直接删除远程仓库重新建一个然后重新推送更干脆。这不是最优雅的方案但在个人项目里快速止损比追求优雅重要得多。这个系列走到代码托管这一步我自己最深的体会是把博客源码交给 Git 之后折腾起来心态完全不一样了。以前改一个配置要小心翼翼担心改坏了就完蛋现在随便改改完看效果不满意就回滚甚至拿分支当一个“草稿区”来实验各种想法好用就保留不好用就丢弃。最后再分享一个小习惯每次发布一篇文章提交信息都用统一的格式比如docs: 新增《个人博客自建指南三》一个月后回看提交记录所有文章的历史脉络清清楚楚。写博客这件事长期坚持靠的是流程顺手而 Git 这样的工具一旦用顺了你就再也回不去没有它的日子了。