企业官网建设流程全解析

干这行越久，越发现一个扎心的事实：很多写了几年代码的同事，Git 用得依然是“三板斧”——clone、add、commit、push，遇到冲突要么乱改一通，要么喊人帮忙。Git 不是背命令的考试，它是你每天吃饭的筷子。用不好 Git，浪费的不是时间，是你的耐心和信任。

我打算用一整篇的篇幅，把 Git 从安装、配置到原理、进阶、排错，完完整整捋一遍。这不是官方文档的翻译，是我自己这些年踩坑踩出来的实战总结。不管你是刚入门的新手，还是用了一段时间但总觉得“差点意思”的开发者，这篇内容都值得你花半小时看完。看完你会发现，Git 原来没那么玄乎，理解了它的设计逻辑之后，很多命令根本不用死记硬背。

1. Git 到底是什么，以及它凭什么能“救你的命”

先聊一个最根本的问题：Git 解决的是什么痛点？

想象一下没有版本管理的日子——你写了一个文件，改了几版之后，文件名变成了论文_最终版_v3_不要再改了.docx。过两天你又改了一版，发现改坏了，想回退，结果发现最终版_v3已经是改坏之后的版本了，你再也找不到之前那个能跑通的状态。程序员的版本管理要是也这么干，那项目部早就炸了。

Git 就是干这个的：它把你每次的改动记录成一个“快照”，你可以在任意时间点穿梭、对比、回退、合并。它不是简单地存几个备份文件，而是通过一套精密的存储模型，让你能够像操作时间线一样操作代码。

1.1 分布式和集中式到底差在哪

你肯定听说过 Git 是“分布式版本控制系统”，跟 SVN 这种“集中式”不一样。这话听着专业，但很多人其实没真正理解。

集中式（比如 SVN）：所有代码存在中央服务器上，每个人从服务器拉最新代码，改完再提交上去，所有人都围绕一个中心点转。这有个致命问题：服务器挂了，或者网络不通，你没法提交代码，历史记录也查不了。

分布式（比如 Git）：每个人的本地都是一个完整的仓库，包含所有历史记录、所有分支。你可以离线提交、离线查看历史、离线创建分支，一切操作都在本地完成。之后你选择什么时候把本地的提交推送到远程，什么时候从远程拉取别人新增的提交。这就是“分布式”三个字的真正分量——你的电脑不只是个工作副本，它本身就是仓库。

这也带来了一个直接的体验差异：Git 的操作速度飞快。因为大部分操作（提交、查看历史、切分支）都在本地完成，不用经过网络，git log这种命令基本上是毫秒级响应。用惯了 Git 再用回 SVN，你会觉得每一步都在等服务器响应，极其难受。

1.2 Git 是 Linus 的“三天之作”，但设计极精妙

Git 的诞生背景也值得一提，知道这段历史能帮你理解它为什么长这样。Linux 内核是世界上最庞大的开源项目之一，维护者 Linus Torvalds 当年用的 BitKeeper 因为许可问题不让他们用了，Linus 一怒之下自己写了一个版本控制系统，据说两天还是三天就写出了第一个可用版本。这套系统设计的核心诉求就是：高性能、分布式、能支撑 Linux 内核这种超大型项目的日常协作。

所以你如果觉得 Git 的命令设计得反直觉、缩写诡异、概念抽象，别怀疑自己——它本来就是个“天才给自己写的趁手工具”，后来才被推广成全民工具。这也解释了为什么网上有大量 Git 疑难杂症的帖子，因为它的学习曲线确实有一定高度。但一旦你理解了它背后的对象模型和数据流，一切都豁然开朗。

2. 从零开始：安装、配置与“小乌龟”实战

别嫌这步简单，我见过太多人卡在“装不上”“配不好”的阶段。这节我把 Windows、macOS、Linux 三种系统的安装和初始化配置都过一遍，顺便聊聊 Git 自带 GUI 和 TortoiseGit（小乌龟）的选择问题。

2.1 Windows 安装：下载、选项、环境变量一次说清

Windows 下安装 Git 最标准的做法是去 Git 官网下载 Git for Windows。如果官网访问慢，国内也有不少镜像站提供同版本安装包，具体版本号以你下载时为准。下载下来是.exe文件，双击运行。

安装过程中的选项目比较关键，我逐个说：

• Select Components：如果你以后可能要在 Bash 里写 Linux 风格脚本，建议勾选“Git Bash Here”和“Git GUI Here”，这样右键菜单会多出入口按钮，使用非常方便。
• Default editor：默认是 Vim，劝新手别硬刚 Vim，建议选 Notepad++ 或者 VS Code，不然你第一次写 commit message 时，会被困在 Vim 里不知道怎么退出（按:wq可以保存退出，但新手真不一定知道）。
• Adjusting your PATH：强烈建议选第一项 “Git from the command line and also from 3rd-party software”。如果这里选错了，你之后在 PowerShell、CMD 里敲git会直接报错，比如最常见的那个报错——git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

如果你已经装完，发现命令行里git用不了，多半就是 PATH 没有配置好。解决办法：手动把 Git 的安装目录下的cmd文件夹路径（常见的是C:\Program Files\Git\cmd）加到系统环境变量的Path里，然后重开一个终端窗口。

• Line Ending Conversions：这步是很多新手困惑的重灾区。Windows 用 CRLF 换行，Linux/macOS 用 LF 换行。如果团队有人用 Windows、有人用 macOS，换行符不一致就会导致明明只改了一行，Git 却显示整文件都被改了。我推荐选 “Checkout as-is, commit as-is” 或者 “Checkout Windows-style, commit Unix-style”，前者是让 Git 保持文件原样，后者是 checkout 时转成 Windows 换行，commit 时转成 LF。具体根据团队协作情况定，但一定要统一规则，否则后面全是坑。这个我在后面“常见问题”里还会专门展开。

安装完成后，打开 Git Bash 或者 CMD，输入：

git --version

看到版本号输出，就说明装好了。

2.2 macOS 和 Linux 安装

macOS 上，装 Xcode Command Line Tools 的时候会带上 Git。但你如果想要更新的版本，建议通过 Homebrew 安装：

brew install git

Linux 直接用系统包管理器：

# Debian/Ubuntu sudo apt update && sudo apt install git # CentOS/RHEL sudo yum install git

不管哪个系统，装完之后都建议先看一眼版本，确保装的是新版，旧版本部分命令行为会有差异。

2.3 必做的全局配置：身份、换行符、别名

装好 Git 之后，第一件要紧事是配置你的身份信息。没有它，你根本没法提交——提交时 Git 会强制要求知道“谁”在提交：

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

这里有个细节：这个邮箱不要求一定是真实邮箱，但建议用你注册 GitHub/Gitee 的邮箱，这样提交记录能正确关联到你的账号上。不少人随手填了个123456@qq.com，后面统计贡献度时发现全是“无名氏”，追悔莫及。

然后是换行符的全局配置，Windows 下可以执行：

git config --global core.autocrlf true

macOS/Linux 下执行：

git config --global core.autocrlf input

core.autocrlf true表示提交时自动把 CRLF 转成 LF，检出时把 LF 转成 CRLF。input表示提交时转 LF，检出时不转。这组配置能极大减少跨平台协作时换行符带来的 diff 噪音。

再配两个别名，能省不少事：

git config --global alias.st status git config --global alias.lg "log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit"

以后你就可以用git st看状态，用git lg看漂亮的提交记录图。

2.4 配置 SSH 密钥：Gitee 和 GitHub 的免密通行证

每次 push 都输账号密码，表面上是安全，实际是浪费生命。我建议配置 SSH 密钥，一劳永逸。

生成密钥的命令：

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

一路回车就行，默认会生成在~/.ssh/id_rsa.pub。然后查看公钥内容：

cat ~/.ssh/id_rsa.pub

复制输出的内容，到 Gitee 的“设置—SSH公钥”或者 GitHub 的“Settings—SSH and GPG keys”里粘贴保存。之后克隆仓库时用 SSH 地址（git@github.com:用户名/仓库名.git或git@gitee.com:用户名/仓库名.git），就不再需要输密码了。

我遇到过一种情况：密钥配置好了，但连接时提示Permission denied (publickey)。排查思路一般是：先确认ssh-agent是否运行，密钥是否加载：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa

如果还是不行，检查你是不是用了自定义文件名的密钥。如果密钥文件名不是默认的id_rsa，还需要在~/.ssh/config里配置IdentityFile路径。这些都是细节，第一次配好后面能省心很多年。

2.5 TortoiseGit（小乌龟）到底要不要装

“小乌龟”是 Windows 上最经典的 Git 图形客户端，它的标志性优势是集成到资源管理器右键菜单里，你无需打开命令行，在文件夹里右键就能完成提交、更新、查看日志等操作。

• 安装小乌龟略繁琐：先装 TortoiseGit 本体，再装一个语言包，还得在设置里改成中文。安装时它会自动探测你电脑上的 Git 安装路径，如果找不到，就得手动指定。
• 日常用法：图标叠加（文件有修改时显示红色感叹号）、右键提交、右键更新（pull）、右键显示日志（show log）——对不习惯命令行的朋友确实很友好。

我的建议分场景：如果你只是偶尔提交代码、改改文件，小乌龟够用了；如果你每天大量操作 Git，跟分支、改冲突、处理复杂情况，命令行依然是效率最高的方式，图形界面反而会限制你理解 Git 真正发生了什么。

3. 核心原理：三个区域、对象模型，以及 Git “快”的秘密

从这节开始，你学到的将不是“怎么敲命令”，而是“命令为什么是这样设计的”。理解了原理之后，你会发现自己对 Git 的恐惧感消失了，很多问题不再需要百度。

3.1 工作区、暂存区、版本库和远程仓库的关系

用一张图在脑子里构建 Git 的存储模型。理解以下四个概念，就掌握了 60% 的 Git：

• 工作区（Working Directory）：就是你在电脑里能看到的那些文件和文件夹，你天天编辑的就是这里。
• 暂存区（Index / Staging Area）：一个隐藏的区域，你运行git add后，文件的“准备提交”版本会被放到这里。它是工作区与版本库之间的缓冲区。
• 本地版本库（Local Repository）：在你项目根目录的.git文件夹里，保存着你所有的提交历史和对象数据。
• 远程仓库（Remote Repository）：就是 GitHub、Gitee 或者你自己服务器上的那份仓库，用于多人协作和备份。

它们之间的关系可以用一句话概括：你在工作区修改文件，挑选一部分改动用git add放上暂存区，然后通过git commit把暂存区的内容打包成一个提交，存入本地版本库，最后通过git push推送到远程仓库。

为什么要设计暂存区这么一层？因为现实中你经常会同时改多个文件，但有些改动是一个功能，有些改动是另一个功能。没有暂存区，你只能一个接一个提交，每次提交都带上所有未提交的改动。有了暂存区，你可以精确挑选哪几个文件进入下一次提交，让每次提交的语义更清晰。这就是 Git 被称为“优秀的提交管理工具”的原因之一。

3.2 Git 对象模型：blob、tree、commit 和 tag

Git 内部本质上是一个存储对象的数据库。理解这几个对象类型，你就看透了 Git 的底层逻辑：

• blob：文件内容的快照。Git 不管文件名，只管内容，内容相同就复用同一个 blob。
• tree：目录结构的快照，它记录了目录里有哪些文件、每个文件对应哪个 blob、以及子目录对应的 tree。
• commit：一次提交，它包含指向某个 tree 的引用、父提交的引用、作者信息、提交信息等。
• tag：一个固定的引用，通常指向某个 commit，用作里程碑标记。

当你运行git commit时，Git 实际上做了这样的事：把暂存区里的文件内容写入对象库生成 blob，把这些 blob 按目录结构组织成 tree，再生成一个 commit 对象指向这个 tree，最后把当前分支的指针更新到新的 commit。

这解释了 Git 一个很多人会觉得“玄乎”的地方：为什么 Git 存储的不是差异（diff），而是快照（snapshot）？因为每次提交，Git 都完整地记录了当时所有文件的内容。空间占用看起来会很大，但 Git 内部有压缩和去重机制（相同内容的 blob 不重复存储），实际空间开销远比你想象的小。而快照模型带来的是极致的读取速度——切换分支、对比历史，都不需要去“算”出某个版本的文件内容，直接拿出来用就行。

3.3 分支为什么“轻”得惊人——指针的艺术

理解了对象模型，分支就不难了。在 Git 里，分支本质上只是一个指向某个 commit 对象的可移动指针。

当你创建一个新分支时，Git 并不是复制文件，而是创建了一个 41 字节的指针文件。所以 Git 创建分支、切换分支才那么快——它只是把 HEAD 指针从一个 commit 挪到另一个 commit，然后更新工作区文件。如果你切到历史很旧的分支，看起来好像“代码变了”，其实不是 Git 帮你改了代码，只是工作区的文件被替换成了目标 commit 对应的快照。

这个指针模型还能解释很多“怪现象”：

• 为什么git branch能秒建几十个分支？因为只是新建指针。
• 为什么git checkout能迅速在不同分支间跳转？因为本质是移动指针。
• 为什么 Git 鼓励多建分支？因为分支的创建和销毁成本极低，这是分布式开发模型的最大红利。

理解指针模型还有一个好处：未来你把git reset、git merge、git rebase理解了，它们本质上都是在移动指针或创建新的提交，而不是“魔法”。

4. 日常实战：克隆、提交、分支、合并一次打通

原理讲完了，说点能直接上手的。这一节我从最常用的操作讲起，带你走一遍日常开发的主流程。

4.1 克隆仓库与完整提交流程

得到一个新项目的第一个动作通常是克隆：

git clone <远程仓库地址>

这会在你当前目录下创建一个跟仓库同名的文件夹，并把默认分支（通常叫 main 或 master）的最新代码拉下来。克隆下来后，你就可以开始改了。

日常开发主循环是这几个命令：

# 1. 查看当前状态，红色标识未跟踪或已修改文件 git status # 2. 把文件加入暂存区，可以用 . 表示所有改动 git add . # 3. 查看暂存区与前一个提交的差异，绿色显示 git diff --cached # 4. 提交，写清改动说明 git commit -m "feat: 新增登录功能" # 5. 推送到远程仓库 git push

我每次提交前几乎都会执行git diff --cached看一眼自己到底改了什么东西，防止把调试代码、临时输出、敏感信息误提交上去。这一步看着多余，实际上能救你无数次。

4.2 提交规范：怎么写 commit message 才不招人烦

提交信息不是随便写几个字就完事的。一个团队如果提交习惯差，一个月后看提交历史，根本不知道每个 commit 改了些什么。推荐 Angular 提交规范，这也是目前开源社区最通行的一套：

结构是：<type>(<scope>): <subject>

Types 常见取值：

• feat：新功能（feature）
• fix：修复 bug
• docs：文档变更
• style：格式调整，不影响逻辑
• refactor：重构，既有功能不变
• perf：性能优化
• test：增加或修改测试
• chore：构建过程或辅助工具的变动

举个例子：

git commit -m "fix(login): 修复密码错误时无提示的问题"

这样写的意思一目了然：这次提交修复了登录模块的一个 bug，具体问题是密码错误时没有提示。看历史的人不用打开代码就能知道每次提交的意图，配合git blame定位问题也会有价值得多。

如果你觉得命令行写多行 commit message 太麻烦，可以用：

git commit

不带-m，Git 会打开你配置的编辑器，在那里可以写标题和正文，推荐正文部分写清楚“为什么改了这些”。

4.3 reset、revert、restore：三个撤销命令一招分清

“我想撤销刚才的提交”“我想把工作区恢复原状”“我想放弃某个文件的修改”——这些需求分别对应不同命令，很多人搞混了。我按“目标”来梳理：

• git restore <file>：丢弃工作区的改动，把文件恢复到最近一次提交或暂存的状态。适合“我改坏了还没 add”的场景。
• git reset：移动当前分支的 HEAD 指针。用于撤销提交，有三种模式：

--hard是一个非常危险的操作，它会把工作区文件直接重置掉，未提交的改动会彻底消失。用之前务必确认。

• git revert <commit>：通过创建一个新的反向提交来抵消指定提交的改动。这是“安全回滚”的首选，尤其是修改已经 push 到远程的情况下，因为 git revert 不会改写公共历史，不会造成别人 pull 时的冲突。

一句话：改坏了还没提交，用restore；提交了但没推送，想重写历史，用reset；提交了且已推送，想安全回滚，用revert。

4.4 分支管理：feature、merge、rebase 的正确姿势

日常开发中，主分支（main/master）通常要保持稳定。每次开发新功能时，从主分支拉一个新的功能分支：

# 基于当前分支创建并切换到新分支 git checkout -b feature/login

开发完、测试通过、把改动合并回主分支：

# 先切回主分支，拉取最新远程代码 git checkout main git pull # 合并功能分支 git merge feature/login

合并之后，常用的清理动作：

git branch -d feature/login git push origin --delete feature/login

-d只能删除已合并的分支，如果分支还有未合并的提交，Git 会拒绝，需要换成-D强制删除。这个保护机制很有用，防止你误删掉还有价值的工作。

关于git merge和git rebase的选择：合并会产生一个真实的合并提交，保留分支聚合的轨迹；变基会把你当前分支的提交“重新放”到目标分支的顶端，让提交历史变成一条直线，更整洁。

我的建议是：公共分支、几个人协同的分支上，用 merge 更安全；自己一个人开发的功能分支，想保持历史干净，可以用 rebase。

4.5 冲突处理：别慌，一步一步来

冲突是 Git 入门者的噩梦。但说白了，冲突只不过是 Git 在问你：同一块地方，两个人做了不同的修改，我该听谁的？

比如你和同事同时改了login.js的第 10 行，他先提交了，你再 pull 时就会冲突。出现冲突后，Git 会在冲突文件里标记：

<<<<<<< HEAD 这是你当前分支的内容 ======= 这是别人分支的内容 >>>>>>> feature/login

处理步骤：

1. 用编辑器打开冲突文件，你会看到上面这种标记。
2. 手动选择保留哪部分代码、删除哪部分，或者两边合并。
3. 删除所有<<<<<<<、=======、>>>>>>>标记。
4. 保存文件，然后git add该文件，再git commit完成合并提交。

避免冲突最有效的手段是：频繁 pull 最新代码，每次 pull 之后立刻测试。冲突发生得越晚，上下文差异越大，解决成本越高。经常跟远程同步，可以最大程度减少同时间同区域修改的概率。

5. 进阶玩法：Git 服务器搭建、忽略文件与安全加固

如果你只是个人开发，用 GitHub 或 Gitee 就够了。但公司内部代码一般不建议放公网，你需要自己搭一个 Git 服务器。这也是从“会用 Git”走向“懂 Git”的一个重要台阶。

5.1 自己搭建 Git 服务器：Gitea 与 GitLab 的选型

搭建 Git 服务器的方案有好几种，从轻量到重量排个序：

• 纯 Git 裸仓库：最轻量，在 Linux 服务器上创建一个裸仓库，通过 SSH 协议共享。适合个人或极小团队，但缺少权限管理、代码审查、Web 界面。
• Gitea：一个非常轻量的 Git 服务程序，内存占用小，部署快，自带 Web 界面、账户体系和简单的代码审查。对大多数中小团队来说，Gitea 完全够用了。
• GitLab：功能非常全，CI/CD、代码审查、权限模型、安全扫描等都内置了，但资源占用大（官方建议至少 4GB 内存），适合对功能和集成有高要求的团队。

我个人给团队搭建时，默认方案是 Gitea。它的安装太友好了，下载对应平台的二进制文件，或者用 Docker：

docker run -d --name=gitea -p 3000:3000 -p 22:22 -v /var/lib/gitea:/data gitea/gitea:latest

启动后，浏览器访问 3000 端口，按提示做初始化配置，就能在网页上创建仓库、添加 SSH 密钥了。整个过程不到十分钟。之后成员使用跟 GitHub 的体验基本一致，克隆、推送、拉取都一样。

5.2 Git 目录泄露：风险与应对

聊一个偏安全的话题。git目录泄露是指网站的.git目录被错误地暴露在公网上，导致任何人都能通过浏览器直接访问.git目录里的对象文件，进而用工具恢复出整个源代码仓库。这是很常见的错误部署方式——很多人在发布网站时，直接把整个开发目录上传，忘了排除.git文件夹。

作为开发者，你要注意两件事：

1. 自己不要踩这个坑。部署时用.gitignore不影响.git目录的排除，部署前务必确认.git不会被上传到服务器。静态站点部署尤其注意，建议在服务器配置层禁止访问.开头的目录。
2. 发现泄露后的处理。如果真的不小心把.git目录暴露了，第一时间收紧目录访问权限、移除公网访问路径，并且加固服务器配置。如果是别人部署的系统泄露了，应及时联系提醒处理。生产环境服务器上如果存在.git目录，建议做一次排查。

Git 目录泄露反映出的核心问题是对 Git 机制理解不足——.git目录是整个仓库的“内核”，里面装着全部历史记录和对象数据，暴露它就等于把源码和历史全部交了出去。

5.3 忽略文件 .gitignore 的正确姿势

.gitignore是项目里必须有的文件，用来告诉 Git 哪些文件不要纳入版本管理。常见的需要忽略的：临时文件、日志、编译产物、依赖目录（如node_modules/）、本地配置、IDE 配置、密钥文件等。

一个典型的 Node.js 项目 .gitignore 长这样：

node_modules/ dist/ *.log .env .DS_Store .idea/ .vscode/

这里强调几个经验：

• 密钥、环境变量文件（.env、config.local.js）必须忽略，否则一旦提交到 Git 历史里，即使后面删掉，历史记录里依然存在，这是泄露的高危区。
• .gitignore只影响尚未跟踪的文件。如果你之前已经把某个本应忽略的文件 add 过，那么忽略规则不会生效，需要先把它从版本库移除：

git rm --cached filename

再添加到.gitignore里。

• 尽量在项目创建的第一时间就把.gitignore建好，避免后面处理“已经入库的垃圾文件”这种尴尬局面。

5.4 Git 大文件存储：LFS 能解决什么问题

仓库里如果放了很多图片、视频、二进制安装包，仓库体积会迅速膨胀，克隆和拉取都会变得很慢。Git LFS（Large File Storage）就是为这个场景设计的。

LFS 的原理是把大文件替换成一个文本指针文件，真正的文件内容存到 LFS 服务器上。克隆仓库时只下载指针文件，只有真正 checkout 到大文件的版本时才去下载内容。这样历史仓库不会因为频繁修改大文件而无限膨胀。

使用方式：

# 安装 LFS git lfs install # 跟踪指定类型的大文件 git lfs track "*.psd" "*.zip" # 提交 .gitattributes git add .gitattributes git commit -m "chore: 配置 Git LFS"

要注意的是，LFS 只是把大文件的存储方式改了，并不是万能药。如果可以不往仓库里放大文件，尽量别放。如果是超大单体文件，考虑构建产物走专门的制品库，源码仓库保持精简。

6. 高频报错速查：我把这些年踩过的坑都贴在这

最后这部分，我把使用 Git 过程中遇到频率最高的报错和排查思路整理成表格。每个问题的描述、原因、解决办法都写清楚，建议收藏，遇到直接查。

6.1 命令行没反应？先看这五个地方

有时候命令敲下去，并没有报错，但也没效果。这类“诡异”问题，我通常按以下顺序排查：

1. 看当前分支：git branch，确认你没在 detached HEAD 状态（即 HEAD 没有指向任何分支）。
2. 看远程分支同步情况：git remote -v，确认 remote URL 指向正确，没配置错仓库。
3. 看 .gitignore：是不是新文件被忽略了，所以git add .没效果。
4. 看 index.lock：如果.git/index.lock文件存在且进程已死，会导致 Git 命令被阻塞。删除这个文件可以解决，但前提是确认没有 Git 进程正在运行。
5. 看代理设置：某些 Git 命令（如 Clone 走 HTTPS）会读取系统代理，代理配置异常会导致超时或 fallback 失败。检查git config --global --list里是否有残留的 proxy 配置。

6.2 小乌龟登录失败问题排查

有同学用 TortoiseGit 配合 GitLab/Gitee 时，遇到过这样的提示：login failed. check api token or gitlab version. log in via git if the version...。这种情况主要发生在小乌龟的某种“Git 远端”集成场景下，通常和 API Token 有关。

遇到这类问题，我的处理思路是：

• 检查远端地址是否使用了正确的带 token 的 URL 格式。
• 检查 token 权限是否足够，比如只给了 read 权限却想 push。
• 最省事的做法：不要依赖小乌龟的远端集成认证，改用 SSH 方式连接仓库，密钥配好了就不用管理 token 过期的问题。
• 另外，小乌龟的某些“远端”用了应用的 API 能力，如果服务端版本比较老、接口不兼容，也会报这个错。升级 TortoiseGit 到最新版往往能解决这类兼容性问题。

6.3 一个实用技巧 stash：把临时改动存起来

场景：你正在功能分支上改代码，改了一半，突然需要紧急修一个线上的 bug。你不能把没写完的代码提交上去，但切分支又会因为工作区有未提交改动而被拒绝。这时候git stash是你的救星：

git stash git checkout main git pull # 紧急修复... git checkout feature/login git stash pop

git stash会把工作区的未提交改动暂时存到一个栈里，让工作区恢复干净。git stash pop再把之前存起来的改动弹回来。这个命令我几乎每周都会用到，是非常高频的实用技巧。

如果你想看到 stash 列表，用git stash list；如果弹回来后冲突了，处理冲突的方式跟普通合并一样，解决后git add即可。

最后再分享一点我的个人体会

Git 学了很久之后我才想明白一件事：很多人觉得 Git 难，难的不是命令，而是心智模型。一旦你搞懂工作区、暂存区、版本库、远程仓库四个概念，明白分支是指针、提交是快照，那些看起来“乱糟糟”的命令其实自然而然就有了归属感。

所以我的建议是：别急着背命令表，先把原理啃下来，然后在实操中不断加深理解。每遇到一个报错，都是一次加深理解的机会。真要在面试或者同事面前“露一手”，你不一定要背出所有命令，但你能讲清楚git pull实际上做了 fetch 和 merge 两件事、git reset --hard为什么会丢代码、为什么 Git 切分支这么迅速——这些远比默写命令列表更有说服力。

工具永远服务于人。Git 不是用来折磨你的，它是用来保护你的时间和心血的。希望你把它真正变成自己的武器，而不仅是几行指令。