企业官网建设流程全解析

最近后台收到不少朋友私信，都在问 Git 下载安装的事情。问得最多的几个问题是：官网下载链接到底是哪一个、安装向导里一大堆选项该怎么选、装完之后是不是就能直接用了、怎么配置才能免密推送代码到 Gitee 或者 GitHub。这些问题对老手来说可能不算什么，但刚接触版本控制的新手，光一个安装向导就能卡住半天。我干脆把从下载、安装、配置到常见问题排查的完整流程整理出来，一步步带你装好 Git 并把基本流程跑通。这篇文章不只讲“怎么点下一步”，还会把每个选项背后的逻辑讲清楚，让你装完心里有底，而不是稀里糊涂一路回车。不管你是学生、前端后端开发者，还是准备开始用 Git 管理代码的爱好者，这篇保姆级教程都适合你。

1. 搞清楚 Git 到底是什么，再动手不迟

1.1 一分钟理解 Git 的核心概念

Git 是一个分布式版本控制系统，它的核心作用就是“记录每一次改动”，并且让你能在任意时间点回退到之前的任意版本。你可以把它理解为游戏里的存档机制——打 boss 之前存个档，打挂了读档重来。写代码比打游戏更需要这种能力，因为代码改坏了、功能写崩了、需求说不要了，都是家常便饭。

Git 有几个关键概念需要先建立印象：工作区、暂存区、本地仓库、远程仓库。我用做饭来类比，你切菜备料的台面就是工作区，菜切好放在配料盘里就是暂存区，冰箱冷藏就是本地仓库，而朋友家的冰箱就是远程仓库。你在台面上干活，干完一部分把菜装到配料盘（git add），然后把配料盘放进自己冰箱（git commit），最后再把冰箱里的菜分享给朋友（git push）。远程仓库就是像 Gitee 或 GitHub 这样的代码托管平台，相当于别人帮你保管一份“冰箱”的副本，方便协作和备份。

弄懂这四层关系之后，后面所有命令的逻辑就顺了。很多人学 Git 觉得难，就是因为这四个概念混淆，不知道一条命令到底作用在哪一层。后面我讲命令的时候，也会反复对照这四层来讲，帮你把印象扎牢。

1.2 你需要 Git 吗：适用的场景与学习收益

很多人觉得 Git 是程序员才需要的东西，这个想法其实过时了。现在 Git 的应用场景远比你想的广：

• 写代码的人，不管是个人项目还是公司团队协作，Git 是国内外开发岗位的基础技能，简历写“熟悉 Git”几乎是标配。
• 写文档、写论文、做方案的人，用 Git 管理版本比“新建副本、最终版、最终版2、最终改死版”这种文件名后缀法高效得多，每次改动都有记录，随时可以回到任意历史版本。
• 做自媒体、做设计稿、管理配置文件的，Git 也能帮忙记录版本变化和协作修改。

如果你是开发者或者正在学编程，Git 是绕不开的。尤其是当你开始使用 Gitee 或 GitHub 时，拉取开源项目、提交 Issue、参与开源贡献、部署个人博客，哪一个环节都会用到 Git 命令。而 Git 的下载安装是第一关，这一关走顺了，后面的学习曲线就会平缓很多。

现在网上关于 Git 的教程非常多，但很多时候新手遇到的问题恰恰卡在最开始的环境安装配置上。代码跑不起来，先检查 Git 装没装好、配置对不对，这是很多场景的第一步。所以我先花大篇幅把安装和初始配置讲透，这是性价比最高的一环。

2. Windows 平台 Git 下载安装全过程

2.1 官方下载渠道与版本选择

安装 Git 第一步是下载安装包，这一步就有不少人栽跟头。搜索“Git 下载”会出来一堆第三方下载站，看起来界面很友好，但下载速度和安全性都没保障，有的还可能捆绑额外软件。我的建议是直接认准官网，Git 官方下载地址是 git-scm.com，打开页面后点击 Downloads 就能看到对应系统的安装包。

Windows 用户下载时有一个细节要注意：官网首页会自动检测你的操作系统位数，但保险起见，你自己也要确认一下电脑是 64 位还是 32 位。现在绝大多数电脑都是 64 位，选择 64-bit Git for Windows Setup 那个版本就行。如果你不确定，右键点击“此电脑”选“属性”，就能看到系统类型。

这里插一句其他系统的情况：macOS 用户最方便的方式是装 Homebrew 后执行 brew install git，或者直接去官网下载 macOS 版安装包；Linux 用户一般用发行版的包管理器，Ubuntu/Debian 是 sudo apt install git，CentOS/RHEL 是 sudo yum install git。这篇文章后面的配置和命令在所有平台都是一样的，所以如果你不是 Windows 也能照常参考。

还有一个关键点：下载时认准最新稳定版，不要追求测试版或者 Preview 版本。Git 的版本更新比较频繁，但大多数功能变化对普通用户来说感知不强，最新稳定版就是最省心的选择。下载得到的是一个 exe 安装文件，一般只有几十 MB。

2.2 安装向导的关键选项逐个过

拿到安装包之后，双击开始安装。安装向导基本都是英文界面，不少人看到英文就紧张，其实完全没必要——大多数界面直接点 Next 就行，只有五个选项需要你认真看一眼。我挨个说。

第一项是许可协议界面。这个界面除了 Next 没什么好操作的，直接点 Next 继续。

第二项是选择安装路径。这里有一个硬性建议：安装路径不要包含中文和空格。很多软件在中文路径下会出现莫名其妙的编码问题，Git 尤其明显。建议直接用默认路径 C:\Program Files\Git，或者改成 D:\Git 这种纯英文路径，省心。

第三项是选择组件。一般保持默认全选就行，但有两个复选框要留意。一个是“Git Bash Here”和“Git GUI Here”的右键菜单选项，默认就是勾选状态，千万别取消，因为装上之后你在文件夹里右键就能直接打开 Git Bash，这是使用 Git 最顺手的入口。另一个是“Add a Git Bash Profile to Windows Terminal”，如果你用 Windows Terminal，建议也勾上，方便直接在终端里切换到 Git Bash。

第四项是选择开始菜单文件夹，默认即可，不用改。

第五项就是重点中的重点了：选择默认编辑器。默认选的是 Vim，但 Vim 的操作对新手来说实在太劝退——你第一次执行 commit 可能就卡在 Vim 里不知道怎么保存退出。我强烈建议：如果你装了 VS Code，直接选 “Use Visual Studio Code as Git's default editor”；如果你更习惯 Notepad++，也可以选 Notepad++。如果这些编辑器都没装，就先用默认的 Vim 凑合，但我建议你顺手装一个 VS Code，后面编辑提交信息、解决冲突都方便得多。

接下来这个选项也特别关键：Adjusting your PATH environment。这里给出三个选择：

• 第一个是“仅从 Git Bash 使用 Git”，选这个的话，在 cmd 和 PowerShell 里敲 git 会提示找不到命令，不建议。
• 第二个是“从命令行以及第三方软件中使用 Git”，这个最推荐，它会把 Git 加入系统 PATH，让你在 cmd、PowerShell、VS Code 终端里都能直接用 git 命令。
• 第三个是“从命令提示符中使用 Git 和可选的 Unix 工具”，它会把一些 Unix 命令也带进 Windows，有极小概率和系统命令冲突，普通用户没必要选。

选第二个，这是最平衡、最稳妥的选择。

再往下是 HTTPS 传输后端，默认选第一个“使用 OpenSSL 库”，这个不用动，SSL 证书校验都靠它处理。

然后是行尾转换方式 Line ending conversions，这是新手最容易忽略但影响巨大的选项。Windows 和 Linux/macOS 对换行符的处理不一样，Windows 用 CRLF，Unix 用 LF。默认选项是“检出 Windows 风格，提交 Unix 风格”，这是跨平台协作最稳妥的方案，Git 会自动在检出时转成 CRLF、提交时转成 LF，团队里不同系统的人协作也不容易乱。除非你是单人纯 Windows 环境且明确知道自己要什么，否则保持默认。

再往下是终端模拟器，默认选 MinTTY 即可，它比 Windows 自带的控制台好用得多，支持的颜色和中文字符也更好。然后是 git pull 的默认行为，选默认即可。最后是凭据管理器，选择 Git Credential Manager，这样你在用 HTTPS 协议推送代码时，第一次输入账号密码会被安全保存，后面不用反复输入，很方便。后面所有提示“启用实验性支持”的选项都不要勾选，那些功能还不稳定，普通用户不需要。

2.3 安装完成的验证方式

安装过程大概一两分钟就结束，完成后桌面可能不会自动生成图标，这不代表没装好。打开任意文件夹，在空白处右键，菜单里应该出现 “Git Bash Here” 和 “Git GUI Here” 两项，看到这两个选项就说明安装基本成功了。

接着打开 Git Bash，输入 git --version，回车，如果输出类似 git version 2.44.0.windows.1 的内容，就说明 Git 已经正常可用了。再输入 git --help，你会看到一堆 Git 常用命令的列表，能出这个界面，环境配置这一关就算真正过了。

我还建议同时验证一下 cmd 里能不能用 git。按 Win+R，输入 cmd 回车，在命令行里输入 git --version，如果也能显示版本号，说明 PATH 配置正确，后面你用 VS Code 终端、PowerShell 等各种终端都能顺畅执行 git 命令。这个验证很值得做，不然等你用 VS Code 的时候才发现终端里敲不了 git，又要回头排查 PATH，平白浪费时间。

3. 安装后的第一件事：初始化配置

3.1 设置用户名和邮箱的原理与操作

很多人装完 Git 就直接开始 clone 代码，结果第一次 commit 就报错，提示需要配置 user.name 和 user.email。这是因为 Git 的每个提交记录都必须带上提交者的身份信息，相当于每次改动都要盖上一个人的章，没有章它就不让你提交。

设置方式很简单，在 Git Bash 里执行下面两条命令：

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

user.name 不一定要用真实姓名，但建议能让人看出是你；user.email 建议填你注册 Gitee 或 GitHub 时用的邮箱，这样推送代码后平台能正确地把提交记录对应到你的账号上。

这里有一个很重要也很常见的认知误区：user.email 和平台账号的关联，靠的是邮箱匹配，不是用户名匹配。比如你在 GitHub 上注册的邮箱是 a@example.com，但在 Git 里配置的邮箱是 b@example.com，那么你的提交在 GitHub 上就不会归到你名下，会显示成一个独立的未知头像。所以邮箱一定要和托管平台的邮箱保持一致。

关于 --global 参数的解释：它的意思是“全局生效”，也就是说这台电脑上所有仓库都默认用这个身份。如果你不想全局生效，只想针对某个特定仓库设置不同身份，就到那个仓库目录下执行同样的命令，但去掉 --global，这样就是仓库级别的配置。这个功能实用性很强，比如我有公司的 GitLab 账号，也有私人的 Gitee 账号，公司仓库单独设置仓库级配置，私人项目走全局配置，互不干扰。

3.2 检查配置是否生效

配置完以后，建议立刻验证一下，避免后面提交时才发现问题。在 Git Bash 里执行：

git config --global --list

这个命令会列出所有全局配置项，你就能看到 user.name 和 user.email 是否已经写入。如果只想查看某一个配置项，可以这样：

git config user.name git config user.email

这些配置内容实际上写在你的用户目录下的一个文本文件里。Windows 上路径一般是 C:\Users\你的用户名.gitconfig，Linux/macOS 是 ~/.gitconfig。你直接用文本编辑器打开这个文件也能看到完整的配置内容，格式类似：

[user] name = 你的名字 email = 你的邮箱

知道配置文件在哪，对后续排查问题很有帮助。比如有时候你在一个仓库里执行 git config --list，发现 user.name 不对，那就是仓库级配置和全局配置冲突了，你直接检查仓库目录下的 .git\config 文件就能找到问题。记住：仓库级配置的优先级高于全局配置，这是 Git 的覆盖规则。

除了身份信息，我建议在一开始就顺手把默认分支名改成 main。前些年 Git 的默认分支叫 master，现在业界逐渐迁移到 main。虽然这不算必须，但如果你新建的仓库默认分支是 master，推送到 Gitee 时平台默认分支是 main，两边会有细微的差异，新手容易困惑。执行下面这条命令即可：

git config --global init.defaultbranch main

另外还有两个实用的全局配置可以顺手加上。第一个是别名配置，Git 支持给命令起别名，比如 git st 代替 git status、git ci 代替 git commit，操作起来效率高了不少。第二个是开启彩色输出，让命令结果更易读。这些都可以通过编辑 .gitconfig 文件来实现，以下是一个比较推荐的初始配置：

[user] name = 你的名字 email = 你的邮箱 [init] defaultBranch = main [color] ui = auto [alias] st = status co = checkout ci = commit br = branch

把上面的内容保存到 .gitconfig 文件后，执行 git config --global --list 就能看到对应的配置项生效。配置在这一步弄好，后面用起来会顺手很多。

4. 新手最容易上手的 Git 日常命令

4.1 提交代码的完整流程

配置完环境信息，接下来要真正把 Git 用起来。我讲一条最核心的日常开发流程，如果你只记一条链路，就是这一条：init → add → commit → remote → push → pull。

第一步，进入你要管理的项目目录，在 Git Bash 里执行：

cd /d/项目路径 git init

git init 的作用是把当前文件夹变成一个 Git 仓库。执行后目录下会出现一个隐藏的 .git 文件夹，这就是 Git 用来记录版本信息的数据库。注意：这个命令只在第一次开始时执行一次，不需要每次都用。

第二步，创建或者修改文件后，查看仓库状态：

git status

这个命令会告诉你哪些文件被修改了、哪些文件还没有被 Git 跟踪。新手最应该养成的习惯就是经常敲 git status，它让你随时知道项目处于什么状态，避免“明明改了代码为什么提交不了”的困惑。

第三步，把改动加入暂存区：

git add 文件名 # 或者一次性添加所有改动 git add .

git add 就是把当前工作区的改动添加到暂存区，也就是我在开头说的“菜切好放到配料盘”。只有被 add 过的文件，才会被下一步 commit 记录到版本历史中。很多人第一次提交后发现某些文件没有被包含进去，多半就是漏了 git add。

第四步，把暂存区的内容提交到本地仓库：

git commit -m "提交说明"

-m 后面的引号里写的是这次提交的说明，建议写清楚“这次改了什么”。好一点的提交信息比如“修复登录页在手机端显示错位的问题”，而不是“修改bug”。如果执行 git commit 时不加 -m，Git 会打开默认编辑器让你写提交信息，这也是我前面强调要设置编辑器的重要原因——如果在 Vim 里不会退出，就会卡在提交页面出不来。

第五步，把本地仓库和远程仓库关联起来。你需要在 Gitee 或 GitHub 上先创建一个空仓库，然后把远程地址关联到本地：

git remote add origin 仓库地址

这里的 origin 是远程仓库的默认名字，可以理解成一个“远程仓库的别名”，后面 push、pull 都用这个名字来指代。关联之后，第一次推送需要设置上游分支：

git push -u origin main

-u 参数的作用是把本地的 main 分支和远程的 main 分支关联起来，以后再执行 git push 就不用带参数了。

第六步，日常拉取远程的最新代码：

git pull

git pull 的作用是把远程仓库其他人提交的内容拉取到本地。在团队协作中，每次开始工作前先 pull 一次，能有效减少代码冲突。在多人项目里，push 之前也最好先 pull 一下，把最新的代码合并到本地再推送，这是避免冲突的黄金法则。

4.2 修改提交信息的技巧

使用 Git 的时候，几乎所有人都会遇到一个场景：commit 之后才发现提交信息写错了，或者漏了一个文件。这时候就要用到 git commit --amend 命令。

git commit --amend 的作用是修改最近一次提交。如果你只是提交说明写错了，想改一下文字，执行：

git commit --amend -m "新的提交说明"

这条命令会用一个新的提交覆盖最近一次提交。注意，它的原理不是“删除旧提交再追加一个”，而是把最近的提交替换成一个新的提交对象，提交的 hash 会改变。

如果你是漏了文件没提交，先用 git add 把漏掉的文件加入暂存区，再执行：

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

--no-edit 表示保持原来的提交说明不变，只补充文件到上一次提交里。执行完之后，git log 里看不到两条提交记录，只有一条包含完整内容的提交，非常干净。

不过这里有一个非常重要的注意事项：--amend 会改写提交历史，所以它只适用于“修改还没有推送到远程的提交”。如果你已经 git push 了，再对这次提交执行 amend，本地历史就和远程不一致了，后续需要强制推送 git push --force 才能同步，而强制推送在同团队协作时是很危险的操作，可能把队友的提交覆盖掉。最常见的场景是：自己刚在本地 commit，还没有 push 时发现写错了，这时候用 amend 是最合适的。

再补一个相关的高频命令：git diff。当你修改了文件但还没 add 时，执行 git diff 可以看到具体改动了哪些内容；如果你已经 add 了，想看暂存区和本地仓库之间的差异，用 git diff --cached。很多新手不看 diff 就直接 commit，提交完了才发现把调试代码也提交上去了，回头再改就很麻烦。建议 commit 之前先 diff 一遍，确认无问题再提交。

5. 配置 Gitee/GitHub SSH 密钥，免密推送

5.1 为什么要用 SSH 协议

Git 连接远程仓库有两种主要协议：HTTPS 和 SSH。HTTPS 协议每次 push 都需要输入用户名和密码（或者个人访问令牌），虽然 Git Credential Manager 能记住凭据，但仍有输错、过期的问题。SSH 协议则不同，一旦配置好密钥，后续 push、pull 都不需要再输任何账号密码，体验顺畅得多。

SSH 认证的原理是“一对密钥”：私钥留在你本地电脑上，公钥放到代码托管平台上。当你推送代码时，平台用公钥验证你的身份，而私钥永远不会离开你的电脑，安全性有保障。这就好比钥匙配锁芯，私钥是钥匙，公钥是锁芯的模具。

我还要提醒一下：用 Gitee 进行 HTTPS 推送时，现在很多场景不支持直接用账号密码，而是要求用“私人令牌”作为密码输入，这对新手来说又是一个容易卡住的地方。提前配置好 SSH 密钥，这些麻烦就都绕开了。

5.2 生成 SSH 密钥的完整步骤

生成 SSH 密钥其实不需要安装额外工具，Git Bash 自带 ssh-keygen 命令。打开 Git Bash 执行：

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

参数解释：-t rsa 指定生成 RSA 类型的密钥，这是最通用、兼容性最好的类型；-b 4096 指定密钥长度，4096 位是目前推荐的安全长度；-C 后面跟着的是注释，一般填邮箱，仅仅是用来标记这个密钥用途的，不会影响实际功能。

执行后，终端会提示你选择密钥保存的位置，默认是 /c/Users/你的用户名/.ssh/id_rsa，直接按回车使用默认路径即可。接下来会提示输入 passphrase（口令），这里可以直接按回车跳过，或者设置一个口令。设置了口令的话，每次使用私钥时都会要求输入口令，安全系数更高，但也更麻烦。我自己的习惯是个人电脑不设口令，方便日常操作；如果你办公电脑是公用或容易被他人接触的，建议设一个。

生成完成后，进入 .ssh 目录查看文件：

cd ~/.ssh ls

你应该能看到两个文件：id_rsa 是私钥，id_rsa.pub 是公钥。记住：私钥千万不能泄露、不能发给任何人、不能上传到任何平台，公钥则是要交给平台的那一半。

5.3 把公钥添加到 Gitee / GitHub

查看公钥内容：

cat ~/.ssh/id_rsa.pub

终端会输出一串以 ssh-rsa 开头的长文本，从开头到结尾全部选中并复制。注意要完整复制，不要漏掉结尾的邮箱部分。

然后打开 Gitee，登录后点击右上角头像，选择“设置”，在左侧菜单找到“安全设置”下的“SSH公钥”，把刚才复制的内容粘贴到大文本框中，标题可以随意填，比如“我的电脑”，最后点击确定。GitHub 的操作路径类似：进入 Settings → SSH and GPG keys → New SSH key，粘贴保存。

添加完之后，检查配置是否生效。在 Git Bash 里执行：

ssh -T git@gitee.com

如果你是配置的 GitHub，则执行：

ssh -T git@github.com

第一次连接会提示确认主机指纹，输入 yes 回车即可。如果看到类似“成功认证”的提示，就说明 SSH 配置已经生效。之后你在 clone 远程仓库的时候，选择 SSH 格式的地址来克隆，后续 push 就完全不需要再输入账号密码了。这是提升日常操作体验最明显的一步，建议每个用 Git 的人都配置上。

6. 常见问题与排查技巧实录

6.1 安装和配置阶段的典型问题

我在文章里多次提到，安装阶段最容易出问题的就是 PATH 配置。下面这张表整理了新手高频问题，后面排查时可以对照查看：

这一部分着重提醒两点。第一，安装 Git 之前最好把正在运行的其他软件关掉，尤其是杀毒软件和安全卫士之类的工具，它们有时会拦截 Git 写入系统 PATH 的操作，导致安装完 git 命令不可用。第二，如果你安装时 PATH 选项选错了，两个解决思路：重装一次选对选项；或者去系统环境变量里手动添加 Git 的安装路径下的 cmd 目录，例如 C:\Program Files\Git\cmd。第一种方式更省心，我直接建议重装。

6.2 使用阶段的高频报错

安装和基础配置过关之后，使用阶段还有几个报错出现频率非常高，这里一并整理了。

第一个是 clone 或 push 时报 “fatal: unable to access”，后面跟着类似 “Could not resolve host” 或者连接超时的提示。这个问题一般是网络原因，可能是网络波动、代理设置冲突或者 DNS 解析失败。排查思路是：先试试其他网站能不能正常访问；如果用了代理工具，检查一下 Git 里是否配置了代理，执行 git config --global --list 查看有没有 http.proxy 或 https.proxy 配置；之前有全局代理配置的话，用 git config --global --unset http.proxy 和 git config --global --unset https.proxy 去掉。

第二个是执行 git push 时报 “Permission denied (publickey)”。这是 SSH 密钥配置有问题的典型报错，排查步骤依次是：确认本地是否有私钥文件 id_rsa；确认公钥是否完整添加到了 Gitee/GitHub 上；确认你使用的远程仓库地址是 SSH 格式而不是 HTTPS 格式。执行 ssh -T git@gitee.com 测试能快速定位问题到底是在本地还是远程。

第三个是 push 时报 “src refspec main does not match any”。这个报错的意思是本地还没有匹配的提交记录，也就是说你还没有执行过 git commit，直接想 push 了。解决方式很简单：先 git status 查看是否有文件被跟踪，再 git add . 和 git commit -m "init" 提交一次，然后重新 push。

第四个高频问题也是很多人踩坑的地方：执行 push 的时候遇到冲突，提示类似 “Updates were rejected because the remote contains work that you do not have locally”。这句报错说的是远程仓库有你本地没有的提交，Git 拒绝让你的推送覆盖远程内容。这时候不要强行 push，正确的做法是先 git pull 把远程内容拉下来合并，解决完可能的冲突后再 push。这也是团队协作中最基本的同步流程。

第五个与热词相关：git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks 这条命令。它通常出现在一些图形化 Git 工具的后台调用里。这条命令的作用是：关闭差异对比时的 mnemonic 前缀功能、关闭非 ASCII 文件名的转义显示，以及禁止 Git 在操作期间获取可选的锁。普通用户不需要手动输入这类命令，但如果你在日志里看到它，至少要能理解它在做什么。

额外分享一个我在实际教学中不断强调的心得：遇到 Git 报错，先读报错原文，再搜索。Git 的报错信息其实已经非常直白了，大部分人就是因为没逐字看英文提示，才导致问题迟迟无法定位。打开一个有中文解释的搜索引擎，把报错第一行原样粘进去，往往第一个结果就能解决问题。Git 的错误提示本身就在指引你——关键是你要先看一眼它说什么。

关于代码冲突，最后多说一句。很多新手第一次遇到冲突都慌，但其实冲突解决就是在文件里找特殊标记的冲突块。冲突区块会以 <<<<<<<、=======、>>>>>>> 分隔出两个版本的差异内容，你只需要保留想要的那部分、删除不想要的，保存文件后再执行 git add 和 git commit 就算解决了。第一次遇到冲突别紧张，这其实是 Git 帮你守住代码安全的表现。

回到安装这个话题，我再补充一个小技巧：如果你是新手，先别急着在自己正在开发的项目里折腾 Git。可以先新建一个 test 文件夹，在里面随便放几个文本文件，用 git init、add、commit、push 整个流程多跑几遍。这样做的好处是，你能在一个完全安全的环境里把所有命令玩明白，就算弄坏了也无所谓。我见过太多人一上来就在真实项目里操作，一次误操作吓得再也不敢用 Git。先在测试仓库里把命令熟悉透，再对真实项目下手，心理负担会小很多，学习效率反而更高。

踩过几次坑之后，我自己已经形成了一套固定的安装配置流程，整套下来基本不会再遇到环境问题。下载装好、PATH 选对、FET 编辑器选好、身份信息配置好、SSH 密钥配上，这五步走完，你的 Git 才算是真正准备好干活了。