Git版本控制完全指南：从基础原理到团队协作与疑难排查

我当年带第一个项目的时候，最怕的不是需求变更，而是"版本管理全靠自觉"。团队里有个习惯——改代码之前先复制一份，于是仓库里出现了"xxx_v1.py"、"xxx_final.py"、"xxx_真_final.py"，再后来有人干脆用网盘同步文件夹，结果一次误覆盖，两天的工作量直接蒸发。后来我下定决心把所有项目迁到 Git，并且把团队的使用规范系统梳理了一遍，从那以后"版本混乱"这个词就再没出现过。

这篇文章也算是我这些年使用 Git 的一次深度复盘。从一个文件如何进入仓库开始，到分支合并、撤销回退、提交规范、疑难杂症排查，一直到免密配置和图形化工具选型，我把能讲的、值得讲的都整理出来。无论是刚接触 Git 的新手，还是已经在用但经常被报错卡住的准熟手，这篇文章都能帮你把零散的 Git 知识串成一个完整体系。

1. 版本控制不是"多存几份文件"，而是项目的地基

1.1 没有版本控制的痛，经历过的都懂

很多人对版本控制的第一反应是"不就是备份吗"。但如果你真的在多人协作的项目里待过，就会发现它远远不止备份这么简单。没有版本控制时，最常见的尴尬局面是：两个同事同时改了同一个模块，彼此不知道，等合并代码时发现"你的改动把我还原了"，谁也说不清哪个版本才是最新的。这种场景下，文件命名和网盘同步都无能为力，因为问题本质不是"文件丢了"，而是"变更没有记录"。

版本控制系统的核心价值，是让每一次变更都有迹可循、可回溯、可对比。它记录的不只是文件内容，还有谁在什么时间因为什么原因做了修改。写过代码的人都知道，很多时候排查 bug 最想问的问题不是"代码现在长什么样"，而是"它怎么变成这样的"。有了版本历史，这个问题就有了答案。

1.2 为什么主流选择了 Git

说到版本控制，历史上还有 SVN、CVS 这些集中式版本控制系统。它们的特点是有一个中央服务器，所有提交都要先连上服务器，个人电脑上只有一个工作副本。这样做的问题很明显：一旦服务器挂了或者网络不通，提交、日志、分支这些操作全都瘫痪。

Git 采用了分布式设计。每个开发者的本地仓库都是完整的历史拷贝，所有常规操作都在本地完成，速度极快，也不需要时刻联网。就算服务器明天被雷劈了，只要任何一个人的本地仓库还在，完整记录都能恢复回来。这种设计在移动办公、远程协作、开源项目这些场景下优势非常明显。

另外一个关键优势是 Git 对分支的轻量级支持。在 SVN 里建分支通常是拷贝整个目录，又慢又占空间，所以在集中式系统里分支是"能不建就不建"的重操作。Git 的分支本质上只是一个指向某个提交的指针，创建和切换几乎瞬时完成。分支行为变得非常便宜，于是"开个分支试试"成了 Git 时代最自然的开发方式。

1.3 Git 底层到底在管理什么

理解 Git，最好先理解它内部存的是什么。Git 把仓库看成一组对象，包括四类核心对象：

• blob（数据对象）：文件内容本身，一个文件内容对应一个 blob。
• tree（树对象）：目录结构和文件名清单，记录目录里有哪些子目录和文件，以及它们指向哪个 blob。
• commit（提交对象）：一次提交的完整快照，包含指向根 tree 的引用、父提交的引用、提交信息、作者、时间等。
• tag（标签对象）：给某个提交打上的固定标记，常用于版本发布。

平时我们执行 git commit，Git 会先为所有跟踪的文件生成对应的 tree，再生成一个 commit 对象指向这个 tree。每个 commit 都知道自己的"爸爸"是谁，这样所有提交就串成了一条不可能是环的有向无环图，完整记录了项目的时间线。

由于每次提交都保存了一棵完整的 tree，很多人误以为 Git 特别占空间。实际上 Git 对仓库内的对象做了压缩和去重，相同内容的 blob 只会存一份，而且对象还有增量压缩机制，所以仓库体积的控制做得相当好。这也是 Git 敢说自己是"快照式"版本管理的底气。

2. 安装、配置与初始化：这些基础步骤后面全是泪点

2.1 各平台安装 Git 的正确姿势

Windows 用户一般去 Git 官网下载安装包，一路 Next 即可。这里我建议保留安装向导默认选项，特别要注意"Adjusting your PATH environment"这一步，务必选择 "Git from the command line and also from 3rd-party software" 选项，把 Git 加入系统 PATH，否则之后在终端里敲 git 会提示"不是内部或外部命令"。

macOS 上最简单的方式是装好 Homebrew 之后执行 brew install git，版本也是最新的。如果不想装 Homebrew，直接用 Xcode Command Line Tools 里自带的 git 也行，Mac 上运行 git --version 如果提示没有，系统还会弹窗引导你安装命令行工具。

Linux 发行版用各自的包管理器即可，Debian/Ubuntu 执行 sudo apt install git，CentOS/RHEL 执行 sudo yum install git。装完之后建议先跑一下 git --version，确认一下版本号。顺便说一句，如果下载官网安装包速度不理想，可以找国内高校或云厂商提供的 Git 镜像，这是很常规的做法。

2.2 全局配置：用户名、邮箱、换行符

安装好 Git 之后，第一步是配置身份信息。Git 每次提交都会记录作者和邮箱，所以这两个信息必须正确：

bash复制git config --global user.name "Your Name"
git config --global user.email "your@email.com"

注意邮箱最好是真实常用的邮箱，因为很多代码托管平台的账号关联靠的就是这个邮箱。如果你给开源项目提交代码，建议使用 GitHub 上默认的 noreply 邮箱保护隐私。

除了身份信息，还有一个容易被忽略的配置是换行符处理。Windows 和 Linux/macOS 的换行符不一致（CRLF 与 LF），如果团队横跨多个平台，可能每次拉代码都会看到整文件被标记为变更。Git 提供了 core.autocrlf 选项来缓解：

• Windows 上建议配置 git config --global core.autocrlf true，提交时自动转成 LF，检出时转回 CRLF。
• Linux/macOS 上建议配置 git config --global core.autocrlf input，提交时转 LF，检出不强制转。

另外推荐执行 git config --global core.quotepath false，这个配置可以让中文文件名在 Git 状态输出里正常显示，而不是被转义成八进制的乱码。

2.3 环境变量问题排查

Windows 上最常见的 Git 报错就是"git 不是内部或外部命令，也不是可运行的程序或批处理文件"。这通常是因为安装时没有把 Git 加入 PATH，或者 PATH 配置被修改了。解决办法是在系统环境变量的 Path 里增加 Git 的安装路径，一般默认是 C:\Program Files\Git\cmd。改完后新开一个终端窗口，重新运行 git --version 验证。

如果是在 VSCode 里发现无法识别 git，但终端能用，一般是 VSCode 没有重新加载环境变量。重启 VSCode 或者关闭再打开终端面板就能解决。这类问题本身不是 Git 的故障，是环境变量没有生效的经典案例。

2.4 移除文件的版本控制：一个必须掌握的姿势

Git 使用过程中，你大概率会遇到一个场景：某天不小心把一个本该忽略的文件提交进了仓库，比如本地的 .env 环境变量配置、编译产物、IDE 配置文件等。你要做的不是手动删掉这个文件再提交，而是使用 git rm --cached：

bash复制# 从版本控制中移除，但保留本地文件
git rm --cached .env
# 将移除操作提交
git commit -m "chore: remove .env from version control"

--cached 参数表示只从索引（暂存区）中移除，不删除工作区的真实文件。之后顺手把该文件加入 .gitignore，避免后续再被误提交。常见问题里经常有人问"移除了版本控制但本地文件还在吗"，答案是在，--cached 就是用来解决这个的。

3. 三棵树与文件状态：理解 Git 的关键心智模型

3.1 工作区、暂存区、版本库的三角关系

Git 的精髓，我觉得三棵树的概念占了七成。几乎所有命令都围绕这三个区域展开：工作区是你电脑里能看到的目录，暂存区是一个隐藏的中间层，版本库则是保存所有历史提交的数据库。

如果非要打个比方，工作区相当于你的书桌，暂存区是打包区，版本库是已经入库的档案柜。你在书桌上写东西，写完觉得这版可以，放进打包区；攒够了觉得没问题，正式归档到档案柜。归档后每一份档案都有编号、日期和详细说明，想翻哪份翻哪份。

三棵树的说法来自 Git 官方文档，分别是 HEAD（最后一次提交的快照）、Index（暂存区）、Working Directory（工作区）。一次完整提交过程，就是你先把工作区的变更挪到 Index，再通过 commit 把 Index 的快照固化到 HEAD。

3.2 文件状态的四种流转

与三棵树对应的是文件的四种状态：未跟踪、已修改、已暂存、已提交。

• 未跟踪（Untracked）：文件在但 Git 不认识它，通常是新文件，git status 会显示在 Untracked files 区域。
• 已修改（Modified）：文件被 Git 追踪，但工作区内容和暂存区不一致。
• 已暂存（Staged）：文件已经通过 git add 加入暂存区，等待提交。
• 已提交（Committed）：变更已经固化到版本库。

我用 git status 的频率特别高，每次改代码前先看一眼状态，改完再看一眼，几乎形成肌肉记忆了。状态输出里会明确提示你现在处于哪个环节、下一步建议执行什么命令，对新手来说这就是最好的向导。

3.3 commit 在底层做了什么

执行 git commit -m "msg" 时，Git 会做几件事：先根据暂存区的文件内容生成对应的 tree 对象，再生成一个 commit 对象，包含 tree 指针、父提交指针、作者和提交信息，最后把当前分支指针移动到新 commit 上。这一步完成，本次快照就永久保存在 .git 目录里了。

这里有个细节值得留意：每次 commit 都会生成完整的文件快照，而不是只记录差异。所以理论上你的每次提交都是一次"保险点"。哪怕后来代码改得面目全非，只要知道某个历史 commit 的哈希值，就能通过 git checkout <hash> 或者 git restore --source=<hash> 把当时的状态找回来。

理解了这一点，后面的 reset、revert 操作就都好解释了。无非是在"移动 HEAD 指针"和"生成反向提交"这两种策略里做选择。

4. 高频命令工作流：从 clone 到 merge 的日常

4.1 clone、add、commit、push 的完整闭环

绝大多数开发者的日常都围绕一个固定循环：从远程仓库拉代码到本地，修改功能，提交，推回远程。

bash复制# 克隆远程仓库到本地
git clone https://github.com/example/project.git

# 查看状态
git status

# 添加指定文件或全部文件到暂存区
git add src/main.go
git add .

# 提交
git commit -m "feat: add user login api"

# 推送到远程
git push origin main

git clone 会把仓库的完整历史拿到本地，并且默认配置好 origin 远程地址。git add . 很方便，但我建议在提交前执行 git status 和 git diff 确认变更内容，避免把调试日志、临时文件、无关修改一起交进去。好习惯是让每次提交的改动范围尽量小、目的尽量明确。

git push origin main 里的 origin 是远程仓库的默认别名，main 是本地分支名。如果你还没推送过当前分支，Git 会提示你使用 git push --set-upstream origin main 建立追踪关系，第一次设好之后，后续直接 git push 即可。

4.2 分支：为什么它这么便宜

分支是 Git 最灵活的部分。前面说过，Git 分支本质上只是个指向 commit 的指针，新建分支就是创建一个新指针，加上切换 HEAD 指向它。这个过程不复制任何文件，所以哪怕几百个分支也毫无压力。

日常开发我推荐这样的分支策略：

• main（或 master）永远是稳定可发布的分支。
• 开发新功能时从 main 拉出 feature/xxx 分支。
• 修紧急 bug 时从 main 拉出 hotfix/xxx 分支。
• 准备发版时拉出 release/v1.2.0 分支。

bash复制# 创建并切换分支
git checkout -b feature/login

# 或者新版命令
git switch -c feature/login

# 查看当前分支
git branch

# 切换分支
git checkout main
# 或
git switch main

新版 Git 推荐用 git switch 和 git restore 来替代 git checkout 的多重职责。checkout 既能切分支又能恢复文件，新手容易混淆，拆开成两个命令之后语义清晰很多。

4.3 merge 与 rebase 的选择

分支开发完之后，要把代码合回来，一般有两种方式：merge 和 rebase。

bash复制# 把 feature/login 合并到当前分支
git merge feature/login

# 或者用 rebase 让历史更整洁
git rebase main

merge 会生成一个额外的合并提交，保留了真实的分支分叉痕迹；rebase 则会把当前分支的提交"搬到"目标分支的最新提交之后，让提交历史呈线性。两者没有绝对的好坏，我的经验是：公共分支用 merge，保留历史真实记录；个人开发分支在推远程之前用 rebase，保持提交线干净。

当两个分支改了同一个文件的同一块内容时，合并就会产生冲突。Git 会把这文件的冲突区域用 <<<<<<<、=======、>>>>>>> 标记出来，你需要手动决定保留哪边。我在团队里常说一句话：解决冲突不是"删掉别人的代码"，而是要理解两边各自的意图，把两边的需求都正确保留下来。解决完冲突后执行 git add，再 git commit 完成合并。

4.4 撤销：restore、reset、revert 怎么选

撤销操作可能是 Git 命令里最让人头大的部分，因为命令非常多。我现在用一套比较清晰的选择逻辑：

• 工作区改动还不想要，直接 git restore <file>，回到暂存区或 HEAD 的状态。
• 已经 git add 进暂存区，想撤回到工作区，用 git restore --staged <file>。
• 想丢弃最近几次提交，让分支回退到某个历史 commit，用 git reset --hard <hash>，但注意这会丢失之后的提交（如果这些提交没被推送，风险还可控）。
• 已经推送到远程，想撤销某次提交的影响，但又想保留历史记录，用 git revert <hash>。它会生成一个反向提交，把之前的改动撤销掉，但不会删除原提交。

git reset 和 git revert 的核心区别在于：reset 是移动历史指针，revert 是新建一个提交来抵消变化。凡是已经推到公共分支的提交，一律不要用 reset 硬删，否则团队其他人 pull 时会出现大量同步问题。公共历史是不可变历史，这是多人协作必须遵守的底线。

4.5 查看历史：log、graph、diff

git log 是我最常用的历史查看命令，推荐两个参数组合：

bash复制# 单行显示提交历史
git log --oneline

# 图形化显示分支结构
git log --graph --oneline --all

# 查看某个文件的历史
git log --follow -- src/main.go

# 查看工作区与暂存区的差异
git diff

# 查看暂存区与 HEAD 的差异
git diff --staged

git log --graph 输出里会有 *、|、\ 这样的字符，能直观看到分支的分叉和合并走向。很多 IDE 的 Git 插件就是把这类信息用图形界面呈现出来，比如 VSCode 的 Git Graph 扩展。理解了命令行输出的逻辑，再看图形工具就非常简单了。

5. 提交规范与团队协作：让历史成为资产而非垃圾

5.1 提交信息为什么影响这么大

团队协作里，最容易被忽视却又最影响体验的就是提交信息。我见过很多仓库的历史信息是"update"、"fix"、"111"、"aaa"，这种历史不仅没有参考价值，连基本的问题定位都做不了。

举个很实际的例子：某天线上出问题，你怀疑是某次重构引入的。你打开 git log 希望快速定位"哪次提交改动了认证模块"，结果提交信息全是"update"，你只能逐个提交去看 diff，效率极低。反过来，如果提交信息语义化明确，比如 fix(auth): fix token expiry check，你一眼就能锁定候选提交，排查时间直接缩短一个数量级。

好的提交信息同时还是自动化工具的输入。很多 CI/CD 流程依赖提交信息判断版本号、自动生成 changelog，或者决定是否触发发布任务。规范一旦被团队接受，收益是全方位的。

5.2 Conventional Commits 规范详解

目前业界最通用的提交规范是 Conventional Commits，格式如下：

code复制<type>(<scope>): <description>

[body]

[footer]

核心是 type 字段，常用的类型有：

• feat：新功能
• fix：修复 bug
• docs：文档变更
• style：代码格式调整，不影响逻辑
• refactor：重构，既不是新功能也不是修 bug
• perf：性能优化
• test：测试相关
• build：构建系统相关
• chore：日常杂项、依赖升级等

scope 是可选的，用于描述影响范围，比如 feat(auth): add login api 就表示影响认证模块。description 用祈使句、简洁明了，一般不超过 50 个字符。如果提交有破坏性变更，在 footer 里标注 BREAKING CHANGE:。

我建议团队把这套规范写进 README 或者 CONTRIBUTING 文档，新人在第一次提交前花十分钟读一下，之后整个仓库的历史质量会非常稳定。

5.3 原子提交：一次提交只做一件事

与提交信息同样重要的是提交粒度。我特别推崇原子提交——每个提交只做一件逻辑上独立的事，可以是"新增一个接口"、"修复一个空指针"、"调整页面样式"。不要一个提交里同时包含两个不相关的功能，否则哪天要撤销其中一个，另一个也被拖下水。

原子提交的核心不是"提交次数越少越好"，而是"每个提交都能独立审阅、独立回滚"。代码评审的时候，reviewer 按提交逐个看，分区清晰，效率会高很多。一旦出了问题，回滚也只需 git revert 那一个提交，其余代码不受影响。

6. Git 疑难杂症排查实录

6.1 "git 不是内部或外部命令"

这是 Windows 上最经典的 Git 报错。出现原因基本就是 PATH 环境变量没有 Git 的安装路径。解决方法很简单：确认 Git 安装路径，通常在 C:\Program Files\Git\cmd，然后把这个路径加入系统环境变量 Path。改完后重新打开终端，执行 git --version 验证。

如果你用的是 VSCode 的终端，注意 VSCode 继承的是打开时的环境变量，所以改完 PATH 后需要完全重启 VSCode，而不是只开一个新的终端标签页。这个细节很容易让人误以为自己没改对。

另外还有一种情况是只安装了 Git 的 GUI 客户端（比如 TortoiseGit 的 standalone 版）但没有勾选"将 Git Bundled 工具加入 PATH"。解决方案同样是手动添加 PATH，或者重新安装 Git for Windows，在安装时选择加入 PATH 的选项。

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

这个报错说明当前目录不在 Git 仓库中，且往上找父目录也没找到 .git 文件。最常见的原因是：克隆/初始化的时候选错了目录；或者仓库确实存在于某个上级目录，但你直接 cd 到了子目录之外；又或者在错误的地方执行了 git 命令。

解决方法是先 pwd 确认当前路径，再检查该目录下是否有 .git 目录或文件：

bash复制ls -la .git

如果整个项目还没初始化，执行 git init 把当前目录变成仓库。如果项目是从远程克隆的，检查是否把仓库克隆到了别的目录，重新 cd 到仓库根目录即可。

还有一种隐蔽的情况：子模块的仓库路径变了。Clone 了带子模块的项目，但执行子模块命令时母仓库找不到子模块的 .git 元数据，报错也可能是这句。此时进入子模块目录执行 git submodule update --init 或确认子模块是否被正确加载。

6.3 "error setting certificate file"与 SSL 证书问题

Windows 上 Git 偶尔会报类似这样的错误：

code复制unable to access 'https://xxx/yyy.git/': error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt

这个报错说明 Git 尝试读取 HTTPS 证书文件时，路径不存在或者文件缺失。常见原因是 Git 安装目录被移动过，或者重装了不同版本的 Git 后旧的全局配置还指向旧路径。

排查思路是查看 http.sslCAInfo 配置：

bash复制git config --global --list

如果看到某个 sslCAInfo 指向不存在的路径，重新设置或者删除即可：

bash复制git config --global --unset http.sslCAInfo

如果你是出于安全性考虑想指定证书文件，可以用：

bash复制git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt"

某些企业内网环境使用自签证书时，这类报错尤其常见。不建议直接执行 git config --global http.sslVerify false 关闭验证，虽然能解决问题，但安全隐患比较大。更好的方式是向网络管理员申请正确的根证书，或者把内网证书加入系统证书库。

6.4 认证失败："login failed. check api token or gitlab version"

这类报错通常发生在通过 HTTPS 访问私有仓库时。老一点的 Git 版本对某些平台支持的认证协议不完善，或者你的凭证信息过期，都会导致认证失败。

排查链路一般是这样：

1. 确认远程地址正确：git remote -v
2. 尝试重新认证：更新凭证管理器中的账号密码，Windows 上就是"凭据管理器"里删除旧的 Git 凭证，再执行一次操作重新输入账号密码。
3. 如果平台支持，改用 Personal Access Token 代替密码。
4. 条件允许的话，干脆切换到 SSH 协议认证，一劳永逸。

6.5 如何防止 .git 目录泄露

最后说一个比较容易被忽视的安全问题。如果你的网站是静态部署的，执行构建后没有清理 .git 目录，别人就能通过 https://你的域名/.git/ 直接访问 Git 元数据。攻击者可以用工具把 .git 目录完整下载下来，甚至可以在本地还原你的全部源码历史，包括那些"不该出现在生产环境的敏感信息"。

这个问题在搜索引擎热词里排得很高，说明实际中确实有不少人踩过。防护方法很简单：

• 构建部署时，把 .git 目录排除在发布文件之外。
• Web 服务器配置规则，禁止外部访问所有以 . 开头的目录和文件。
• 养成习惯：上线前检查一遍 https://你的站点/.git/config 是否可访问。
• 如果已经泄露且历史提交里有敏感信息（比如密码写进了代码），立即轮换所有相关密钥，而不是只删掉 .git 目录。

版本控制的核心是保护信息，别让它成为安全漏洞。

7. 进阶玩法：免密、别名与图形化工具

7.1 SSH 密钥免密配置

每次 push/pull 都输密码非常影响效率，推荐配置 SSH 密钥免密。生成密钥：

bash复制ssh-keygen -t ed25519 -C "your@email.com"

一路回车即可，生成的密钥默认在 ~/.ssh/id_ed25519 和 ~/.ssh/id_ed25519.pub。然后把公钥内容复制到代码托管平台的 SSH Keys 设置里。如果平台支持 ED25519，建议优先选它，安全性比 RSA 更好，密钥也更短。

配置好后，把远程地址改成 SSH 形式：

bash复制git remote set-url origin git@github.com:example/project.git

之后 git push 就不再需要输入账号密码了。

7.2 高效配置：别名与图形化工具

Git 支持配置别名，可以极大提高操作效率。我的常用别名配置：

bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --all --decorate"

配置完直接输入 git st、git co 就行。特别注意 git lg，我几乎每天都在用，图形化输出提交历史，比 IDE 里的图还顺手。

图形化工具方面，TortoiseGit（Git 小乌龟）在 Windows 用户里依然有很高人气，右键菜单直接显示变更文件和状态，适合不习惯命令行的同事。VSCode 里推荐 Git Graph 扩展，可以查看分支拓扑、提交信息、文件改动，用起来非常直观。不过我的建议始终是：先学会命令行，再使用图形工具。因为图形工具报错信息通常不完整，只有理解了底层命令，才能准确判断问题。

7.3 Git LFS 与仓库瘦身

大文件（设计稿、模型文件、游戏资源）放进普通 Git 仓库会导致仓库越来越大，每次 clone 都要下载一堆历史大文件，体验极差。Git LFS（Large File Storage）专门解决这个问题，原理是用轻量的文本指针替换真实的大文件内容，大文件本体存储到专用存储空间。

bash复制# 安装 LFS 扩展
git lfs install

# 指定扩展名类型由 LFS 管理
git lfs track "*.psd"
git lfs track "*.zip"

# 提交 .gitattributes 配置文件
git add .gitattributes
git commit -m "chore: track large files with git lfs"

如果仓库已经因为大文件变得臃肿，可以用 git filter-branch 或 git filter-repo 重写历史，把所有历史提交中的大文件从 Git 对象中移除。注意这类操作会重写提交历史，已推送的公共仓库需要所有人协同，不然强制推送会造成历史分叉。

7.4 内网代理场景下的 git 配置

有些企业内部网络出于安全策略要求，访问外网或内网某些服务需要经过代理服务器。Git 支持针对 HTTP/HTTPS 配置代理：

bash复制git config --global http.proxy http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080

如果代理需要认证，可以在 URL 中携带用户名，但建议不要明文填写密码：

bash复制git config --global http.proxy http://username@proxy.company.com:8080

不需要代理时，用 git config --global --unset http.proxy 移除，或者设置 --local 级别只在特定仓库生效。顺便提一句，注意别把开发环境之外无关的代理配置带到企业代码仓库，否则会影响内网仓库的正常访问。

整个 Git 体系用下来，我最大的体会是：它不是随便背几个命令就能驾驭的工具，而是要理解它背后的三个核心概念——对象存储在说什么、三棵树在表达什么、分支指针在指向什么。这三个概念懂了，哪怕是第一次遇到的报错，也能顺着报错信息推一个合理的排查方向。

最后再分享一个小技巧：如果哪天不确定某条命令会做什么，先看一下官方文档或者 git help <command>，然后在没有重要变更的分支上试；不要在主分支上做破坏性实验。经历过一次误操作之后你就会明白，Git 给了你很强的能力，也要求你始终保持清醒，知道自己在哪个区域、要往哪里走。