说实话自建博客这件事前面几篇把框架搭起来、页面跑起来之后很多人会卡在同一个地方代码怎么管。尤其是博客这种需要长期改、反复调的内容型项目如果没有一套版本管理机制早晚会把自己搞糊涂。我见过太多人改着改着就分不清哪个版本能用了或者电脑一坏、文件一丢整站代码灰飞烟灭。这篇就是来解决这个问题的讲讲 Git 的基本用法和码云的实际操作帮你把博客代码稳稳地托管起来。这篇内容适合谁正在自建博客但还没引入版本控制的人以及已经装了 Git 但只会 add、commit 两个命令、完全不知道怎么和远程仓库配合的人。我尽量用实际操作场景来讲把命令是什么、为什么要这么敲、敲完会发生什么都说清楚。1. 内容整体设计与思路拆解1.1 为什么博客这类小项目也要上代码托管先回答一个很多人会问的问题我博客就几个页面代码量也不大有必要用 Git 和代码托管平台吗有必要而且越早用越省心。博客和其他软件项目有个本质区别——它是“长期维护型”的不是写完就交付的。你今天改个样式明天加篇文章后天可能又把某个功能推倒重来。如果没有版本管理这种持续修改会带来三个很现实的问题第一改坏了没法回退。改样式时手滑删了个标签页面整个乱掉但你已经忘了之前是什么样只能凭记忆一点点补浪费时间还容易出错。有 Git 的话一条命令就能回到任意一个历史版本。第二多个设备同步困难。你在台式机上改了文章想在笔记本上继续写没有远程仓库的话就得用 U 盘拷来拷去或者用云盘同步。这个方案的问题在于容易覆盖你有过两个设备上各改了一半、互相覆盖的经历吗一次就能让人崩溃。第三没有备份。很多人觉得代码放本地硬盘就够了直到硬盘坏掉、电脑进水、误删文件夹才追悔莫及。远程代码托管平台天然就是一个异地备份本地没了拉下来就是。所以代码托管这件事不是大厂团队的专利个人小项目照样需要。它本质上是给你的代码上了一份保险同时给了你一台“时光机”。1.2 为什么选 Git 加码云的组合版本管理工具里Git 已经不是“选项之一”而是事实标准。它由 Linux 之父 Linus Torvalds 开发为了解决 Linux 内核这种超大规模项目的协作问题而生分布式架构设计让它天然适合各种规模的项目——大到几千人协作的巨型项目小到一个人维护的博客都能胜任。那远程托管平台为什么选码云Gitee原因很简单国内访问速度快不像有些海外平台需要额外的网络配置才能顺畅使用push 和 pull 都很快。对个人开发者友好私有仓库免费博客代码放在私有仓库里不用担心被别人看到或者抄袭。平台语言和文档都是中文的对新手极其友好遇到问题能直接看懂官方帮助文档。后续如果想给博客配 Gitee Pages可以直接在码云上操作属于一个生态里的东西。当然如果你有国际化的需求GitHub 也很好注册流程更简单些。但从国内自建博客的实际使用体验来讲码云是更顺滑的起点。两个平台的 Git 操作逻辑完全一样在码云上学会了切到 GitHub 也就是注册个账号的事没有任何迁移成本。1.3 这篇文章的整体思路这篇按实际操作流程来组织先从 Git 的安装说起因为这是基础——然后讲本地仓库的建立和基本提交流程让你先能在本地用起来——接着讲码云账号准备、SSH 密钥配置这些连接远程仓库的前置工作——再讲本地代码怎么推送到码云——最后讲日常更新的工作流和一些常见问题的排查。这样的顺序就是你第一次实操时会走的完整路径跟着敲一遍整个流程就跑通了。2. 环境准备Windows 下安装 Git2.1 下载与安装过程Windows 下安装 Git 基本属于“一路下一步”的操作但有几个选项值得注意一下。先去 Git 官网下载对应系统版本的安装包建议下载 64 位的 Standalone Installer 版本。安装过程中有几个选择点需要留意选择安装路径时建议保持默认路径C:\Program Files\Git不要放到带空格或者中文的路径里省得后面出现莫名其妙的问题。在选择默认编辑器时对新手来说我强烈推荐选 Notepad 或者 VS Code。Git 的很多操作比如写提交信息、合并分支时处理冲突会调用默认编辑器如果选了 Vim 而你不会用 Vim会卡在“怎么保存退出”这个尴尬问题上。关于 Vim 卡住的问题下面“常见问题”部分我会讲。关于设置 PATH 环境变量的选项选择默认推荐的 “Git from the command line and also from 3rd-party software” 就行。这个选项会把 Git 的可执行文件加入系统 PATH以后在 CMD 或者 PowerShell 里也能直接用git命令操作范围更灵活。关于行末转换line ending conversion的部分这边建议选第一个选项 “Checkout Windows-style, commit Unix-style line endings”。博客代码以后要部署到 Linux 服务器的话这个选项能帮你避免换行符CRLF 和 LF导致的兼容性问题。安装完成后在桌面空白处右键菜单里会出现 “Open Git Bash here” 的选项也可能直接显示为 “Git Bash Here”。Bash 界面打开后输入下面的命令验证是否正常git --version如果看到类似git version 2.39.1.windows.1的输出说明 Git 安装成功。如果显示“无法识别 git 命令”多半是 PATH 配置有问题回到安装程序修复一下或者检查环境变量的系统变量 Path。2.2 安装完成后需要做的第一步配置装好 Git 之后有两项配置必须立刻做——设置你的用户名和邮箱。这个不是可选项因为 Git 每次提交代码时需要记录提交人信息。如果没配置提交的时候会直接报错。在 Git Bash 里执行git config --global user.name 你的名字 git config --global user.email 你的邮箱需要说明的是这里的名字和邮箱是写在提交记录里的作者信息可以和你码云账号的注册信息保持一致但不是强制的。不加--global的话配置只对当前仓库生效加了表示这台机器上所有仓库默认使用这套信息。个人电脑建议加--global一次配置全局生效。你可以用以下命令查看当前配置是否生效git config --list命令会列出 Git 当前所有的有效配置项像 user.name、user.email、core.autocrlf 这样的都能看到。2.3 Git Bash 是什么为什么推荐用它Git 安装后会附带一个叫 Git Bash 的终端环境。新手很容易搞不清楚它和 CMD、PowerShell 的区别。简单说来Git Bash 是一个能够在 Windows 上模拟 Linux 终端操作风格的环境——这意味着你在网上搜到的绝大多数 Git 教程里面的命令在 Git Bash 里可以直接用不用做任何转换。举个例子Linux 下的目录查看命令是lsWindows 的 CMD 是dir。在 Git Bash 里用ls就能正常查看文件列表clear清屏、pwd查看当前路径都和 Linux 下表现一致。Mac 用户没有这个问题因为 Mac 原生就是类 Linux 环境。Windows 用户建议全程使用 Git Bash能少踩很多命令不兼容的坑。3. 本地仓库建立与首次提交3.1 初始化仓库git init现在假设你的博客代码位于D:\myblog这个目录下。在 Git Bash 中切换到该目录cd /d/myblog注意 Git Bash 的路径写法它把 Windows 下的D:\转成了/d/斜杠的方向和盘符的表示方式都不同这个转换刚开始不太习惯但用几次就熟了。然后执行初始化命令git init如果输出Initialized empty Git repository in D:/myblog/.git/说明一个 Git 仓库已经在当前目录创建成功了项目根目录下会多出一个隐藏的.git文件夹。这个文件夹是 Git 的所有“数据库”记录着项目的全部历史。这个文件夹不要手动去改、去删删了历史就没了。你会发现.git文件夹在文件管理器中默认是隐藏的要看的话需要在文件资源管理器里打开“显示隐藏的项目”选项。3.2 把文件加入版本管理git add初始化之后仓库是空的。哪怕目录里已经有文件了Git 也不会自动跟踪它们必须手动把文件加进来。这里有一个非常重要的概念Git 对文件的管理分了三个区工作区就是你本地看到的那些文件比如你的博客的 HTML、CSS、JS 文件。暂存区一个过渡区域存放你“准备提交”的改动的快照。版本库Git 真正保存历史记录的地方。修改了一个文件之后它先停留在工作区执行git add它进入暂存区执行git commit它才被正式写入版本库成为一个历史版本。这个“先暂存再提交”的设计初看有点多余实际用起来很有用。它让你可以把多个文件的改动分组比如今天改了样式又加了篇文章想分两次提交、留下两条清晰的历史记录那就可以第一次只add样式文件并提交第二次再add文章文件并提交。先把文件加进来看下状态git statusgit status是一个高频命令用来查看当前仓库的状态。新初始化的仓库里执行你会看到类似下面的输出On branch master No commits yet Untracked files: (use git add file... to include in what will be committed) index.html assets/ articles/Untracked files就是 Git “看到了但还没接管”的文件。要全部加入版本管理执行git add .这会把当前目录下所有未跟踪的文件都加入暂存区。如果只想加入某个文件git add index.html这样指定就行。再执行git statusUntracked files会变成Changes to be committed文件状态就不一样了。3.3 记录首个版本git commit文件进入了暂存区就可以正式提交了git commit -m 初始化提交博客初始版本-m后面的引号内容就是提交信息。提交信息要写得有意义让未来的自己或者协作者能从中看出这个版本改了些什么内容。“初始化提交博客初始版本”这种写法就不错直接明了写成“修改”或者“11.11”这种信息过两周你自己都看不明白。如果没有加-m参数Git 会打开之前配置的默认编辑器来写提交信息。如果你配置了 VS Code 或 Notepad那就比较顺手TESTS比较麻烦的是默认 Vim 下写好信息你却不知道怎么保存退出这种情况我在“常见问题”部分会专门说。提交成功后会有类似这样的输出[master (root-commit) 7d4b8c2] 初始化提交博客初始版本 10 files changed, 3568 insertions()7d4b8c2是这次提交的版本号commit hash前面 7 位的简短形式。以后想回退到这个版本靠它就行。3.4 查看提交历史git log提交了几次之后可以查看历史记录git log输出会按时间倒序列出所有提交记录每条包括版本号、作者、日期和提交信息。加上--oneline参数每条记录会被压缩成一行浏览起来更清爽git log --oneline输出的样子大致是8c2f1a3 (HEAD - master) 修正首页导航栏样式 5b0f6d2 新增文章我的第一篇博客 7d4b8c2 初始化提交博客初始版本有时提交后想追加修改内容比如刚提交完才发现漏了个文件可以这么做git add 漏掉的文件 git commit --amend -m 新的提交信息--amend会把刚才那次提交和现在的暂存内容合并成一次新提交不会产生多余的历史记录。要注意的是它适用于 push 之前的“修正”场景如果代码已经 push 到远程仓库不要轻易用--amend会搞乱远程历史的。3.5 忽略不需要提交的文件.gitignore有些文件是不应该进入版本管理的比如编辑器的临时文件、操作系统产生的缓存文件、含有本地敏感信息的配置文件等。对于博客项目来说比较典型的有.DS_StoremacOS 下的资源索引文件.vscode/每个项目的 VS Code 私密配置node_modules/如果你用了 npm 管理依赖这个目录可能有几百 MB绝非入库对象本地图片缓存目录等不想把这些文件提交上去就需要.gitignore文件了。在博客项目根目录下新建.gitignore文件写上规则.DS_Store .vscode/ node_modules/ *.log每一行是一条忽略规则。*是通配符*.log表示忽略所有以.log结尾的文件。.gitignore文件本身要提交到仓库里去这样换设备或者别人克隆你的项目时忽略规则也能随之生效。4. 码云账号准备与 SSH 免密配置4.1 注册码云账号并新建远程仓库码云的官网是 gitee.com访问后直接用手机号或邮箱注册即可验证流程和大多数国内平台类似。注册完成后登录进入控制台页面点右上角的“新建仓库”按钮跳转到仓库信息填写页面。几个关键配置项需要注意仓库名称建议和你的博客项目简称一致用英文字母和连字符比如my-blog。仓库名会出现在远程仓库的访问 URL 里使用英文更容易输入。路径仓库路径也建议使用英文。例如仓库名my-blog那路径也会是my-blog。开源还是私有自建博客的源码如果里面可能有数据库连接信息、个人信息、密码等建议选私有。博客对外展示的是构建后的静态文件或最终生成的页面而不是源码实际部署不需要别人看到源码。选择分支模型码云默认分支名一般是master新版可能默认main无所谓按默认走就行。初始化仓库底部有两个初始化选项——添加 .gitignore 模板和添加开源许可证。建议不要勾选保持空仓库因为我们本地已经建好了仓库远程仓库保持干净以免和本地内容产生冲突和多余的合并历史。点击创建之后你会看到一个空仓库的页面。网页会展示几种关联本地仓库的方式包括 HTTPS 方式和 SSH 方式先不用急着操作直接跳到下面的 SSH 配置。4.2 生成 SSH 密钥ssh-keygen本地电脑怎么和码云建立安全的身份认证这里有两种方式一种是 HTTPS每次操作都需要输入用户名密码或者使用凭据管理器记住用起来稍显繁琐另一种是 SSH 免密配置一次以后 push、pull 都不用输密码建议使用这种方式。SSH 的运作机制简单来说是一个密钥对一把私钥留在你本地电脑相当于你的私人身份标识一把公钥放到码云服务器相当于门禁卡两把钥匙配对成功才能放行私钥不会在网络上传输。在 Git Bash 里执行ssh-keygen -t rsa -b 4096 -C 你的邮箱-t rsa指定加密类型-b 4096指密钥长度为 4096 位建议比默认的 2048 更安全-C后面的注释最好写你的邮箱方便以后多个密钥时分辨。执行后会出现提示Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/你的用户名/.ssh/id_rsa):这里直接按回车使用默认路径就好。接下来提示输入密码短语passphraseEnter passphrase (empty for no passphrase):这个密码短语是保护私钥的安全密码设置的话每次使用私钥时都要输入不设置直接回车跳过。对个人开发环境我建议直接不设置方便使用——只要电脑只有你自己用安全风险可控。生成完成后~/.ssh目录下会出现两个文件id_rsa是私钥id_rsa.pub是公钥。公钥可以安全地分享给别人私钥必须保密。4.3 把公钥配置到码云查看公钥内容cat ~/.ssh/id_rsa.pub输出是一长串以你的邮箱结尾的文本形如ssh-rsa AAAA...将这段完整复制。然后登录码云点击右上角头像进入“设置”页面左侧菜单找到“安全设置”中的“SSH 公钥”选项点击“添加公钥”。标题栏可以随便填比如写“我的Windows笔记本”公钥栏把刚复制的内容粘贴进去。确认后码云会要求输入一次账号密码来验证身份。添加成功后在 Git Bash 里验证是否通了ssh -T gitgitee.com首次连接时会有个确认提示The authenticity of host gitee.com (X.X.X.X) cant be established. ... Are you sure you want to continue connecting (yes/no)?输入yes回车。如果看到类似下面的输出Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明 SSH 配置成功。这个提示说不能登录到 shell但确实是认证成功的正常提示。4.4 为什么 SSH 比 HTTPS 更适合日常使用如果你只是临时上传一次代码用 HTTPS 也没多大问题。但博客是要反复更新的次数多了差别就出来了用 HTTPS 时如果你选择不记住密码那每次 push 都要手动输一次用户名和密码非常打断节奏。用 SSH 则配置完就不管了后续所有 Git 操作都是静默认证体验非常顺滑。另外码云的 SSH 认证走的是 22 端口HTTPS 走的是 443 端口。在某些网络环境下SSH 的连接稳定性会比 HTTPS 更好一些这个就不展开细说了。5. 本地仓库与码云对接首次推送就上手5.1 添加远程仓库地址git remote现在本地仓库有了远程空仓库也有了要做的事情就是把它俩“连起来”。在码云的仓库页面找到 SSH 格式的仓库地址看起来是这样gitgitee.com:你的用户名/my-blog.git然后回到 Git Bash在本地项目目录下执行git remote add origin gitgitee.com:你的用户名/my-blog.git这条命令的意思是给远程仓库起个名字叫origin地址是后面那串。origin只是一个约定俗成的默认名字代表你的主远程仓库改成gitee或blog也都可以。统一用origin的好处是你从网上看别的教程时里面的命令直接能跟着用。5.2 首次推送git push -u origin master执行推送命令把本地仓库的历史上传到码云git push -u origin master如果你本地分支名是main而不是master新版 Git 初始化时可能默认分支名变成了 main就把命令里的master换成main。这里拆解下参数的含义origin远程仓库的名字master要推送的本地分支-u--set-upstream的简写把本地master分支和远端的master分支建立关联。设置之后以后直接执行git push和git pull就行不用再带上origin master指定了首次推送的输出会显示一些统计信息比如* [new branch] master - master Branch master set up to track remote branch master from origin.这时去码云的仓库页面刷新一下能看到本地代码已经上传上去了。5.3 处理第一次推送可能遇到的坑很多人第一次推送的时候会碰到报错大概长这样! [rejected] master - master (fetch first) error: failed to push some refs to gitgitee.com:你的用户名/my-blog.git hint: Updates were rejected because the remote contains work that you do not have locally.这个报错的原因通常是远程仓库里有本地没有的提交——最常见的场景是你在码云网页上创建仓库时勾选了“初始化仓库”这样远程仓库就会自动生成一个包含 README.md 或 .gitignore 的初始提交而你本地仓库完全没有这个历史两个仓库的起点就不同了。解决办法有两个第一个、在码云网页上删除这个仓库重新创建一个纯空仓库并且这次注意不要勾选任何初始化选项。这样最简单适合还没绑定任何东西的情况。第二个、先拉取远程仓库并合并再推送git pull origin master --allow-unrelated-histories--allow-unrelated-histories允许两个历史完全独立的分支合并。合并完成后可能有冲突处理完冲突再git push -u origin master这个方法适合远程仓库里已经有重要内容、不能删了重建的情况。我等建议第一条路线——如果仓库刚建什么都没有删了重建是最省事的。5.4 后续的推送更新流程推送成功后日常的更新操作就很固定了基本就是三步git add . git commit -m 本次修改的内容描述 git push这三步对应了 Git 的三个操作阶段暂存改动→记录版本→上传远程。熟练后非常机械化几乎不用动脑子。结合博客实际场景再强调一点不要等到积累了一大堆改动再一次性提交。比如你写了三篇文章、改了导航栏、调了页面样式很可能你想在历史记录中能区分每一次独立的修改那就要拆成多次提交一次提交一件事把你改动的环节和对应代码一一对应。这样后续要定位某次问题能直接从历史记录里找到“罪魁祸首”。6. 分支管理与博客日常更新工作流6.1 分支是什么为什么博客也要用分支是 Git 里非常有分量的概念。简单理解分支是在主线的某个节点上开出一条平行世界在平行世界里你随便改、随便折腾不影响主线的稳定。有些人会觉得“我博客就一个人维护要什么分支”单人的博客项目其实不需要重度使用分支但理解分支并掌握基础操作是有价值的理由如下第一你现在可能不需要但博客功能复杂了之后会需要。比如你想给博客加一个新主题这是一项大工程会动很多文件搞一半可能页面就处于“废了一半”的状态。如果直接在主分支比如 master/main上改那这段时间你的项目代码就是不完整的也没法正常部署。正确的做法是拉一个临时分支feature/new-theme出来在这个分支上慢慢改改好了再合并回主分支。这样主分支始终是可用的、能部署的状态。第二要学会分支并不复杂核心命令就几条半天不到就能掌握。花这点时间未来遇到场景就能直接上手不会手忙脚乱。6.2 分支常用操作速查创建并切换到新分支git checkout -b feature/new-theme这条命令做了两件事-b表示创建新分支checkout表示切换过去。拆开来看就是git branch feature/new-theme git checkout feature/new-theme查看当前在哪个分支git branch输出里带星号或者显色高亮的那个就是当前分支。在新分支上做完修改并提交后切回主分支并合并git checkout master git merge feature/new-thememerge会把feature/new-theme分支的修改整合到当前分支中。合并完成后这个临时分支可以删除git branch -d feature/new-theme删除分支后当前分支代码不会少只是把分支名对应的引用删掉了。合并完成的分支用-d可以正常删除如果有未提交的修改Git 会拒绝删除这是保护机制。6.3 博客项目的推荐工作流结合博客这个具体场景我的建议是这样始终保持主分支master或main上的代码处于“可发布”状态。日常小改动比如修样式、改错别字、加个页面直接在主分支改、提交、推送都行完全可以。大改动比如换主题、重构目录结构、改动全站样式拉一个专用分支来做做好并验证没问题了再合并回主分支。具体流程示范git checkout -b redesign-nav # 修改导航相关文件 git add . git commit -m 重新设计导航栏布局 git checkout master git merge redesign-nav git push git branch -d redesign-nav这一趟操作下来你的主分支始终是干净的也留给未来的自己一个清晰的开发历史。6.4 需要处理合并冲突的常见情况合并分支时如果两边修改了同一个文件的同一处内容Git 就不知道应该听谁的于是产生“冲突”。比如你在feature/new-theme分支里修改了index.html的title标签同时在主分支上也改了title合并时就会报冲突CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.这时候 Git 会在冲突文件里插入特殊的标记让你手动确认保留哪边的修改。编辑器打开冲突文件后大概是这样 HEAD title我的博客/title title我的博客 - 新版本/title feature/new-theme HEAD和之间是当前分支的版本和之间是被合并分支的版本。你需要把不需要的标记行删除留下你想保留的内容保存文件。然后git add index.html git commit -m 合并分支解决标题冲突单人项目里冲突不太常见万一碰上了上面这个处理流程也够用了。7. 常见问题与排查技巧实录7.1 高频报错速查表我把新手经常遇到的一批报错和处理方案整理成了一个表格建议收藏遇到对号入座就好。报错信息原因解决方案git不是内部或外部命令Git 未安装或 PATH 未配置重装 Git 并确认 PATH 配置正确fatal: not a git repository (or any of the parent directories): .git当前目录不是 Git 仓库确认已执行git init或在仓库根目录下操作Please tell me who you are.未配置用户名和邮箱执行git config --global user.name和user.emailfatal: remote origin already exists.已经添加过远程仓库地址用git remote set-url origin 新地址更换或git remote remove origin删除! [rejected] ... (fetch first)远程仓库有本地没有的提交按 5.3 节处理Permission denied (publickey).SSH 密钥不匹配或未添加到码云检查公钥是否已配置确认使用的是 SSH 地址fatal: unable to access... SSL certificate problemHTTPS 证书校验问题更换 SSH 地址或在编码规范和网络要求允许时临时关闭 SSL 校验7.2 卡在 Vim 编辑器里退不出来怎么办经典新手难题。执行git commit且没有带-m参数时Git 会打开默认编辑器。如果默认编辑器是 Vim你会看到一个黑乎乎的界面按什么键都不起作用最后卡住了。在 Vim 界面下正确操作是先按一次Esc键进入命令模式然后按一下:进入命令行模式界面底部会出现冒号再输入q!感叹号表示不保存强制退出按回车就能退出。如果之前输入的提交信息不想丢失就不要用q!。不过也别每次都硬着头皮处理 Vim 了直接一劳永逸地换个默认编辑器更省心。在 Git Bash 里执行假设你用 VS Codegit config --global core.editor code --wait这条命令把 Git 默认编辑器配置成 VS Code。执行git commit时会弹出 VS Code 编辑器窗口你在里面写好提交信息关闭窗口Git 就会自动继续执行提交。7.3 推送时提示登录失败或找不到仓库这个问题分几种情况如果你是使用 HTTPS 地址push 时提示Login failed或者Authentication failed大概率是密码不对或者账号开了两步验证。两步验证启用后不能用账号密码直接操作需要到码云设置里生成私人令牌私人令牌也叫 Private Token在 push 时用令牌当密码。如果是 SSH 地址提示Repository not found先确认仓库是折叠在某个组织或账户下检查 URL 里的用户名和仓库名是否完全一致。另一个常见原因是你在码云上创建仓库时选的归属账号不是当前登录的账号比如仓库在 A 组织下URL 里写的却是个人用户名。排查时可以用一条命令看出具体连接问题ssh -T gitgitee.com这条命令能告诉你认证是否成功了如果成功问题多半出在仓库地址上如果认证失败按提示检查公钥配置。7.4 误提交了大文件怎么办博客项目里很容易出现一次误操作比如把一个几十 MB 的图片、视频文件 add 进去了。提交本身也许没多大事但推送到远程后这个文件就会永远留在 Git 的历史记录里仓库体积会越来越大、越来越臃肿。如果文件还没推送到远程处理方式很简单。回到提交之前重新执行一次提交git rm --cached 大文件名 git commit --amend这样大文件就从暂存区移除了同时用--amend修正之前那次提交让历史里不包含这个文件。如果已经推送到远程了处理起来就比较麻烦可能需要重写历史或使用 git-filter-repo 这类工具清理。所以预防才是最好的办法——把常用的大文件目录写进.gitignore并养成git status看一眼的习惯在 add 之前确认没有引入不该出现的文件。7.5 本地分支名和远程不一致的问题码云新建仓库时默认分支可能是master也可能让你设置成main不同版本的模板默认值不一样。如果你本地初始化出来的分支名和远程不一样比如本地是master远程是main推送时就要多带一个映射参数git push -u origin master:mainmaster:main的意思是把本地的master分支推送到远程的main分支。为了让以后的操作更省心建议统一命名。如果你更喜欢全新的main在本地重命名分支git branch -m master main然后重新关联推送。这个命令在各类云平台新老版本切换的时候是常客掌握了能省不少麻烦。8. 从码云上恢复这章教程的最后一个核心技巧8.1 模拟“换电脑”场景完整试一遍到这里本地仓库和码云已经通了最后再加一个大家都可能遇到的场景换了一台新电脑怎么把博客项目恢复出来第一步新电脑上安装 Git配置好用户名和邮箱生成好 SSH 密钥并添加到码云这一步在 4.2 和 4.3 已经详细说过按同样的流程走一遍。第二步克隆项目到本地git clone gitgitee.com:你的用户名/my-blog.gitgit clone命令会把远程仓库完整下载到当前目录包括全部历史记录和所有分支。这是新电脑上获取项目的最直接方式。第三步进到项目目录里正常操作cd myblog git branch -agit branch -a会列出所有分支包括远程的分支。看到之前推过的分支都在说明整个项目的“魂”都跟着过来了。这个场景背后体现的正是代码托管的核心价值你的代码不再只存在于某一块硬盘上而是有了一个独立的、可控的、随时可恢复的远程副本。这个保障对长期投入的内容型项目特别关键。8.2 注意小细节避免事后捶胸顿足整个流程走下来有几个小细节值得你特别注意第一提交信息一定要写清楚。今天你觉得“修改”两个字够用三个月后的自己看到这种信息只能一脸懵。这不算强制要求但真的是我用过最值回票价的习惯。第二改动提交前养成跑一下git status和git diff的习惯。git status看有什么文件被改动了git diff看具体改了什么内容能有效避免“我以为没改却 push 了一堆无关文件”的情况。第三大文件路径尽早写进.gitignore。等文件进了版本历史再剔除非常折磨人。第四码云账号注意安全和找回信息的完整度密码尽量用独立、强度高的注册邮箱保持可用状态。账号一旦无法登录远程仓库的代码就成了“看得见摸不着”的摆设。8.3 工作流与扩展下一步可以怎么玩把这套 Git 加码云的流程跑通之后你的博客项目已经拥有了一块安全、可靠的代码落点。接下来自然而然可以做的事还有不少在码云启用 Gitee Pages 服务直接把博客构建成网站对外访问通过 Webhook 或者 Gitee Go 配置简单的持续部署让 push 代码后自动发布到服务器把码云仓库镜像到其他平台实现双备份如果以后开始多设备写作那 Git 的分支和 pull 机制会让你做自动同步更顺畅。这些都是后话基础是先让 Git 用得顺、用得稳。回到这一章的主题代码托管不是一个“高深的工程师才该懂”的选项而是一个所有长期维护代码的人都应该上手的基本功。从git init到 SSH 配置从第一次 push 到日常 update核心流程就这么多。花个半天时间把流程走通你的博客就从一个“本地文件”变成了“有人替你保管、有据可查的项目”这个转变弥足珍贵。