Git从入门到实战：安装配置、常用命令与报错排查全指南

1. 先搞清楚Git解决什么问题：存档、分支与协作

我第一次在Windows上敲git命令，弹出来的是“git不是内部或外部命令”，当时第一反应是“电脑坏了”。后来才知道，只是没装Git或者环境变量没配好。很多人放弃Git，不是因为它难，而是被这种冷冰冰的英文报错劝退了。这篇博文从安装配置、常用命令、提交规范、高频报错排查到工具链搭配，把Git从零到能正常上手这件事完整讲一遍。适合刚准备学Git的新手，也适合已经入坑但总被报错卡住、想系统补一遍基础的人。

1.1 版本管理：如果你还在手动备份

先问一个很基础的问题：为什么需要Git？

我相信不少人经历过这种场景：项目改到一半发现方案走不通，想回到昨天那个能跑的版本，结果发现“昨天的版本”已经不知道被覆盖多少次了。于是开始用文件名区分：方案_v1.doc、方案_v1_修改版.doc、方案_final.doc、方案_最终版_打死不改版.doc。这种手动备份的方式，短期看能用，但一旦文件多了、协作的人多了，基本是灾难：你根本分不清哪个是最新的，更可怕的是不知道哪个版本里包含了谁的改动。

Git解决的就是这个问题。它给整个项目做了一个“存档点”系统——每次你觉得某个改动有价值，就提交一次（commit），提交之后随时可以回到任意一个历史版本。不夸张地说，用了Git之后，“改坏了怎么办”这个焦虑直接消失，因为最坏的情况也就是回退到上一个存档点。

Git的底层原理是快照和对象存储。每次提交时，它会把当前所有文件的内容按状态记录下来，没变过的文件直接复用上一次的对象，变过的文件才生成新对象。所以它并不像很多人以为的那样“每次提交都复制一份整个项目”，而是用哈希值管理所有文件版本，既省空间又安全。这也是为什么Git被称为“分布式版本控制系统”：每个开发者的本地仓库都含有一份完整的项目历史，不需要联网也能提交、回滚、查历史。

1.2 Git和GitHub/GitLab不是一回事

这是新手最容易混淆的点。Git是一个版本控制工具，它运行在你自己的电脑上，负责记录项目文件的变化。而GitHub、GitLab、Gitee这些是“代码托管平台”，是给你放远程仓库的地方。你可以把Git理解为本地“存档管理软件”，把GitHub理解成“云存档服务”——两者配合使用，但完全不是同一个东西。

用Git的时候，你在本地做提交、分支、回退这些操作，这些都不需要联网。只有当你需要把本地代码同步到远程仓库（git push）或从远程下载代码（git clone、git pull）时，才需要和托管平台打交道。企业在内部用的一般是GitLab或自建仓库，开源项目多数在GitHub上，国内团队用Gitee的也不少。平台可以换，但Git的操作逻辑是通用的。

热搜里常出现“git hub”这种写法，其实就是把GitHub拆开了。GitHub读作“git-hub”，是Git托管服务，不是Git本身。这个细节搞清楚了，后面看文档时就不会总被术语绕晕。

1.3 三个区、四种状态：理解Git的核心模型

Git整个工作流程，本质上就是文件在三个“区域”之间流转：

• 工作区（Working Directory）：你平时看到的、可以编辑的文件所在目录。
• 暂存区（Staging Area / Index）：介于工作区和本地仓库之间的“候车区”。
• 本地仓库（Local Repository）：Git真正保存历史记录的地方，是一堆对象文件，不在你的项目文件里直接显示，一般隐藏在 .git 目录中。

再加上远程仓库（Remote），就构成了Git的完整流转路径。

对应到命令上：git add 是把工作区的改动放进暂存区，git commit 是把暂存区的内容变成一次正式的历史记录，git push 才是把本地提交推到远程仓库。很多新手一上来就“add完直接push”，结果发现推不上去，原因就是漏了commit这步。

用生活化类比来说：工作区是你的工位，暂存区是部门分拣台，本地仓库是公司档案室，远程仓库是异地备份中心。你得先把文件从工位放到分拣台，再从分拣台归档到档案室，最后档案室把副本送到异地备份中心。每一步对应的命令不同，干了哪一步、没干哪一步，git status 全都会告诉你。

文件在Git里有四种状态：未跟踪（untracked）、已修改（modified）、已暂存（staged）、已提交（committed）。理解这四个状态，比背命令重要得多。看到 git status 的输出时，不要只看颜色，先看它说你“暂存了什么”“没暂存什么”“有哪些新文件没被跟踪”，这套概念通了，Git就入门了一半。

1.4 IDE里那串“天书”命令是什么意思

很多用IDEA、VSCode或其他IDE的人可能见过这样一条命令：

bash复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status

这是IDE在后台替你执行Git操作时加了很多参数。第一次看到时我也很懵，但拆开看就明白了：

• -c <key>=<value>：给本次命令临时设置一个Git配置，不改全局配置。
• diff.mnemonicprefix=false：让diff输出里的路径前缀用 a/、b/ 而不是自定义的简写，方便跨平台统一显示。
• core.quotepath=false：让中文文件名正常显示，不转成八进制的 \346\265\213 之类。这个参数在后面配置章节还会讲到。
• --no-optional-locks：禁止Git在这次命令中获取“可选锁”。IDE会在后台频繁调用Git，如果每次都加锁，容易和其他Git操作冲突，加上这个参数可以避免不必要的锁等待。

IDE替我们封装了这层复杂度，所以平时你只需要点按钮，命令会自动拼好。但理解这串参数有一个好处：当你在终端里手动执行Git时，如果遇到中文文件名乱码、diff显示怪异，就知道可能是少了某个配置或参数，而不是电脑坏了。

2. 安装与验证：从“git不是内部或外部命令”开始

2.1 不同系统的安装方式

Git的安装本身不复杂，但不同系统有不同讲究。

Windows用户直接去Git官网（git-scm.com）下载安装包，一路Next即可。注意核对一下系统架构是64位还是32位，现在基本都是64位。macOS用户推荐使用Homebrew安装：brew install git；如果你装过Xcode Command Line Tools，它也自带Git，但版本可能偏旧。Linux用户根据发行版选择：Debian/Ubuntu用 sudo apt install git，CentOS/RHEL用 sudo yum install git，Fedora用 sudo dnf install git。

安装完之后，在终端里输入 git --version。如果输出类似 git version 2.40.0，说明装好了。我建议你拿到任何一台新电脑时，第一件事就是跑这个命令验证环境，而不是直接开始clone仓库，否则很容易把“没装Git”和“网络有问题”混在一起排查。

2.2 “无法识别”的完整排查链路

Windows上最典型的报错有两类：

PowerShell里报的是：

text复制git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写，如果包括路径，请确保路径正确，然后再试一次。

cmd里报的是：

text复制'git' 不是内部或外部命令，也不是可运行的程序或批处理文件。

这两句话翻译成人话就是：系统在“环境变量PATH”里没找到git这个程序。原因通常有三个：

1. Git没有安装成功。
2. Git安装成功了，但安装时没把Git加入PATH。
3. Git加入PATH了，但终端是在安装之前打开的，需要重开一个终端窗口才能生效。

排查路径其实很简单。先确认Git装在哪，Windows默认是 C:\Program Files\Git，如果你自定义安装到了 D:\Git，那执行Git命令的目录就是 D:\Git\cmd。然后去“系统属性 → 环境变量 → 系统变量 → Path”里检查，有没有包含这个cmd目录。

如果没有，手动加进去：新建一条，填 C:\Program Files\Git\cmd，保存后重开终端。这一步做完，基本上“git不是内部或外部命令”就解决了。

另外还有一个容易忽略的点：如果你用 where git 在cmd里查，能看到路径，但PowerShell还是报“无法识别”，很可能是因为PowerShell的执行策略或者PATH缓存。有些老版本系统会缓存环境变量，重开终端不行的话，重启电脑基本都能解决。

2.3 Git Bash和cmd/PowerShell怎么选

Windows上安装Git时会附带一个叫Git Bash的工具。很多人不明白它是什么，其实Git Bash是一个模拟Unix shell的命令行环境，基于MSYS2项目，让你在Windows上也能用 ls、grep、vim 这些Linux风格命令。

我的建议是：新手装完Git后，直接用Git Bash来练习，别急着用cmd或PowerShell。原因很现实：大部分Git教程、博客里的命令都是基于Linux风格的，你在Git Bash里照着敲，和它们在服务器上的表现更接近；而cmd的语法和Linux差异较大，有些命令会执行失败。

PowerShell确实功能更强大，但它有自己的语法和管道机制，比如 ls 的结果是一个对象数组而不是纯文本流，很多新手在这里被绕晕。所以初期阶段，Git Bash是学习成本最低的选择。等你对命令行有了感觉，再切回PowerShell也不迟。

2.4 安装向导里容易被忽略的选项

Windows安装包虽然一路Next也能用，但有三个地方我建议你多看一眼：

• Select Components：默认会勾选Git Bash和Git GUI，不要取消。Git GUI虽然用得少，但偶尔可视化查历史很方便。
• Default editor：默认是Vim，新手用它改commit message时，很容易卡在“怎么退出Vim”这一步。如果有VS Code就选“Use Visual Studio Code as Git‘s default editor”，没有的话选Notepad++也行。
• Adjusting your PATH environment：推荐选中间项“Git from the command line and also from 3rd-party software”，这样git命令能被cmd正确识别。

至于换行符转换那一步，默认选项“Checkout Windows-style, commit Unix-style line endings”对Windows用户是最省心的。这个具体原理在下一章讲配置时详细展开，这一步你只需要保留默认即可。

3. 装完必做的初始配置：身份、换行符和中文文件名

3.1 身份配置：没有它commit会报错

Git装好之后，第一件必做的事是配置用户名和邮箱。别小看这一步，不配置的话，你连第一次commit都完成不了，会看到下面这类报错：

text复制*** Please tell me who you are.
Run
  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

配置方法很简单：

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

这里的邮箱最好和你在GitLab/GitHub上注册的邮箱一致，因为平台会根据提交邮箱把提交记录关联到你的账号。如果邮箱不一致，你的提交会显示成一个“匿名”用户，别人在代码评审时找不到你，会很痛苦。

--global 表示这是一台机器上的全局配置，对所有仓库生效。如果你某个项目想用不同身份，可以在项目目录里不写 --global，这样local配置会覆盖global配置。

3.2 换行符：Windows用户最容易踩的坑

换行符问题是Git里一个非常经典、又特别容易让人崩溃的坑。Windows系统里文本文件换行默认是 CRLF（回车+换行，\r\n），而Linux和macOS默认是 LF（换行，\n）。

假如团队里Windows和macOS的人都有，如果换行符处理不当，你会看到这种诡异现象：明明自己只改了一行，git diff 却显示整个文件全都变了。这就是换行符差异导致的“全红”。

Git提供了 core.autocrlf 配置来解决这个问题：

• Windows用户建议设 true：checkout时把 LF 转成 CRLF，commit时把 CRLF 转回 LF。
• macOS/Linux用户建议设 input：checkout时不转换，commit时把 CRLF 转成 LF。

设置命令：

bash复制git config --global core.autocrlf true

现在大多数初始化良好的仓库会自带 .gitattributes 文件来统一换行符策略，有了它之后 core.autocrlf 的优先级会降低。但如果你接手的是一个老仓库、没有 .gitattributes，手动配好 core.autocrlf 依然是最有效的保护手段。

3.3 中文文件名：一行配置解决乱码

在Windows上用Git时还有一个高频问题：文件名或路径里有中文时，git status 会显示一堆八进制转义字符，比如 "\346\265\213\350\257\225.txt"，完全没法读。

这个问题的根源是Git默认对非ASCII字符做了转义。解决办法就一行：

bash复制git config --global core.quotepath false

配完之后，中文文件名会正常显示。这个配置对中文用户可以说必配，尤其是团队里有人喜欢用中文命名文件时，没有它基本没法工作。

3.4 默认编辑器、初始分支名与配置优先级

如果你是新手，把默认编辑器从Vim换成VS Code能省很多事：

bash复制git config --global core.editor "code --wait"

这样commit时如果需要编辑提交信息，Git会自动打开VS Code，你写完保存关闭窗口就完成了，不用再学“Vim退出大法”。

还有一个时代变化：Git以前初始化仓库时默认分支叫 master，现在主流平台和Git新版本都默认 main。如果你用的Git版本不高不低，可以在配置里显式指定：

bash复制git config --global init.defaultBranch main

最后说一下配置优先级，这个非常实用：Git配置有三级，system（系统级）< global（用户级）< local（仓库级）。也就是说在某个仓库里执行的配置会覆盖全局配置。查看当前所有配置的来源，可以用：

bash复制git config --list --show-origin

排查问题时这个命令能告诉你某个配置到底在哪一层被设置了，非常有用。

4. 日常高频命令：从clone到merge的完整闭环

4.1 第一次拉取代码：git clone

拿到一个远程仓库后，第一步是用 git clone 把它复制到本地：

bash复制git clone https://gitlab.example.com/group/project.git

执行完后，当前目录会多出一个和仓库名相同的文件夹，里面就是完整的项目代码和隐藏的 .git 目录。.git 目录就是本地仓库的核心，它保存了全部提交历史、分支指针、配置信息。日常开发中你不用管它，但别删它——删了本地历史就没了。

如果仓库很大，而你只需要最新代码来跑起来看看，可以用浅克隆：

bash复制git clone --depth=1 https://gitlab.example.com/group/project.git

它只拉取最近一次提交，速度会快很多。但注意，浅克隆会丢失完整历史，后面如果需要 git log 查看以前的提交，会受限。

clone是每个新人入职后做的第一件事，所以我把这一步放在最前面。在clone之前，请确认你有仓库的访问权限，否则会卡在账号密码或权限校验上。

4.2 日常循环：status → diff → add → commit

改代码的日常操作，其实就围绕下面几件事：

1. git status：永远最先执行。它会告诉你当前处在哪个分支、有哪些文件改了、哪些文件还没被跟踪。
2. git diff：查看工作区里具体改了哪些内容。不加参数看的是“已修改但未暂存”的改动；想看暂存区的改动，用 git diff --cached。
3. git add：把文件加入暂存区。git add <file> 只加一个文件，git add . 是加当前目录下所有改动。新手用 git add . 时要小心，容易把临时文件、编译产物一起加进来。
4. git commit -m "feat: xxx"：把暂存区的内容固化成一次历史记录。-m 后面跟的是提交说明。

完整流程写成命令就是：

bash复制git status
git diff
git add src/
git commit -m "feat: add login page"

提交完再用 git status 看一次，确认工作区干净，心里就有底了。

想快速看提交历史，用：

bash复制git log --oneline --graph -10

--oneline 让每个提交只显示一行摘要，--graph 显示分支走向，-10 只看最近10条。这个命令是了解项目演进脉络最直观的方式。

4.3 分支操作：branch、switch、merge

分支是Git最强的功能之一，也是新手最容易懵的地方。理解它有一个简单类比：分支就是平行时空。你在主线上稳定开发，同时在另一个时空里尝试新功能，两个时空互不干扰，最后把新功能合并回主线。

常用命令：

bash复制git branch               # 查看本地分支
git switch -c feature/login   # 创建并切换到新分支
git switch main          # 切换分支
git merge feature/login  # 把feature/login合并到当前分支

git switch 是相对较新的命令，老教程里多用 git checkout -b，两者效果一样。现在Git已经推荐用 git switch 来表示“切换分支”，而 git checkout 还承担着“恢复文件”的职责，命令职责分开后不容易混淆。

合并分支时，如果两边改的是不同文件，Git会自动完成合并；如果改了同一文件的同一处地方，就会产生冲突。冲突不是错误，而是Git诚实告诉你“这里我拿不准，你人来决定”。处理冲突在第6章详细讲。

分支合并完之后，本地和远程的分支清理也有固定动作：

bash复制git branch -d feature/login        # 删除本地分支
git push origin --delete feature/login   # 删除远程分支

4.4 暂存、回退和后悔药：stash、restore、reset

开发中经常会遇到这种情况：手头改到一半，突然需要切分支去修一个紧急bug。直接切分支的话，Git会阻止你，因为当前工作区有未提交的改动。这时候用 git stash 把当前改动先“存起来”：

bash复制git stash
git switch hotfix
# 修完bug
git switch feature/login
git stash pop   # 恢复之前暂存的改动

git stash 相当于一个临时储物柜，适合用来处理“还没改完但要先干别的事”的场景。

还有三个命令经常被并称为“后悔药”，但它们面向的场景非常不一样：

• git restore <file>：丢弃工作区的改动，让文件回到最近一次提交的状态。适用于“改坏了，我不要这些改动了”。
• git restore --staged <file>：把文件从暂存区撤出来，变回“已修改未暂存”的状态。适用于“我add错文件了”。
• git reset --soft HEAD~1：撤销最近一次本地提交，但保留改动内容。适用于“commit信息写错了，想重新提交”。

需要注意：restore 和 reset 只适合处理尚未推送到远程的提交。如果提交已经push到远端，就别用 reset 去“改历史”了，应该用 git revert <commit> 生成一个反向提交来弥补。revert不会重写历史，是团队协作中更安全的选择。

5. 提交规范与免密登录：团队协作的两个基本功

5.1 提交信息：别让你的队友看天书

很多初学者提交时，信息就写一个字：“改”、“update”、“fix”。等过了两个月回来看git log，完全想不起来当时改了什么。如果团队里有5个人都写“update”，那历史记录就彻底失去意义了。

我特别推荐使用Conventional Commits（约定式提交）规范，它的核心是让提交信息有固定格式：

text复制<type>(<scope>): <subject>

其中 type 是类型，常用的有：

• feat：新功能
• fix：修复bug
• docs：文档变更
• style：代码格式调整，不影响逻辑
• refactor：重构，不改功能和bug
• test：增加或修改测试
• chore：构建配置、工具等杂项

scope 是影响范围，可以写模块名，比如 feat(login): 增加短信验证码登录。subject 是简短描述，不要超过50个字符，英文用祈使句，中文直接写清楚干了什么。

一个反例和一个正例对比：

text复制# 不好
update

# 好
fix(cart): 修复购物车数量为0时仍可提交订单的问题

好的提交信息，能让后面的人用 git log --oneline 就能大概读懂这个项目的演进史。在code review时，清晰的提交信息也能帮评审人快速定位意图。坚持写规范的提交信息，短期看只是多花了10秒钟，长期看是在给整个团队降低沟通成本。

5.2 分支命名规范：让分支名称即有信息量

分支名也是团队协作中的沟通语言。推荐一套很通用的规范：

• feature/xxx：新功能分支
• bugfix/xxx：bug修复分支
• hotfix/xxx：紧急线上修复分支
• release/xxx：发布分支
• docs/xxx：文档分支

比如 feature/user-register 一眼就知道是做用户注册功能的。对比一下 dev、test、abc123 这种没有语义的名字，哪套更利于协作就不用说了。

分支规范具体怎么定，每个团队可能略有差异，在加入新团队时先看仓库里的分支命名习惯，跟着既有风格走，比自己强行立一套规则更稳妥。

5.3 免密配置：HTTPS凭证和SSH Key

每次push都输账号密码，用久了人会疯。免密登录有两条主流路线。

第一条是HTTPS + 凭证管理器。Windows安装Git时自带Git Credential Manager，macOS用 osxkeychain，Linux可以配 libsecret。开启后第一次输过账号密码，之后Git自动帮你完成认证。这种方式配置简单，适合刚开始用Git的人。

第二条是SSH Key，也是我更推荐的方式。生成密钥：

bash复制ssh-keygen -t ed25519 -C "you@example.com"

一路回车，默认会在 ~/.ssh/ 目录下生成 id_ed25519（私钥）和 id_ed25519.pub（公钥）。然后把公钥内容复制到GitLab或GitHub的“SSH Keys”设置里。之后clone时用SSH地址，比如 git@gitlab.example.com:group/project.git，push时就不用输密码了。

SSH和HTTPS在功能上没有区别，只是认证机制不同。SSH的好处是密钥对是一次性生成的，长期有效，在服务器上部署时也更方便；HTTPS的优势是纯Web环境也能用，配合token也不麻烦。两者可以共存，不冲突。

5.4 token时代：为什么用密码推不上去了

现在GitHub和很多GitLab实例都已经不允许用账号密码直接push代码了，必须使用Personal Access Token（个人访问令牌）。这是出于安全考虑：token可以设置有效期、限定权限，即使泄露，危害也远小于账号密码泄露。

用的时候，token就当作密码填进去就行。但也正因为token有有效期，你会遇到这类报错：

text复制login failed. check api [token](https://taotoken.net?utm_source=general) or gitlab version.

这通常是IDE里的GitLab插件在登录时提示的。排查思路是：

1. 确认token是否过期，过期就到平台设置里重新生成。
2. 确认token权限够不够，至少要有 read_repository 和 write_repository。
3. 确认GitLab版本是否太老，部分老版本的API和插件不兼容。
4. 如果插件提供“Log in via Git”选项，优先用它，让插件直接调用本机Git已经保存的凭据，绕开token问题。

这类报错的核心是“认证信息失效”，别急着重装IDE，先重新生成token测试。

6. 高频报错排查实录：证书、token、冲突与泄露

6.1 fatal: not a git repository：绝大多数人搞错了目录

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

这可能是新手最常遇到的报错之一。它的意思是：当前目录不在任何Git仓库内，也找不到 .git 目录。

常见原因是命令执行错了地方。比如你clone下来一个项目，但没有先 cd 进项目目录就执行 git status；或者你在子目录里执行Git命令，但子目录本身不是独立的Git仓库。

排除方法很简单：

bash复制git rev-parse --show-toplevel

这个命令会输出当前所在仓库的根目录绝对路径。如果报同样错误，说明确实不在仓库里；如果输出了路径，说明你在仓库内，只是目录层级太深。

另外还有一种少见情况：项目里确实有 .git 目录，但被误删了。这种情况下本地历史全丢，只能重新clone。这也是为什么 .git 目录不能随便删的原因。

6.2 unable to access + error setting certificate file：证书路径问题

很多人第一次从内网GitLab clone代码时，会看到这样一串报错：

text复制unable to access 'https://git.example.com/group/project.git/':
error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt

这个报错可以拆成两层理解：

• unable to access：Git无法访问目标URL。
• error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt：Git在尝试读取CA证书文件时失败了。

Git在做HTTPS请求时，会用这个CA证书文件来校验服务器证书是否可信。如果这个文件路径不对、文件缺失，或者系统时间不正确导致证书校验失败，就会报这个错。

我的排查链路是这样的：

1. 先确认证书文件是否存在。按报错给的路径，去 D:\Git\mingw64\etc\ssl\certs\ 下看看有没有 ca-bundle.crt。如果安装路径不是默认的，证书路径就会对不上。
2. 用 git config --show-origin http.sslCAInfo 查看当前CA证书配置是从哪来的。如果有脏配置，用 git config --global --unset http.sslCAInfo 清掉，让Git用默认路径。
3. 检查系统时间是否准确。系统时间差太多，HTTPS证书校验也会失败，这种问题重新同步时间即可。
4. 如果企业内网用的是自签名证书，可以把内网CA证书追加到 ca-bundle.crt 文件末尾，或者单独指定一个证书文件。

网上有人为了省事直接执行：

bash复制git config --global http.sslVerify false

这个命令的意思是“关闭SSL证书校验”，问题确实能立刻消失，但我强烈不建议这么干。相当于你过安检时直接告诉保安“不用查了，我人品好”，一旦中间有人改动了传输内容，你完全察觉不到。只在明确知道自己连接的是可信内网仓库、且没有其他办法时，才考虑临时关闭，用完了记得改回 true。

6.3 unable to access：网络和代理配置的排查

另一种 unable to access 更常见，报错类似：

text复制Failed to connect to gitlab.example.com port 443: Timed out

或者：

text复制Could not resolve host: gitlab.example.com

这种一般是网络层面问题。排查步骤：

1. 先用 ping 或 curl -I 测试仓库域名是否可达。
2. 检查Git里是否设置了代理：git config --global --list | grep proxy。
3. 如果你之前配置过代理（比如公司内网环境需要走代理出去），但后来切换了网络环境，旧代理配置会导致外网仓库无法访问，这时清掉就好：

bash复制git config --global --unset http.proxy
git config --global --unset https.proxy

4. 还要检查系统环境变量里有没有 HTTP_PROXY、HTTPS_PROXY。有些程序会自动设置这些变量，Git也会读它们。如果有残留，同样需要处理。

这类问题本质上是“Git读到的网络配置和当前网络环境不匹配”。排查时要顺着配置来源一层层找：当前仓库local配置、全局global配置、系统环境变量、系统级system配置。用 git config --list --show-origin 是一把很好用的钥匙。

6.4 merge冲突：看到<<<<<<<不要慌

合并分支时遇到冲突，Git会在冲突文件里插入标记，长这样：

text复制<<<<<<< HEAD
当前分支的内容
=======
被合并分支的内容
>>>>>>> feature/login

<<<<<<< HEAD 到 ======= 之间是你当前分支的内容，======= 到 >>>>>>> feature/login 之间是你要合并进来的内容。

处理办法很直接：打开文件，把不需要的部分删掉，保留最终想要的结果，并且把 <<<<<<<、=======、>>>>>>> 这些标记行也全部删掉，然后 git add 这个文件，再 git commit 即可。

预防冲突的关键是：

1. 提交要小而频繁，不要憋一大坨改动才提交。
2. 每次开始开发前先 git pull 更新本地。
3. 尽量让多人不要同时改同一区域的文件。

但冲突本身不可怕，它只是Git在尽可能保证安全的前提下，把无法自动判断的地方交给人来决策。处理过几次，你就会习惯。

6.5 .git目录泄露：一个容易被忽略的风险

最后聊一个和“热词”有关的安全问题：git目录泄露。

什么叫git目录泄露？如果项目发布到服务器后，.git 目录被放在Web根目录下，而且服务器没有禁止访问 . 开头的文件，那任何人只要访问 https://site.example.com/.git/config，就能直接读到仓库的配置信息。更严重的是，攻击者还能通过 .git 目录里的对象文件拼出完整的源码和历史记录，整个项目的代码就这么暴露了。

这个问题的根源，通常是构建流程不规范：很多人把整个工作目录打包上传服务器，忘了 .git 是隐藏目录，或者服务器配置里没屏蔽点开头的路径。

防御动作很明确：

1. 部署时不要把仓库根目录直接作为Web根目录。
2. 服务器上建议加规则禁止访问 . 开头的路径或文件。
3. 构建产物里不要包含 .git 目录，最好用构建工具只拷贝必要文件。
4. 定期检查生产环境，浏览器直接访问 /.git/config，如果返回了内容，说明已经泄露了。

git目录泄露在安全圈算一个高频问题，很多企业SRC漏洞报告里都有它。作为开发者，理解它的原理和危害，比出事了再补救要省心得多。

7. 工具链搭配：命令行之外，还有这些让Git更好用的选择

7.1 VSCode / Cursor 的Git集成

现在很多人的主力编辑器是VSCode或基于它改造的Cursor。它们内置了Git支持，左侧“源代码管理”面板（快捷键 Ctrl+Shift+G）可以看到当前仓库的状态、改动文件列表、输入提交信息、甚至直接推送。

在Cursor里，“哪里查看绑定git”这个问题经常被问到。实际上和VSCode一样：先打开命令面板（Ctrl+Shift+P），输入“Git: 打开源代码管理”，或者