企业官网建设流程全解析

在代码这行里摸爬滚打的人，八成都有过一段“手工作坊”式的黑历史。我自己刚入行那两年，管代码就靠一个U盘和一堆压缩包，项目改上三个月，文件名从 v1.0 进化到 v1.0_final，再到 v1.0_final_真不改了，极限状态能出现 v1.0_final_真的不改了_last。结果某天和同事同时改了同一个文件，合并的时候谁也没通知谁，一下午白干，那种感觉就像手工作坊里唯一的图纸被撕了。后来把 Git 和 Gitee 这套流程吃透，我才意识到代码管理这件事，根本不该靠人肉记忆和文件命名来硬扛。

这篇东西，是我从“文件管理器管理代码”切换到“版本控制系统管理代码”的全过程记录。Git 怎么装、怎么配置，Gitee 上怎么建仓库、怎么配 SSH 密钥免密登录，平时最高频的克隆、提交、推送、分支合并怎么操作，IDEA 和 VS Code 怎么联动，还有一堆新手必踩的高频报错怎么排查，我会一次讲透。基础薄的同学可以照着步骤一步步来，已经上手的人也能把一些“知其然不知其所以然”的原理补补全。

1. 为什么是 Git + Gitee？先告别“手工作坊”思维

1.1 你并不笨，只是还在用“文件夹命名法”管理版本

我见过太多刚开始接触版本控制的同学，第一反应是“我代码量不大，一个人写，用 Git 是不是没必要”。这个想法很真实，但也很危险。你现在的代码量不大，不代表一个月后不大。等到项目变得复杂，你很难记得住三天前改过哪个函数、为什么改、当时是抄的哪份配置。手动备份的文件夹结构通常长这样：

项目-最终版 项目-最终版-改 项目-最终版-改2 新建文件夹 新建文件夹(2)

这种命名法的本质是拿文件名当版本号，拿复制粘贴当备份，拿聊天记录当变更日志。它有两个致命问题：一是没有历史记录，代码改出问题想回退，只能靠记忆翻找“昨天那个好像能跑”的文件夹；二是多人协作时根本无法并线，两个人同时改一个文件，后保存的人直接覆盖前一个人的工作，连提示都没有。

版本控制系统解决的就是这两件事。Git 能记录每一个文件的每一次改动，能随时回到任意一次提交，能让你在分支上放心大胆地试错。它不挑语言、不挑IDE、不挑操作系统，是程序员这一行里最接近“通用基础设施”的东西。

1.2 Git 的三个区和一次提交背后的原理

新手学 Git 最容易卡住的地方，是搞不懂add、commit、push这三个命令到底在干嘛。这里我用游戏存档来打比方。

Git 把所有操作分成三个区域：

• 工作区：你电脑里正在编辑的文件，相当于游戏里正在打的这关，改动还没被记录。
• 暂存区（Index）：你告诉 Git“这些改动我准备记录了”的地方，相当于在存档点按下“记录”前勾选要保存的游戏进度。
• 本地仓库：已经落盘的历史记录，相当于存好的存档文件。commit就是正式生成一个存档，每个存档有编号、有作者、有提交时间、有说明文字。
• 远程仓库：存放在服务器（比如 Gitee）上的完整副本，相当于把存档同步到云端，防止本地硬盘坏了全丢。

日常操作流就是：git add把工作区的改动放进暂存区，git commit把暂存区的内容打成一个存档，git push把本地存档同步到远程仓库。而git pull则是把远程仓库的新存档拉回本地。

理解了这三个区，后面所有命令都不难记。比如git status就是在问“当前有哪些改动还没进暂存区、哪些进了暂存区还没提交”；git diff就是在问“具体是哪些行变了”。这三个区的设计是 Git 的核心，也是它和 SVN 这类集中式版本控制最大的差异点。SVN 的提交和推送是绑在一起的，而 Git 可以攒一批改动分多次提交，每次提交都保持逻辑独立，这样以后git log看历史时会非常清晰。

1.3 Gitee 与 GitHub 怎么选，为什么新手推荐 Gitee

说起代码托管平台，大家首先想到的是 GitHub。但如果你是国内开发者，或者团队主要在国内，Gitee（码云）其实是更顺手的入门选择。

Gitee 的几个优势很实在：访问速度快，不需要额外折腾网络；界面全中文，新手友好；免费用户就能创建私有仓库，代码可以不公开；内置了 Issue、Pull Request、代码评审、文档管理这些团队协作功能；还提供 Gitee Pages，静态博客和个人文档可以直接部署上去。

有人会纠结“GitHub 才是国际主流，我学 Gitee 是不是学偏了”。其实不用担心，Git 本身是跨平台的，Gitee 和 GitHub 用的都是同一套 Git 协议和命令，学会了在 Gitee 上协作，换到 GitHub 只是改一个仓库地址的事。甚至可以用git remote add把同一个仓库同时推到两个平台，做镜像同步。对大多数国内中小团队、课程作业、个人项目来说，Gitee 是稳的选择。

2. Git 安装与环境初始化配置：装好改对，后面才不闹心

2.1 Windows 下载安装要点：版本和那几个勾选框

Git 在 Windows 上推荐直接去官网 git-scm.com 下载安装包。下载的时候注意区分 32 位和 64 位，现在绝大多数电脑是 64 位。下载完双击安装，一路 Next 也能跑起来，但有三个关键节点建议多看两眼。

第一处是选择 PATH 环境变量，有三个选项：

1. Git from the command line and also from 3rd-party software（推荐） 2. Git from the command line only 3. Only show Git Bash

推荐选第一个，这样 Git 会安装到系统 PATH 里，CMD、PowerShell、IDEA、VS Code 都能直接调用git命令。很多人在 IDEA 里报“git 找不到”，就是因为当初选了第三个，IDE 找不到可执行文件。

第二处是换行符转换方式，这也是新手最容易踩的坑。Windows 的换行符是 CRLF（回车+换行），Linux 和 macOS 是 LF（只换行）。如果不同平台的人频繁提交，Git 默认会在检出和提交时自动转换，避免文件因为换行符差异被整体标记为修改。安装时建议选“Checkout as-is, commit as-is”，然后用git config --global core.autocrlf按团队约定统一，这个我在 2.2 里细说。

第三处是 Git Bash 的默认终端模拟器，选默认的 MinTTY 就行，效果和 Linux 终端很像，建议保留。

装完后打开 Git Bash，敲git --version，能看到类似git version 2.40.0.windows.1的输出，就说明装好了。这个版本号不要太旧，如果还是 2.2x 系列，建议升级，新版对 Windows 下的路径处理、性能和多密钥支持都好很多。

2.2 全局身份配置与 CRLF/LF 的坑

Git 每次提交都要记录作者，所以必须先设置全局用户名和邮箱。在 Git Bash 里执行：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

注意两点。第一，这里的邮箱不一定非得是注册 Gitee 的邮箱，但强烈建议保持一致，这样平台能正确地把提交记录关联到你的账号上。第二，--global是当前用户全局生效，如果不同项目要用不同身份，可以去掉--global，在某个仓库目录下单独设置。

下面是换行符问题。Windows 安装 Git 时默认选项通常是Checkout Windows-style, commit Unix-style，也就是本地自动转 CRLF，提交时转为 LF。这个设置在纯 Windows 环境问题不大，但如果项目里有 Linux/macOS 的同事，容易出现两件事：一是git diff显示整个文件的每一行都变了，其实只是换行符不同；二是配置文件在不同系统上行为不一致，引发离奇的运行问题。

我的建议是：如果团队内统一用 Windows，保持默认问题不大；如果跨平台，统一提交为 LF，本地检出也用 LF，在 Windows 上设置git config --global core.autocrlf false或者按项目根目录放一个.gitattributes文件来规范。.gitattributes里的写法大致是：

* text=auto *.sh text eol=lf *.bat text eol=crlf

这样仓库里始终保持统一的行尾风格，跨平台协作会舒服很多。说实话这个坑不到项目出问题很难注意到，但注意一次能省一整晚的排查时间。

2.3 终端工具：Git Bash 还是 Windows Terminal？

Git 装完会附带一个 Git Bash，它是一个模拟 Linux 环境的终端，里面支持pwd、ls、cd、mkdir这些 Unix 命令，对新手来说，这是最接近教程里命令行的环境。缺点是默认窗口样式比较朴素，字体和复制粘贴体验一般。

如果你比较在意终端体验，可以装 Windows Terminal，然后在里面添加 Git Bash 的配置文件。启动 Git Bash 本质就是运行：

C:\Program Files\Git\git-bash.exe

Windows Terminal 里可以把启动命令指定为这个路径，然后就能获得现代终端的外观 + Git Bash 的命令环境。这个组合我现在日常开发一直在用，体验很稳。

还有一点要提醒：CMD 和 PowerShell 也能敲 Git 命令，但命令风格和系统行为略有差异，比如 PowerShell 里ls是另一个实现的别名，格式不同，新手容易困惑。所以入门阶段建议统一用 Git Bash，少踩环境差异的坑。

3. Gitee 准备与 SSH 密钥配置：一次配置，永久免密

3.1 注册、创建仓库与开源许可证怎么选

Gitee 的注册流程不用多说，用手机号或者邮箱就能注册。登录后点击右上角的“+”新建仓库，会看到一个创建表单。

先填仓库名称，可以包含字母、数字、短横线和下划线。下面有两个关键选项：

• 私有/公开：私有仓库只有你和被邀请的成员能看，适合课程作业、公司内部项目、还没做完的个人项目；公开仓库任何人都能看，适合开源项目。新手如果只是练手，建议选私有，后续想转公开随时能改。
• 初始化仓库：可以把“生成 README 文件”、“使用 .gitignore 文件（按语言模板生成）”、“使用开源许可证”三个选项勾上。README 是仓库的门面，写清楚项目是什么、怎么跑；.gitignore 能自动帮你过滤掉target/、node_modules/、.idea/这类不该提交的文件；许可证则是开源项目的法律基础。

有个热词是“Gitee 开源许可证选什么”，这里展开说。许可证的本质是“你授权别人可以用你的代码做什么、要附带什么条件”。常见选择：

如果你只是建私有仓库自己用，完全不用选许可证；公开发布但不想惹麻烦，选 MIT 最省心。

还有一个高频问题：“Gitee 创建的仓库能包含子项目吗？”答案是能。仓库本质上就是一个 git 存储库，一个仓库里可以放多个子项目，就是不同的子目录。但如果你希望子项目独立版本管理、能被其他仓库单独引用，那就得用 Git 的 submodule 机制，命令是git submodule add <url> <path>。新手阶段建议一个仓库对应一个项目，逻辑清晰，省得管理混乱。

3.2 生成 SSH 密钥并配置到 Gitee

现在到了本文几个“真香”节点之一：配置 SSH 免密。如果不配置，你每次git push到 Gitee 都要输入用户名和密码，次数多了真的会烦。

在 Git Bash 里执行：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

一路回车，默认会在C:\Users\你的用户名\.ssh\目录下生成两个文件：id_rsa是私钥，相当于你的数字身份，绝对不要发给任何人；id_rsa.pub是公钥，可以公开，就是要放到 Gitee 上的那把锁。

查看公钥内容：

cat ~/.ssh/id_rsa.pub

复制输出的那串文本，打开 Gitee → 个人头像 → 设置 → 安全设置 → SSH 公钥 → 添加公钥，粘贴进去保存即可。标题可以随便填，比如“我的Windows电脑”。

这里顺便讲一下原理，方便你以后排查问题。SSH 采用非对称加密，你持有私钥，服务器持有公钥。你发起连接时，服务器用公钥加密一个随机挑战发回来，你的私钥能解开，证明“你确实是你”，服务器就不需要密码了。这样密码不会在网络上传输，也比 HTTPS 的账密缓存更安全。

3.3 验证免密与多密钥多账号共存

配置完公钥后，执行：

ssh -T git@gitee.com

如果第一次连接，会提示是否确认连接，输入yes回车。然后看到类似Hi 用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.的输出，就表示 SSH 免密生效了。

以后git clone git@gitee.com:用户名/仓库名.git的时候，就不再需要输入账号密码。

多账号的场景也值得提前知道。比如你可能同时要用公司的 Gitee 和个人 GitHub，两个账号对应两套不同的密钥。可以在~/.ssh/目录下生成第二个密钥：

ssh-keygen -t rsa -b 4096 -C "github邮箱" -f ~/.ssh/id_rsa_github

然后在~/.ssh/目录下新建一个名为config的文件，内容如下：

Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github

SSH 会按 Host 自动选择对应的私钥，这样两个平台的仓库都能免密访问，互不干扰。这个文件我在实际团队里给每个新人都配置过，十来分钟一次配置，后面能少输几千次密码。

4. 日常核心工作流：克隆、提交、推送、分支合并

4.1 克隆远程仓库，以及 fatal: not a git repository

把 Gitee 上的仓库拉到本地，叫克隆。在 Git Bash 中执行：

git clone git@gitee.com:用户名/仓库名.git

执行完后，当前目录下会出现一个以仓库名命名的文件夹，里面是完整的项目文件和.git本地仓库。有一个自带的小细节：.clone 下载的是全部历史记录，所以提交历史越长的仓库，clone 时间越久，这是正常的。

很多新手在某个报错上卡很久：

fatal: not a git repository (or any of the parent directories): .git

这个报错的字面意思是：当前目录不是 Git 仓库，而且父目录里也不是。原因通常就两个：

• 你在一个普通文件夹里直接执行了git commit、git log、git status这类依赖仓库的命令。解决办法很直接：cd进入克隆出来的仓库目录，或者如果真想让当前文件夹被管理，先执行git init。
• 你把.git文件夹误删了。这种情况仓库历史就丢了，只能靠重新克隆或者恢复备份。

组件提示一个安全习惯：如果你的项目是通过 Web 部署的，不要直接把.git目录放进静态站点的发布目录。.git里的信息包含完整历史，一旦被访问到，有泄露源码和敏感信息的风险。在部署发布时，要确保把.git排除出去。

4.2 日常提交推送：add、commit、push 一条龙

修改代码后，要走的流程是“三件套”：

git add . git commit -m "提交说明" git push

git add .把当前目录下所有改动加入暂存区。如果想只加某个文件，用git add 文件名。更精确的做法是git add -p，它可以逐个区块确认是否加入暂存区，适合一次改了多个文件但只想提交其中一部分的场景。

提交说明是很有讲究的。新手常见的问题是把说明写得毫无信息量，比如update、fix、11.20。等你三个月后回来看git log，完全想不起来当时改了什么。我建议至少遵循这个格式：

类型: 简述改动 比如： fix: 修复登录时验证码不刷新问题 feat: 新增导出 Excel 功能 refactor: 重构订单查询逻辑

git log可以看提交历史，git diff可以看当前未提交的具体改动。组合起来就是：git diff先确认改了什么，再决定提交。

关于提交粒度，我的经验是：完成一个逻辑闭环就提交一次，不要憋到晚上一次性把一天的所有改动提交成一个 commit。提交越频繁，回退越精准，也越能保护你的劳动成果。

4.3 分支管理与合并：merge 和 rebase 的区别

分支是 Git 最强大的功能，也是很多新手一开始觉得难的地方。你可以把分支理解成从主线上分出去的平行线，在分支上改代码完全不影响主分支，等测试没问题再合并回主分支。

日常用法：

git branch feature/login # 新建分支 git switch feature/login # 切换到该分支

git switch是 Git 2.23 之后推荐使用的命令，更语义化。旧的git checkout也能切换分支，但因为 checkout 同时承担了“切换分支”和“恢复文件”两个职责，容易混淆，新手建议直接用switch。

合并分支有两种方式：merge和rebase。

merge 的流程是：切回主分支，执行git merge feature/login。它会把分支上的提交和主分支的提交合并成一个新的“合并提交”，历史会形成分叉，但保留了你“什么时候并入哪条支线”的真实记录。

rebase 的流程是：在 feature 分支上执行git rebase master。它的效果是把 feature 分支的提交摘下来，在 master 最新节点上重新播放一遍，最终历史是一条直线，非常干净。但要注意，rebase 会重写提交节点，所以推送出去的公共分支不要随便 rebase，否则会让其他协作者的本地记录和远程记录对不上，那场面会很混乱。

我个人的习惯是：本地开发、功能分支上用 rebase 保持线性历史；多人共享的分支上合并用 merge，保留真实节点。

合并时最容易遇到的状况是冲突。当两个分支改了同一个文件的同一行，Git 无法自动决定用谁，会在文件里插入标记：

<<<<<<< HEAD 主分支的代码 ======= feature 分支的代码 >>>>>>> feature/login

看到这个不要慌。手动保留你要的内容，删掉<<<<<<<、=======、>>>>>>>这些标记，然后：

git add . git commit -m "解决冲突"

冲突解决完成后，合并就成功了。新手解决冲突时最容易犯的错误是：把别人分支的代码一并删了，所以改的时候一定要先确认两边的代码各自是干嘛的，再决定取舍。

4.4 大文件别硬塞：Git LFS 接入与卡住排查

普通 Git 设计出来是为文本文件服务的，它记录的是“这行是什么”。对二进制大文件，比如图片、视频、打包产物，Git 会把整个文件的历史都存起来，仓库体积会迅速膨胀，clone 和推送都会越来越慢。

Git LFS（Large File Storage）解决的是这个问题：它不是把大文件存进仓库，而是把大文件存到 LFS 存储空间里，仓库里只存放一个指针文件。团队 clone 时，默认只拉取轻量的指针，真正需要大文件时才按需下载。

使用流程：

git lfs install git lfs track "*.zip" git lfs track "*.psd"

git lfs track会在项目根目录生成或追加一个.gitattributes文件，内容类似：

*.zip filter=lfs diff=lfs merge=lfs -text *.psd filter=lfs diff=lfs merge=lfs -text

把这个文件也提交进仓库。之后git add、git commit、git push照常执行，大文件会自动走 LFS 通道。

这里有个实际踩过的坑。如果之前设置过lfs.fetchexclude（按类型配置在 clone 时排除某些大文件），后续访问这些文件时可能会一直卡住或缺失。解决办法是取消全局排除配置：

git config --global --unset lfs.fetchexclude

然后回到仓库目录执行：

git lfs pull

就可以补齐缺失的 LFS 文件。另外，如果git lfs clone卡住，优先检查网络、配置和这个排除项。普通 clone 大仓库时也可以手动加参数：git clone后只拉指针，再按需git lfs pull，能显著加快克隆速度。

5. IDEA 和 VS Code 联动：把 Git 塞进日常编辑器

5.1 IntelliJ IDEA 连接 Gitee 远程仓库

IDEA 是 Java 和很多 JVM 系语言开发者的主力 IDE，它对 Git 的集成很完善。第一次使用前，需要在同一个目录设置 Git 可执行文件：File → Settings → Version Control → Git，在 Path to Git executable 里填C:\Program Files\Git\bin\git.exe。设置后点击 Test，能弹出 Git 版本号就表示生效。

从 Gitee 拉取项目到 IDEA 的常见方式：File → New → Project from Version Control → 输入 Gitee 仓库地址（SSH 那种），点 Clone。IDEA 就会把整个仓库拉下来，并自动识别项目结构。

如果你已经有一个本地项目，想直接关联到 Gitee 上的新仓库：本地项目目录执行git init，然后 IDEA 里右键项目 → Git → Add，再设置远程地址：

git remote add origin git@gitee.com:用户名/仓库名.git git push -u origin master/main

-u参数的意思是“记住当前分支上游”，之后直接git push就能推，不用再写分支名。这个-u我每次给新仓库配置时都会用，因为能省很多事。

IDEA 顶部右侧有提交、更新的按钮，改完代码可以直接用图形界面 commit 和 push，非常直观。有一点要注意：IDEA 默认会用内置的 SSH 实现，如果遇到 SSH 认证失败，到 Settings → Version Control → Git 里把 SSH executable 改为 Native，让它直接使用系统 SSH 密钥。

5.2 VS Code 的 Git 集成与 GitLens

VS Code 对 Git 的支持同样很好。左侧的“源代码管理”图标点开，就能看到当前文件的改动列表。修改过的文件在编辑器里会用不同颜色标记行号：红色是新加的行，也就是没保存过的行，这个色彩标记很直接。

VS Code 里从 Gitee 拉取项目：按Ctrl+Shift+P打开命令面板，输入Git: Clone，粘贴仓库地址，选一个本地目录，VS Code 就完成克隆。提交和推送分别对应源代码管理面板顶部的对勾图标和“推送”按钮。

我额外推荐一个插件：GitLens。它能让你在任何一行代码上看到：这行是谁、什么时候、用哪个提交写的，提交说明是什么。做代码评审和排障时，这是个“考古神器”。团队里新成员说“这代码谁写的，看不懂”，用 GitLens 一下就追溯到历史提交和当时的上下文，能省很多口舌。

5.3 命令行与图形界面怎么配合

说实话，图形界面的 Git 操作确实直观，但我不建议完全依赖 GUI。原因有两个：

第一，很多 GUI 把底层行为封装得太干净，你点“同步”时到底是 pull 还是 fetch 还是 rebase，界面不一定解释清楚。一旦出问题，你很难知道自己刚才到底执行了什么操作。第二，面试和工作交流里，命令行描述更精准，比如“我 rebase 之后强推了”，比“我点了右上角那个按钮”专业得多。

我的建议是：掌握 10 个核心命令，其他交给 GUI。这 10 个命令是：clone、status、add、commit、push、pull、branch、switch、merge、log。日常操作用 GUI 加速，遇到分支合并、历史回退、复杂冲突时回到命令行，两者互补，效率和理解都在线。

6. 高频问题排查实录：这些坑我都替你踩过了

6.1 SSH 认证失败三步定位法

Permission denied (publickey)是新手最容易撞上的报错。遇到这个问题，按顺序排查：

第一步，确认 Gitee 上是否添加了公钥。打开你本地的本地公钥cat ~/.ssh/id_rsa.pub，放到 Gitee 后台的 SSH 公钥列表，看是否完全一致。公钥是字符串，复制粘贴时别手滑多了空格。

第二步，确认本地 SSH 是否启动了私钥。某些 Windows 环境 SSH 代理没自动加载，执行：

ssh-add ~/.ssh/id_rsa

如果没有输出Identity added，先执行eval "$(ssh-agent -s)"再运行ssh-add。

第三步，看详细的调试日志，命令加-v：

ssh -T -v git@gitee.com

输出里会显示它尝试了哪些密钥文件、服务器是否接受了认证。如果你的私钥不是默认名称或默认路径，SSH 不会自动识别，需要用 3.3 里写的~/.ssh/config来指定。

顺便提一句，SSH 认证失败时还要确认一个细节：你的 Gitee 用户名是不是git。Gitee 的 SSH 访问地址固定是git@gitee.com:用户名/仓库名.git，前面这个git是协议决定的，不是你的 Gitee 账号昵称，不能用自己用户名替换。

6.2 提交信息写错怎么办？git commit --amend 的用法

写完提交发现说明有错字，或者忘了一个文件，这时git commit --amend就是救心丸。它可以把上一次提交“吃回去”重做。

修改最近一次提交的信息：

git commit --amend -m "正确的提交说明"

上次提交忘了把某个已修改文件纳入：

git add 遗漏的文件 git commit --amend --no-edit

--no-edit的意思是保持原有提交说明不变，只补充文件改动。

这里必须提醒一个使用红线：amend只适用于本地还未推送到远程的提交。如果你的提交已经git push到团队共享的分支，再去 amend，本地历史就和远程不一致了，后续拉取合并会产出一堆奇怪的分叉。如果已经推送且信息确实需要修改，正规做法是再追加一个新提交，写明类似“修正上一次提交的说明”，或者和团队协商后谨慎处理。

6.3 每次 push 都要账密？彻底清除缓存凭据

使用 HTTPS 方式（https://gitee.com/用户名/仓库名.git）clone 仓库时，Git 会把账号密码缓存到 Windows 凭据管理器里。平时免密很方便，但切换账号或改密码后，经常出现“不是我操作的，却一直提交不了”的问题。

排查和清理方法：

• 打开 Windows 控制面板 → 凭据管理器 → Windows 凭据，找到git:https://gitee.com开头的条目，删除。
• 如果想关闭 Git 自己的凭据自动补全，执行：

git config --global --unset credential.helper

如果你是在没配 SSH 密钥的情况下刚刚开始接触 Gitee，之前的操作路径是把密码悄悄补完了，这一步清理后会恢复正常。

我见过的多数“推送不上去”问题，其实就是凭据管理器里存了一个旧账号的密码。清理后重新推送，输入新账号密码即可。当然，如果你已经切换到 SSH 方式，这个麻烦根本不存在，所以新仓库我还是优先建议直接上 SSH。

6.4 新手高频报错速查表

这里整理了一些我实际在群里反反复复看到的问题：

还有一个恢复“误操作”的技巧。如果你执行了git reset --hard，把工作区改动弄没了，不要立刻哭。Git 其实会在操作日志里保存所有 HEAD 的变动，执行：

git reflog

能看到每次 HEAD 的移动记录，找到误操作之前的那条记录，执行git reset --hard 对应编号，就可以把本地状态还原回来。这也是 Git 比手动备份强大的另一个侧面：只要你 commit 过，绝大多数“删错了”“改坏了”都能找回来。

最后分享一点我个人的经验。刚开始学 Git 时，我也觉得命令又多又抽象，甚至一度想退回 U 盘管理方案。撑过两周后，习惯成了肌肉记忆，现在每天打开电脑第一件事就是git status。你不需要把 Git 的所有高级技巧都学完，只需要把克隆、提交、推送、分支合并这四个动作做熟练，就已经比 90% 的“文件夹版本管理器”强了。如果你现在正踩在某个报错上，按上面 6.4 的速查表试一遍，大概率就能走出来。代码管理这件事，越早告别手工作坊，后面省下的时间就越多。