NewbeeSmart上篇写git基础操作的时候，被问到最多的不是怎么commit，而是合并冲突怎么办、文件改乱了怎么恢复、为什么push老要输密码。说实话，这才是git使用者的真实日常：命令谁都能敲，真正决定用得顺不顺手的是遇到问题后能不能快速定位原因。这篇就奔着这些高频问题来，我把平时帮同事排查过几十次的场景重新整理了一遍，适合已经会add、commit、push，但对合并、回退、免密、报错还心里没底的开发者。文章不按文档顺序讲命令，而是按“你真正会碰到的场景”来组织，每段都可以直接落地。
1. 分支合并与冲突处理：从 merge 到 rebase 的实战选择
1.1 动手前先定分支策略，这部分省不了
我见过不少小团队，仓库拉下来就一个main分支，所有人直接在上面提交。前两周还没事，等代码量上来，一次上线要回滚某个功能时，谁都不敢动了。没有分支策略的仓库，本质上是在用“信任”对抗“混乱”，短期看省事，长期看是给自己埋雷。
小团队落地不需要多复杂的分支模型，记住一条主线就行：main分支保持可发布状态，开发需求时从main拉出特性分支，写完经review后再合回main。这条规则能覆盖80%的场景。分支命名建议带上类型和主题，比如feature/order-export、fix/login-timeout、release/v1.2.0。别小看命名规范，它能让git branch列出的历史一眼可读，也让后续的自动清理脚本有规则可依。
动手写代码前，先确认自己在正确的分支上：
bash复制git checkout main
git pull origin main
git checkout -b feature/order-export
这套命令的含义是：先切到main，拉取远端最新代码，然后基于这个最新状态创建并切换新分支。很多人图省事直接git branch feature/xxx再git checkout feature/xxx，效果一样，但-b一步到位更少出错。记住一点：从旧代码上拉分支，后面合回main时大概率会撞上别人改过的文件，这不是git的问题，是你拉分支的时机不对。
1.2 merge 和 rebase 的区别：一次说清
merge和rebase是git里最容易被拿来对比的两个命令，也是被误解最多的。两者的目标都是“把另一条分支的提交整合进当前分支”，但处理历史的方式完全不同。
git merge会创建一个新的合并提交（merge commit），把两条分支的历史“焊接”在一起。优点是历史真实，能看到哪些提交来自哪个分支，回滚时也能整体回滚到合并前。缺点也很明显：merge commit多了之后，历史图看起来像一张蜘蛛网，尤其多人并行开发时，git log --graph基本没法看。
git rebase做的事情是“搬移提交”：把当前分支上独有的那几次提交摘下来，依次重放到目标分支的最新提交之后。这样一来，提交历史变成一条直线，干净清晰。代价是重放过程中会重写这些提交的哈希值，本质上等于“改写历史”。
所以在项目里的选型经验是：
- 公共分支之间整合代码，用
git merge，不修改公共历史，大家pull下来都会觉得踏实； - 自己维护的特性分支要同步主干的最新代码，用
git rebase，既能避免无意义的合并提交，又方便后续review； - 绝对不要对多人共用的公共分支执行
git rebase。一旦别人基于旧历史工作，你重写历史后，他下次pull会看到一堆莫名其妙的重复提交，甚至直接冲突到生无可恋。
具体操作上，两种命令都很简单：
bash复制# 在特性分支上同步main的最新代码
git fetch origin
git rebase origin/main
# 或者选择merge
git merge origin/main
如果rebase过程中发现冲突太多、处理不下去，不用硬扛，随时可以逃跑：
bash复制git rebase --abort
这个--abort命令是rebase的保命符：它会把一切恢复到rebase开始之前的状态。我处理过不少次同事把rebase做到一半想切回别的分支干活的场景，正确做法不是硬切，而是先--abort或者rebase --continue把当前流程结束再走。git的状态是全局的，中间状态没结束，切分支会失败或带出诡异现象。
1.3 冲突解决：不要无脑接受任何一边
先说透冲突的本质：git不是不知道“哪份代码正确”，而是它不打算替你猜。同一个文件的同一行，两边都有了不同版本的修改，git无法判断哪个是你的意图，只能把选择权交给你。
冲突发生时，git会在冲突文件里插入标记，长这样：
text复制<<<<<<< HEAD
这边是当前分支的内容
=======
这边是正在合并进来的内容
>>>>>>> feature/order-export
看到这个结构，正常处理流程是：
git status查看哪些文件冲突；- 打开冲突文件，逐段搜索
<<<<<<<； - 对每一段冲突，判断应该保留哪一边，或者两边都保留并做整合；
- 删除所有冲突标记，包括
<<<<<<<、=======、>>>>>>>三行； - 保存文件后执行
git add； - 如果是merge，直接
git commit；如果是rebase，执行git rebase --continue。
这里有个非常常见的误区：merge冲突解决完后，有人直接执行git commit，结果git提示“no changes”或者“nothing to commit”，当场就懵了。原因在于，git认为“冲突解决完成”的标记是文件被git add进暂存区，而不是文件内容修改完成。先git add，再git commit，顺序不能反。
再说说冲突内容的判断。我的习惯是打开冲突文件后，先不急着删标记，而是把两边的代码都看一遍，搞清楚它们的意图差异。常见的三种情况：
- 两边改了不同方法，只是位置相邻：两个都保留，去掉标记即可；
- 同一处逻辑两边都改了，但功能不同：需要找review的同学确认，保留哪个或合并两者；
- 一边是重构后代码，一边是旧代码：以重构方向为准，必要时查提交历史确认谁是“最新意图”。
处理完冲突别急着提交，先把测试跑一遍。我见过太多人冲突解决了、编译也过了，结果逻辑被拼错，上线后出问题。冲突解决是最需要冷静处理的场景，别省那几分钟测试时间。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件恢复与版本回退：restore、reset、reflog 的正确打开方式
2.1 三个区的状态先对号入座
git目录下每个文件都可以处于多种状态，深入理解之前，先记住一个简化的模型：文件会经过“工作区 → 暂存区 → 版本库”这三个位置。
工作区就是你本地看到的文件；暂存区是git add之后存放内容的中间区域，代表“下次提交要包含哪些文件”；版本库是git commit后生成的提交历史。日常执行git status，它输出的每一行都在告诉你文件目前停在哪个区。
| 文件状态 | 对应场景 | git status显示 |
|---|---|---|
| 未跟踪 | 新建文件，还没add过 | Untracked files |
| 已修改未暂存 | 跟踪过的文件被改动，还没add | Changes not staged |
| 已暂存未提交 | 已add，还没commit | Changes to be committed |
| 已提交 | 已commit | nothing to commit, working tree clean |
很多新手看到git status的输出不懂“为什么同样是改动，有的在Changes not staged，有的在Changes to be committed”，其实就是因为一个还没add、一个已经add了。这个表格记住后，下面几种“后悔药”就都好理解了。
2.2 只想丢掉工作区的改动：git restore 文件
最经典的场景：改进度一半的文件突然改乱套了，或者老板说这版本的改动不要了，你想把某个文件干净地恢复成之前的样子。这时候用的是git restore。
bash复制git restore src/utils/format.ts
这条命令的作用是用版本库里的内容覆盖工作区文件，丢弃对该文件的所有未提交修改。想一次性恢复多个文件：
bash复制git restore .
注意，git restore .会把当前目录下所有已跟踪文件的本地改动全部覆盖掉，非常猛。执行前务必先git status确认没有需要保留的改动。老版本的git没有restore命令，大家习惯写git checkout -- <file>，两者等价，新项目直接用restore即可。
这里有一条重要的安全提醒：git restore是不可逆的。它不像编辑器里有撤销，被覆盖的改动直接没了。我在执行前通常会把文件先复制一份出来，或者先git diff看一眼到底有哪些改动，确认这些改动确实不需要了再动手。
2.3 已经把文件 add 了怎么办：git restore --staged
另一个高频场景是git add .之后突然发现有个文件不该提交，比如误加了.env配置或者临时调试文件。这时候改动还在暂存区，没有形成提交，处理方式是：
bash复制git restore --staged src/config.ts
--staged参数的意思是“把文件从暂存区撤回到工作区”，文件内容不会被改动，只是不再处于待提交状态。老命令写法是git reset HEAD src/config.ts，效果一样。
还有一种情况是：既想从暂存区撤回，又想把工作区的改动也一起丢掉。可以用：
bash复制git restore --staged --worktree src/config.ts
--staged管暂存区，--worktree管工作区，两个一起用就是“完全回到上一次提交的状态”。这组参数适合“我代码写乱了，而且也不想提交”的场景。
2.4 提交之后后悔：reset 和 reflog 组合拳
提交完才发现漏了文件、或者提交信息写错了、甚至整个提交就是不该存在的，这个时候要动用git reset。
git reset的核心是“把当前分支指针移动到你指定的提交”，根据参数不同，对三个区的影响也不同：
| 参数 | 移动分支指针 | 暂存区 | 工作区 | 典型场景 |
|---|---|---|---|---|
--soft |
是 | 不动 | 不动 | 撤销commit但保留所有改动，重新提交 |
--mixed（默认） |
是 | 清空 | 不动 | 撤销commit和add，但保留文件改动 |
--hard |
是 | 清空 | 覆盖 | 彻底丢弃提交和所有改动 |
撤销最近一次提交但保留所有改动，最常用的是：
bash复制git reset --soft HEAD~1
HEAD~1表示“当前提交的上一个提交”。执行后，刚才那次提交的内容会回到暂存区，你可以补上遗漏文件再重新git commit。如果连暂存区也不想要，用git reset HEAD~1，改动会回到工作区，相当于commit和add都撤销了。
至于git reset --hard，我的建议是：在你没有百分之百确认这些改动都不需要时，不要用。因为--hard会直接覆盖工作区文件，如果你有未提交的改动，它们也会一并被丢掉。
那如果已经--hard了，发现丢了一个提交怎么办？git有个隐藏的后悔药机制：reflog。它记录的是“HEAD指针变动历史”，包括reset、rebase、checkout等所有操作。找回操作很简单：
bash复制git reflog
输出里每一行都是一个曾经的HEAD位置，找到你要回退到的那个提交的哈希值，然后：
bash复制git reset --hard <commit-hash>
就能把分支指针挪回去，被“丢掉”的提交又回来了。我自己用这个方法救回过不止一次误操作，包括误删分支后的恢复。前提是那个提交还没被git的垃圾回收机制清理掉，通常几个月内都没问题。
2.5 从历史提交恢复某个文件
最后一种场景：不是想回退整个提交，而是想把某个文件恢复到以前某个版本。比如线上出了问题，怀疑是某次重构把逻辑改坏了，想看看一个月前这个文件长什么样。
bash复制git restore --source=abc1234 -- src/utils/format.ts
--source=abc1234指定从哪个提交取文件，后面跟文件路径。老一点的做法是用git show abc1234:src/utils/format.ts > src/utils/format.ts，效果类似。两者的区别是git restore一步到位，git show是手动重定向，本质上都是“从历史提交里取出该文件覆盖当前文件”。
注意这里的abc1234可以是完整的提交哈希，也可以是前缀。git支持输入哈希的前几位，只要在当前仓库里能唯一识别。拿不准就先git log --oneline查一下。
3. 免密配置与远程仓库：SSH 与 HTTPS 的选择逻辑
3.1 先弄明白现在用的是哪种协议
很多人对免密的困惑，根源是没搞清remote地址走的是哪条路。执行一下：
bash复制git remote -v
如果输出的是https://github.com/用户名/仓库.git，走的是HTTPS协议；如果输出是git@github.com:用户名/仓库.git，走的是SSH协议。两种协议的“免密”方案完全不同。
| 协议 | 默认端口 | 免密方式 | 适用场景 |
|---|---|---|---|
| HTTPS | 443 | Git Credential Manager / token | 公司统一认证、首次配置简单 |
| SSH | 22 | SSH密钥对 | 个人长期使用、服务器部署 |
很多人对“选哪个”没有概念，实际经验是：个人开发推荐SSH，密钥配置好后不需要反复输入；企业环境如果使用了统一身份认证平台，HTTPS配合凭据管理器反而更省事，因为密码由组织统一管理，SSH密钥反而不方便绑定。
3.2 HTTPS 下的凭证管理：为什么没人让你输密码了
Windows上安装git官方安装包时，默认会安装Git Credential Manager。它的工作方式是：第一次git clone或git push时弹出一个登录窗口，你完成认证后，凭证会被加密存入Windows凭据管理器，之后git自动取用，不再弹窗。
用下面的命令查看当前使用的凭证工具：
bash复制git config --global credential.helper
常见的返回值有三种：
manager或manager-core：走Git Credential Manager，加密存储，推荐；store：明文存储在~/.git-credentials文件里，不推荐，安全性差；cache：临时缓存在内存里，过一段时间过期，需要重新输入。
如果你用的是store，建议换成manager：
bash复制git config --global credential.helper manager
如果公司要求使用Access Token而不是密码，只需要在HTTPS地址里以token作为用户名输入一次，之后由凭据管理器记住，不需要把token写死在remote地址里。我见过有人图方便在clone地址里直接拼用户名密码：
bash复制git clone https://用户名:密码@github.com/xxx/yyy.git
这种写法千万要避免，地址一旦出现在命令行历史、脚本或者聊天记录里，等于把密码拱手送人。token也一样。
3.3 SSH 免密配置完整流程
SSH免密的思路很简单：本地生成一对密钥，公钥放在Git平台，私钥留在本地。每次连接时，服务器用公钥验证你的身份，不再需要打密码。流程如下。
第一步，生成密钥：
bash复制ssh-keygen -t ed25519 -C "your_email@example.com"
-t ed25519指定密钥类型，这是目前推荐的算法，安全性高且文件更短。如果你的Git平台比较老、不支持ed25519，再用-t rsa -b 4096。生成过程会问保存路径和密码短语（passphrase），直接回车使用默认路径即可。passphrase建议设置一个，这样即使私钥泄露，对方也需要密码才能用。
第二步，查看公钥内容并复制：
bash复制cat ~/.ssh/id_ed25519.pub
Windows下也可以执行notepad ~/.ssh/id_ed25519.pub打开，写的是公钥，可以放心复制，不会泄露私钥。
第三步，把公钥粘贴到Git平台的SSH Keys设置页。不同平台入口不一样，但都是“设置 → SSH Keys”这个位置，命名随意，key内容粘贴后保存。
第四步，验证是否配置成功：
bash复制ssh -T git@github.com
如果配置成功，会看到类似Hi 用户名! You've successfully authenticated的提示。需要注意，第一次连接某个主机时，ssh会询问是否信任该主机的指纹，输入yes回车即可，这一步生成~/.ssh/known_hosts记录，之后不再询问。
SSH配置失败最典型的几个原因：公钥复制时少了最后的换行或字符、粘贴到了平台但没保存成功、使用多台电脑但没在每台机器上配置密钥。每台机器的密钥对都是独立的，换电脑就得重新配一遍。
3.4 多个账号多个平台：config 文件管理
一个容易被忽视的问题：如果你有GitHub、GitLab、公司自建Git仓库多个账号，每个账号的密钥不同，ssh默认只会用id_ed25519去认证，导致配了GitHub的密钥，公司仓库却连不上。
解决办法是在~/.ssh/config里为不同域名指定不同的密钥文件：
text复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
Host gitlab-work
HostName gitlab.example.com
User git
IdentityFile ~/.ssh/id_ed25519_work
注意Host名是“别名”，可以自己起。配置后，公司仓库地址里的域名要写成别名：
text复制git@gitlab-work:group/project.git
这样ssh会读取config，用~/.ssh/id_ed25519_work去连接gitlab.example.com。没有config的情况下，也可以临时用环境变量指定密钥：
bash复制GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519_work" git clone git@gitlab-work:group/project.git
不过这种写法只对当前命令生效，适合应急，长期用还是配config干净。
3.5 clone 的进阶细节
git clone是很多人用的第一个命令，但它的默认行为其实藏了不少信息。默认clone会拉取所有分支的引用，但只在你本地创建一个分支：远端默认分支（一般是main）。其他分支以origin/xxx的形式存在于本地，查看：
bash复制git branch -a
想直接切换到某个远端分支：
bash复制git checkout -b dev origin/dev
如果只是临时看代码、不打算参与开发，浅克隆能省很多流量和时间：
bash复制git clone --depth=1 https://github.com/xxx/yyy.git
--depth=1表示只拉取最近一次提交，历史记录不会下载。之后如果想补全历史，再执行git fetch --unshallow。
指定克隆到某个目录名：
bash复制git clone https://github.com/xxx/yyy.git 新目录名
这些细节虽然不常用，但理解了clone的原理，就不会遇到“我clone完了怎么只有main分支”这种疑问。
4. 高频报错排查实录：环境变量、证书路径与登录态
4.1 “git不是内部或外部命令”与“无法将git项识别为cmdlet”
Windows用户最常遇到的第一个git报错，就是在cmd或PowerShell里输入git --version，系统说“不是内部或外部命令”。这个报错的本质是：git.exe所在的目录没有被加入到系统的PATH环境变量里，shell根本找不到这个程序。
常见原因有两个：一是安装git时没有勾选“将Git加入PATH”的选项，很多精简安装包默认不勾；二是安装后没有重启终端，PATH变更要新开的窗口才会生效。
验证方式很简单，在cmd或PowerShell里执行：
bash复制where git
如果返回一段路径，说明git能找到；如果提示找不到，那就去系统环境变量设置里，把git安装目录下的cmd文件夹加进PATH。git bash不受这个问题影响，因为git bash启动时会把git的目录自动加入自己的环境里。所以很多人发现“git bash里能用，cmd里不能用”，其实就是PATH的问题。
这个报错在vscode的集成终端里也会出现。vscode集成终端继承系统环境变量，如果安装git后没有重启vscode，或者vscode启动时PATH还没更新，同样会报这个错。处理方式就是重启vscode窗口。
4.2 证书路径报错：error setting certificate file
这个报错相对进阶，它长这样：
text复制error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt
出现的原因是git在做HTTPS请求时，需要CA根证书来验证远端服务器的SSL证书，但配置指向的证书文件路径无效或文件损坏。这个路径通常来自三个地方：git config --system里的http.sslCAInfo、git config --global里的http.sslCAInfo、或者环境变量GIT_SSL_CAINFO。
排查顺序：
bash复制git config --system --list | findstr ssl
git config --global --list | findstr ssl
如果发现http.sslCAInfo指向的路径不对，可以修正：
bash复制git config --global http.sslCAInfo "D:/Git/mingw64/etc/ssl/certs/ca-bundle.crt"
注意Windows路径在git配置里最好用正斜杠或者转义后的反斜杠。很多人的问题是用了别人的配置文档，拷贝了一个本机不存在的路径。这种情况，直接删掉错误的配置项让它用默认值也行：
bash复制git config --global --unset http.sslCAInfo
还有一种情况是公司内网使用了自签名证书，git默认不信任，会报SSL certificate problem。正规做法是把公司CA证书添加到系统的受信任根证书存储，然后让git使用系统证书库，或者在git配置里指向公司提供的证书文件。千万不要为了图省事直接改成http.sslVerify false，那是关掉了所有HTTPS校验，等于把数据裸奔在网络上。
4.3 unable to access 系列：网络不可达或代理残留
unable to access是完整报错的前半句，后半句通常还有几种变体：
Could not resolve host: xxx：域名解析不了，地址可能输错了；Failed to connect to xxx port 443: Connection refused：服务器拒绝连接，网络不通或端口被封；Connection timed out：连接超时，网络链路上有问题。
这类问题的排查顺序我建议这样：
- 用浏览器打开仓库地址，看页面能不能正常访问；页面能打开而git连不上，问题基本就出在git的配置上；
- 确认域名解析，Windows下
ping 域名或者nslookup 域名； - 检查端口连通性，Windows PowerShell里执行
Test-NetConnection github.com -Port 443； - 查看git配置里是否有残留的代理设置：
bash复制git config --global --get http.proxy
git config --global --get https.proxy
如果返回了代理地址，而当前网络环境根本不需要走代理，把它清掉：
bash复制git config --global --unset http.proxy
git config --global --unset https.proxy
系统环境变量HTTP_PROXY和HTTPS_PROXY也会被git读取，有残留同样会影响。这类“以前配置过代理，后来换了网络环境忘了清理”的情况非常常见，很多人折腾半天才发现是代理残留。
还有个很不起眼但经常犯的错误：从网页复制clone命令时，把后面的cd 目录名也一起复制了，一顿回车后命令行解析出奇怪的结果。比如git clone https://xxx.gitcd 目录名，git把整段当成URL，自然报unable to access。遇到莫名其妙报错时，先回看命令本身是不是被拼接乱了。
4.4 “login failed. check api token or gitlab version”
这个报错经常出现在IDE插件、脚本或者命令行工具连接GitLab时，它不是git clone或git push这类常规操作报的错，而是“程序调用GitLab API”时报的。
GitLab API和git本身的协议是两码事：git push/clone走的是HTTP或SSH协议，认证靠账号密码或SSH密钥；API走的是单独的REST接口，认证靠Access Token。所以排查思路也不一样：
- token是否过期。GitLab的token可以设置有效期，过期后API就返回认证失败，登录GitLab后台重新生成一个；
- token的权限范围（scope）是否包含了需要的操作。比如只勾了
read_repository，但脚本要做提交操作，权限就不够； - GitLab实例版本是否过旧。某些老版本的私有化GitLab，新生成的token格式不兼容，也要换一种处理方式；
- 确认工具里配置的API地址是不是这个GitLab实例的地址，很多人配置了默认的
gitlab.com，实际用的是公司内网实例，地址对不上自然登录失败。
处理这个报错时，先看清楚是谁在报错。如果你是在IDE里打开项目同步时遇到，大概率是IDE的GitLab插件需要重新配置token；如果你是用命令行工具，检查工具的环境变量。别一上来就重装git，方向错了浪费一晚上。
4.5 TortoiseGit 和 VSCode 背后的 git 命令
很多人用TortoiseGit、VSCode这类图形工具，遇到报错就完全懵了，因为看不到底层在干嘛。其实GUI工具只是在调用git命令行，明白这点后，很多问题都能迎刃而解。
比如复制小乌龟（TortoiseGit）执行的操作，你会看到一条超长命令：
text复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks ...
这三段其实是git的“临时配置”语法：-c key=value表示只在本次命令运行时生效，不改全局配置。diff.mnemonicprefix=false的意思是diff输出里不显示a/、b/这类前缀，让界面更干净；core.quotepath=false表示文件名里的非ASCII字符（比如中文）直接显示而不是转义；--no-optional-locks是告诉git不要为一些操作获取可选锁，避免和后台进程冲突。
理解了这一点，你再遇到“TortoiseGit提交报错”时，就知道去命令行里手动跑一遍同样的git命令，看完整输出。图形工具往往把报错信息浓缩成一个弹窗，反而丢失了细节。VSCode自带的源代码管理面板也是同理，它显示的每次提交、每次拉取，底层都是git commit、git pull。在VSCode的设置里，把git.path指向git可执行文件，如果vscode集成终端里git命令可用而GUI不可用，多半就是这个路径配置出问题了。
5. 提交规范与目录安全：历史可读，仓库不外泄
5.1 提交信息格式化：让历史可以被阅读
git commit -m "修改了bug"这种提交信息，写的时候自己觉得清楚，一个月后回来看，完全不知道改了哪里、为什么改。团队协作里，提交信息就是另一种文档，它不是写给自己看的，是写给未来的协作者看的。
目前业界比较通用的格式是type(scope): subject，比如：
text复制feat(order): 新增导出功能
fix(login): 修复登录超时问题
docs(readme): 更新部署说明
type是提交类型，scope是影响范围，subject是一句话描述。常用类型对照：
| type | 含义 | 典型场景 |
|---|---|---|
| feat | 新功能 | 新增接口、新页面 |
| fix | 修复 | 修bug、解决缺陷 |
| docs | 文档 | README、注释、接口文档 |
| style | 格式 | 格式化、调整空格、修分号 |
| refactor | 重构 | 不改功能只改结构 |
| perf | 性能优化 | 优化查询、减少渲染 |
| test | 测试 | 新增用例、修改测试 |
| chore | 杂项 | 构建配置、依赖更新 |
好的提交信息应该描述“为什么这么做”，而不只是“做了什么”。比如：
text复制fix(order): 修复大单导出超时
原因是导出逻辑里对每条明细执行独立查询，改为批量查询后，万级数据导出时间从80秒降到5秒
第一次提交的人可能觉得写这么详细浪费时间，但一次线上事故排查时，好的提交信息能直接告诉你“这个改动的动机是什么”，省掉大量翻阅代码的时间和沟通成本。
5.2 .gitignore 与已经被跟踪的文件
每个项目的第一件事，就是配好.gitignore。它的作用是告诉git“哪些文件不要纳入版本管理”。常见的规则：
text复制node_modules/
dist/
build/
*.log
.env
.idea/
.vscode/
.DS_Store
.gitignore本身不会影响已经纳入版本管理的文件。如果你之前已经把config.js提交进仓库了，后来在.gitignore里写上config.js，git不会自动停止跟踪它。这个文件依然在你的仓库里，照样会被推送到远端。
正确的处理方式是从git的索引里移除，但保留工作区文件：
bash复制git rm --cached config.js
--cached只从暂存区/索引移除，不删本地文件。执行后git status会显示deleted: config.js，实际上本地文件还在，commit之后，远端仓库里就不再跟踪这个文件了。
5.3 别让 .git 目录变成公开资料库
.git目录是git仓库的心脏，里面有完整的提交历史、全部分支、配置信息，甚至可能包括曾经误提交过的密码、密钥、敏感文件的路径。很多开发者习惯把整个项目目录上传到服务器时用scp或直接打包，一不小心就把.git目录也带过去了。如果服务器把静态文件直接对外可访问，任何知道git内部路径的人都可以按.git/HEAD、.git/config这样的标准路径去访问部分内容，进而尝试恢复整个源码。
这是一个防御性的建议：部署时明确排除.git目录，比如打包命令里排除它，或者在静态服务器的配置里禁止访问以.开头的目录。更重要的是，不要在仓库里提交.env、密钥文件、生产数据库连接串这类敏感信息。只要它们进过提交历史，即便后来删掉，历史里仍然能找到。
5.4 小乌龟与VSCode插件的高效配合
命令行是git的根，但日常场景里图形工具确实能提高效率。TortoiseGit在Windows上的优势是文件右键就能看到状态、diff、日志，适合快速对比某个文件的改动。VSCode搭配GitLens和Git Graph插件，可以直观看到每行代码的最后提交者、提交时间，以及分支合并的可视化图。
我个人的分工经验是：常规操作看状态、看diff用GUI，比如VSCode的源代码管理面板；涉及分支操作、历史改写、复杂冲突处理、报错排查，切回命令行。原因很简单，GUI把很多细节隐藏了，比如rebase中途的状态、reset的具体参数，GUI上很容易点错，命令行反而能一眼看到当前处于什么状态、下一步该执行什么。
这种搭配方式也有一个前提：至少要把命令行的基础操作练熟。图形工具能帮你“看到”问题，但“理解”问题还是靠命令行。真遇到疑难杂症时，打开终端，用自己敲过的命令一步步排查，才是最快路径。
最后再分享一个实际工作中的体会。git操作里的绝大多数问题，都不是“命令不够熟”，而是“状态没搞清楚”。不确定该不该reset --hard、该不该push -f的时候，先开一个终端执行git status，看清楚当前在哪个分支、哪些文件有改动，再决定下一步。真操作错了也别慌，reflog是最后的后悔药。把这篇文章里的场景亲手过一遍，之后遇到git报错，基本就不用百度了。