莫魔墨Git这种东西，说难不难，说简单也真不简单。我见过不少朋友折腾一整天，卡在环境变量上，也见过有人用了几年Git，碰到一次误删分支直接愣住。这篇东西我不打算像官方文档那样罗列命令，而是想站在一个“天天在用Git干活”的角度，把新手最容易卡住的地方、最该先搞懂的概念，以及那些报了错却不知道去哪查的问题，一次性讲清楚。如果你正准备学Git，或者已经入了门但总感觉哪里没打通，这篇文章应该能帮你把链路捋顺。
1. 为什么我劝每个新手都先把Git学明白
1.1 版本管理的本质：不是备份，是时间旅行
很多刚接触编程或文档协作的朋友，对版本管理的理解停留在“多存几个文件副本”。于是你会看到这样的目录：论文最终版.doc、论文最终版2.doc、论文最终版3_再也不改了.doc。Git要解决的，恰恰就是这个问题。
Git管理的不是一个文件的“拷贝”，而是整个项目的“历史快照”。每一次提交（commit），都相当于给当前所有文件拍了一张照片，并且记下了“谁在什么时间，因为什么原因，把哪些文件改成了什么样”。你想回到过去任意一个时间点，随时可以；你想看看某个文件昨天是什么样子，一行命令搞定；你想知道某行代码是哪个憨憨写的，git blame会告诉你答案。
这个能力带来的价值，远远超过“防手滑”本身。它让你在尝试新方案时不再畏手畏脚，因为你知道就算改崩了，也能一键回到上一个能跑的状态。这种安全感，是任何备份软件都给不了的。Git本质上就是给你的项目装上了一台时间机器，而你只需要学会几个操作手柄。
1.2 新人最容易掉进去的三个误区
结合我这些年看到的案例，新手学Git最容易陷入三个误区。
第一个误区是把Git当成网盘。以为git push就是把文件传到云端，git pull就是把文件拉下来。这个理解方向没错，但很容易让人忽略一个关键事实：Git的所有操作都是先在本地完成的，远程仓库只是你本地历史的一个“镜像”。如果你没搞懂本地仓库和远程仓库的关系，后面碰到“分支落后”“代码冲突”就会一头雾水。
第二个误区是只记命令、不理解状态。网上很多教程上来就是git add、git commit、git push三步走，新手照抄几遍也能跑通，但一旦出现异常（比如commit完之后发现漏了个文件），就完全不知道怎么办了。原因在于不理解Git对文件的管理状态变化。这个我在第三章会详细拆。
第三个误区是遇到报错就重装。Git的报错信息其实已经告诉了你问题在哪，只是新手不知道去哪看。比如Failed to connect to github.com port 443、error setting certificate file这些，其实都是环境或网络配置问题，重装一百遍也没用。后面我会专门写一节排查高频报错，建议你先收藏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零到一：安装、配置、跑通第一条命令
2.1 各平台安装避坑点
Windows平台
Windows下装Git，主流方式是去官网下载安装包，或者用winget install Git.Git命令行安装。官网地址是git-scm.com，如果下载速度慢，可以改用国内镜像，很多高校和企业都提供同步源，搜“Git镜像下载”就能找到。安装过程中有几步比较容易踩坑，我单独说一下：
-
调整PATH环境变量：安装到“Adjusting your PATH environment”这一步，一定要选中间那个“Git from the command line and also from 3rd-party software”。如果选了默认的“Git Bash only”，后面你在CMD或PowerShell里输入
git就会提示“git不是内部或外部命令”。 -
换行符转换方式：在“Configuring the line ending conversions”这一步，Windows用户建议选第一个“Checkout Windows-style, commit Unix-style line endings”（默认选项）。这个选项会在你拉代码时把换行符转成Windows格式，提交时再转回Unix格式，能避免很多跨平台协作的换行符问题。
-
SSH可执行文件：如果你的电脑上装了OpenSSH（Windows 10以上一般自带），安装时可以选择使用Windows自带的OpenSSH，也可以使用Git自带的。我的建议是用Git自带的，因为后续配置多密钥时会灵活一些。
macOS平台
macOS上最简单的方式是安装Command Line Tools，终端里输入xcode-select --install会弹出安装提示。也可以用Homebrew装，brew install git。两者差别不大，Homebrew装的版本会新一些。如果系统里没装过任何开发工具，xcode-select会自动装好Git、Clang这些基础工具链。
Linux平台
Debian/Ubuntu系用sudo apt install git，CentOS/RHEL系用sudo yum install git。Linux下装Git基本不会遇到PATH问题，装完直接就能用。
2.2 提交前必做的四项身份配置
装完Git之后，第一件事不是急着clone代码，而是配置你的身份信息。这一步不做好，你提交的代码会显示成别人的名字，或者干脆提交失败。
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
这两条配置会写入用户主目录下的.gitconfig文件，属于“全局配置”，对你机器上所有仓库生效。如果是公司的项目，可能要求用公司邮箱和个人昵称，这时候可以在仓库目录内单独执行git config user.name（不加--global），覆盖全局配置。
除了用户名和邮箱，另外两个配置建议你顺手做掉：
bash复制git config --global init.defaultBranch main
git config --global core.autocrlf input
init.defaultBranch main的意思是，以后执行git init创建新仓库时，默认分支叫main而不是master。现在各大托管平台的新仓库默认分支都改叫main了，本地和远端保持一致，能省掉后面改分支名的麻烦。
core.autocrlf input是给macOS/Linux用户准备的跨平台换行符策略。Windows用户如果安装时选了第一项，Git会自动帮你配好core.autocrlf true，不用手动改。这里多说一句：换行符问题看起来不起眼，但跨平台协作时很容易出现“我什么都没改，Git却显示整个文件都被修改了”的情况，根源就是换行符不一致。
2.3 验证安装是否成功
配置完成后，打开终端（Windows下开CMD、PowerShell或者Git Bash都行），输入：
bash复制git --version
能输出git version 2.xx.x这样的信息，说明安装成功。接着输入：
bash复制git config --list
会列出当前所有生效的配置项，检查一下user.name和user.email是不是你刚设置的。
做完这一步，你的Git环境就准备好了。整个过程只需要几分钟，但很多新手恰恰卡在这一步——装好了却说git命令找不到。如果你也是这种情况，先别急着重装，直接跳到第六章的报错排查。
3. 工作区、暂存区、版本库：提交前必须理解的核心模型
3.1 三个区域的分工
Git管理文件的方式，很多教程都用“三层结构”来解释：工作区（Working Directory）、暂存区（Staging Area/Index）、版本库（Repository）。我见过太多新手因为不理解这三个区域的关系，把git add、git commit用成了肌肉记忆，一出问题就懵。
打个比方：你在写一份PPT，工作区就是你的桌面，所有文件都摊在这里，你能看到、能编辑。暂存区是一个“待提交清单”，你告诉Git“这次提交就打包桌上这些东西”，然后把这些文件放进一个筐里。版本库则是仓库的档案室，每次提交就是把筐里的东西正式归档，盖上时间戳和作者签名。
具体到文件操作上，一个文件的完整状态流转是这样的：
- 新建或修改文件后，它处于未跟踪（Untracked）或已修改（Modified）状态。
- 执行
git add <file>后，文件被放进暂存区，处于已暂存（Staged）状态。 - 执行
git commit后，暂存区的内容被固化到版本库，生成一个不可变的提交记录。
整个过程可以用git status随时查看。这个命令会明确告诉你：哪些文件被修改了、哪些文件被暂存了、哪些文件还没被追踪。每次操作前后都看一眼git status，是避免误操作最有效的习惯。
3.2 首次提交与.gitignore
我们用一个实际场景走一遍。假设你新建了一个项目目录，里面有一个index.html和一个README.md，还有一堆自动生成的日志文件。执行：
bash复制git init
这个命令会把当前目录初始化为一个Git仓库，然后执行：
bash复制git add index.html README.md
git commit -m "feat: 初始化项目"
第一条命令把两个文件加入暂存区，第二条命令生成第一个提交。这里有一类文件是我们不想提交的：日志文件、编译产物、本地配置文件。对于这些，需要在项目根目录创建一个.gitignore文件，把要忽略的规则写进去：
text复制# 日志文件
*.log
# 编译产物
dist/
build/
# 依赖目录
node_modules/
# 系统文件
.DS_Store
.gitignore本身是一个普通的文本文件，但它会被Git特殊对待：匹配到的文件会被自动忽略，git status不会显示它们，git add .也不会把它们加进去。项目创建时先写好.gitignore，能省掉后续很多麻烦。别等到把node_modules提交进仓库之后再后悔，那时候清理起来费劲不说，仓库还会变得很臃肿。
3.3 撤销的三种姿势，用对场景才不会翻车
理解了三个区域之后，撤销操作就很好讲了。很多新手问“我把文件改坏了怎么还原”“commit提交错了怎么撤回”，其实答案取决于文件当前处于哪个状态。
场景一：工作区改乱了，还没执行add
bash复制git restore <file>
这个命令会用版本库里最近一次提交的内容，覆盖当前工作区的修改。对于未跟踪的新文件，restore无效，需要手动删除。
场景二：已经add了，想从暂存区撤回来
bash复制git restore --staged <file>
这个命令把文件从暂存区挪回工作区，但文件本身的内容不会被改变。它的效果等同于git reset HEAD <file>，不过restore是Git 2.23之后推荐的写法，语义更清晰。
场景三：commit提交完了，想撤回
这里要分情况。如果提交还没推送到远程，只是想撤销这次提交并保留修改，用：
bash复制git reset --soft HEAD~1
HEAD~1表示上一个提交，--soft的意思是只移动HEAD指针，不动工作区和暂存区的文件。所以执行完之后，你的文件修改还在，只是提交记录消失了。如果想把暂存区也清掉，只保留工作区改动，用git reset --mixed HEAD~1（--mixed是reset的默认行为）。如果想连工作区的修改一起丢掉，用git reset --hard HEAD~1，这个操作很危险，文件修改会彻底丢失，执行前务必确认没有价值。
如果提交已经推送到了远程，不建议用reset，因为会改写历史，导致他人仓库和远程仓库不一致。更稳妥的方式是用git revert HEAD生成一个反向提交，既撤销了改动，又保留了历史轨迹。reset和revert的区别可以简单理解为：reset是“时间倒流”，revert是“做一个抵消操作”。在多人协作的分支上，能用revert就别用reset。
4. 高频命令实操手册：从clone到merge的日常链路
4.1 分支与日志：你每天都在和谁打交道
如果你用Git只做个人项目，分支的威力可能体现得还不明显。但一旦进入团队协作，分支模型就是Git最核心的武器。一个仓库可以同时存在多条开发线：main是主分支，永远保持稳定可发布的状态；feature/xxx是功能分支，开发新功能时从main拉出来，完成后再合并回去。
查看当前仓库所有分支：
bash复制git branch -a
创建并切换到一个新分支：
bash复制git checkout -b feature/login
在较新的Git版本中，也可以用更语义化的git switch -c feature/login。这两个命令效果一样，switch是后来新增的专门用于切换分支的命令。
查看提交历史：
bash复制git log --oneline --graph --decorate -n 20
--oneline让每条提交只显示一行摘要，--graph显示分支合并的走向，--decorate标出分支和标签的指向。这条命令是我平时用得最多的，一眼就能看清最近发生了什么。
如果你想知道某一行代码是哪个提交引入的，用：
bash复制git blame <file>
输出结果会逐行显示提交哈希、作者、时间和修改内容，查问题归属的时候特别好用。
4.2 merge还是rebase：不争对错，只看场景
合并分支有两种方式：git merge和git rebase。这俩的差别是新手最容易困惑的点，我尽量讲得通俗。
假设从main拉了一个feature分支，在开发期间，main上多了两个新提交。此时你把feature合并回main，merge的做法是生成一个新的合并提交，把两条线的历史像拉链一样并在一起；rebase的做法是把你feature上的所有提交“摘下来”，重新接到main最新的提交后面，相当于“我基于最新的main重新做了一遍”。
对比一下：
| 对比项 | merge | rebase |
|---|---|---|
| 历史记录 | 保留完整分叉和合并节点 | 变成一条直线，历史更干净 |
| 冲突处理 | 一次合并处理一次冲突 | 每个提交都可能触发冲突，可能重复处理 |
| 安全性 | 不改写已有提交，安全 | 会改写提交哈希，危险 |
| 适用场景 | 多人协作的公共分支 | 个人功能分支、提交还没推送时 |
我的建议是：公共分支上永远用merge，个人功能分支上可以用rebase来整理历史。整理提交历史是个好习惯，但要以“不要改写别人可能已经拉取过的提交”为前提。
4.3 冲突处理：别怕，这就是个手工活
合并时最常见的问题就是冲突（conflict）。冲突的本质是两个人改到了同一段内容，Git不知道以谁为准，只能把决定权交给你。
比如你和同事同时改了index.html的标题行，合并时Git会提示CONFLICT (content): Merge conflict in index.html。打开这个文件，你会看到：
text复制<<<<<<< HEAD
<title>首页改版</title>
=======
<title>网站首页</title>
>>>>>>> feature/login
<<<<<<< HEAD和=======之间是当前分支（HEAD指向的那个）的内容，=======和>>>>>>> feature/login之间是合并进来的分支的内容。你需要手动删除其中一个或重新调整，然后把<<<<<<<、=======、>>>>>>>这些标记行全部删掉，保存文件。
处理完之后，执行：
bash复制git add index.html
git commit -m "merge: 解决标题冲突"
这样就完成了冲突解决。几个实战心得：第一，冲突解决前先看清楚每个块的含义，别闭着眼睛删；第二，只改冲突标记覆盖的那部分，不要顺手改其他代码；第三，如果你不确定哪个版本是对的，找同事当面聊，别猜。
4.4 提交规范：让历史成为可读的文档
在团队协作中，提交信息（commit message）写得好不好，直接影响项目维护效率。一个规范的提交信息应该能让人不看代码、只扫一遍git log就知道这次改动的意图。
目前业界应用最广的是Conventional Commits规范，格式如下：
text复制type(scope): subject
body（可选，补充说明）
其中type是提交类型，常用值有：
feat：新功能fix：修复Bugdocs：文档变更style：代码格式调整，不影响逻辑refactor：重构，不新增功能也不修Bugperf：性能优化test：测试相关chore：构建工具、依赖等杂项
scope是影响范围，可写模块名或文件名；subject是简短描述，一般不超过50个字符。一个典型示例：
text复制fix(login): 修复验证码在iOS上不显示的问题
原因是验证码图片的宽高样式在Safari下解析异常，改为使用内联样式。
有了这个规范，配合git log --oneline，整个项目的演变过程一目了然。个人项目可能无所谓，但只要是多人协作，提交规范应当作为团队约定尽早落地。
5. 远程仓库与SSH免密配置：为什么密码总是失效
5.1 为什么要配SSH
使用Git托管平台（GitHub、GitLab、Gitee等）时，拉取和推送代码有两种鉴权方式：HTTPS和SSH。
HTTPS方式最简单，clone时输入账号密码（现在基本是输入访问令牌token）就行。但它有一个烦人的问题：每次git push都要验证一次身份。虽然可以配置凭据管理器缓存，但多平台使用时token会过期，过期之后又得重新生成。而且，如果你在服务器上做自动化部署，HTTPS方式很难做到“免交互”。
SSH方式则完全不同。它的做法是：你机器上生成一对密钥（公钥+私钥），把公钥上传到托管平台，私钥留在本地。之后每次连接，Git会自动完成身份验证，全程无感。配置好一次，之后git clone、git push都不用再输密码。这也是为什么搜索热词里“git ssh配置教程”常年居高不下。
5.2 生成密钥和配置远端的完整步骤
第一步：检查是否已有密钥
bash复制ls -la ~/.ssh
如果看到id_rsa.pub或id_ed25519.pub这类文件，说明你已经生成过密钥，可以跳过生成步骤。
第二步：生成新密钥
bash复制ssh-keygen -t ed25519 -C "你的邮箱或备注"
一路回车即可，默认会在~/.ssh/目录下生成id_ed25519（私钥）和id_ed25519.pub（公钥）两个文件。如果你有多台设备或平台，建议给密钥起个特殊名字：
bash复制ssh-keygen -t ed25519 -f ~/.ssh/github_ed25519 -C "github"
第三步：复制公钥内容
bash复制cat ~/.ssh/id_ed25519.pub
把输出的内容整个复制下来，它看起来像一串乱码，开头是ssh-ed25519。
第四步：把公钥添加到托管平台
以GitHub为例，进入Settings → SSH and GPG keys → New SSH key，粘贴公钥，保存。其他平台（GitLab、Gitee）的入口大同小异。
第五步：如果密钥文件名不是默认的，需要配置SSH客户端
如果你用了自定义文件名，比如github_ed25519，还需要在~/.ssh/config里告诉Git用哪个密钥连哪台主机：
text复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/github_ed25519
第六步：验证连接
bash复制ssh -T git@github.com
看到Hi 用户名! You've successfully authenticated，说明配置成功。此后clone仓库时用SSH地址（git@github.com:用户名/仓库名.git）就行，全程免密。
5.3 免密失败的几个隐藏原因
我自己在这块踩过不少坑，也给很多人排查过问题。如果按上面步骤配完还是提示要密码，请检查以下三个点：
- 私钥权限问题（常见于macOS/Linux）：私钥文件权限太宽松，SSH会拒绝使用。执行
chmod 600 ~/.ssh/id_ed25519修复。 - 环境变量HOME不对：Windows上如果同时装了Git Bash和Cygwin/WSL，SSH可能找不到
.ssh目录。确认一下echo $HOME指向的是不是你的用户主目录。 - 托管平台地址不一致：如果你配置时用的是GitLab，走的是
git@gitlab.com，那GitHub的仓库自然不能复用。每台主机要单独配置或单独生成密钥。
配好SSH之后，除了免密，还有一个隐藏好处：SSH方式在传输稳定性上通常比HTTPS更好，不容易出现连接中断。
6. 新手高频报错排查：这几条全是血泪
6.1 “git不是内部或外部命令”和“无法识别为cmdlet”
这两个报错本质是同一个问题：系统的PATH环境变量里找不到Git的执行文件。
在Windows上，git安装后默认位于C:\Program Files\Git\bin\git.exe和C:\Program Files\Git\cmd\git.exe。如果你的PATH里没有包含这些路径，CMD会提示“git不是内部或外部命令”，PowerShell会提示“无法将git项识别为cmdlet、函数、脚本文件或可运行程序的名称”。
解决方法分两步：
- 打开系统环境变量设置（Win+R输入
sysdm.cpl→ 高级 → 环境变量）。 - 在系统变量中找到
Path，编辑，新增C:\Program Files\Git\cmd，保存后重开终端。
另外，改完环境变量一定要重启终端窗口，否则不会生效。如果你用的是VS Code，改完环境变量之后VS Code往往也需要完全重启一次。
反过来还有一种情况：环境变量没错，但由于某种原因git命令暂时没法定位。可以在终端输入where git看能不能找到路径，如果找不到，按照上面的方法重新加一遍即可。
6.2 unable to access + error setting certificate file
这个报错的完整形态类似这样：
text复制unable to access 'https://...': error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt
意思是Git在访问HTTPS仓库时，没能加载证书文件。常见原因是Git安装目录变了（比如从D盘挪到C盘），但全局配置里的证书路径还指向旧路径。
先看一下当前的证书配置指向哪里：
bash复制git config --global --list
输出里如果有http.sslCAInfo=...或http.sslCAPath=...，确认路径是否存在。如果路径不对，重新设置：
bash复制git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt"
把路径替换成你机器上实际存在的证书文件路径。这里要特别提醒一句：网上很多教程会让你直接禁用SSL验证，比如git config --global http.sslVerify false。这条路确实能绕过报错，但非常不建议在生产环境用，相当于你在和服务器通信时放弃了身份校验，数据可能被中间人截获。
6.3 clone速度慢或中途失败
从GitHub clone大仓库时，经常会遇到速度慢、卡在Receiving objects半天不动的情况。最简单的办法是使用国内托管平台的镜像。很多大厂都有GitHub仓库的加速服务，可以把你访问的https://github.com/xxx替换成镜像地址。
另外一个思路是调整Git的缓冲设置：
bash复制git config --global http.postBuffer 524288000
这个命令把HTTP缓冲区扩大到500MB，对某些大文件仓库的clone失败有一定帮助。如果还是失败，建议检查网络环境，不要一直重复试。
6.4 git clone下来之后没有代码？
这个不算报错，但很常见。有人git clone完仓库，打开目录发现空的，怀疑自己clone错了。这种情况大概率是仓库的默认分支没有内容，或者clone的是子目录。可以用git branch -a查看远程有哪些分支，用git log --oneline看看提交历史。如果默认分支是main，而远端主要代码在develop分支上，那clone下来自然是空的。切换分支：
bash复制git checkout develop
7. 把效率再推一档：VS Code、小乌龟和那几条Git Bash技巧
7.1 VS Code：图形化操作的正确打开方式
很多新手对命令行有畏难情绪，这个很正常。好消息是，VS Code内置了完善的Git图形化支持，日常90%的操作可以不用敲命令。
打开任意Git仓库目录，左侧活动栏的“源代码管理”图标就是Git面板。在这里你可以看到所有修改的文件、暂存和取消暂存、输入提交信息并提交、拉取和推送、查看历史。全鼠标操作，对新手极其友好。
再装一个GitLens插件，能直接在代码行上看到每一行的最后修改人和提交信息，配合git blame用，排查问题效率翻倍。VS Code还内置了一个集成终端，快捷键Ctrl+`就能呼出，默认会打开当前项目目录，省去切窗口和cd的麻烦。
用了VS Code之后，还有人问我“git命令还得背吗”。我的观点是：常用命令起码要会用，但不必全背。 图形化工具能覆盖80%的日常操作，剩下的20%——复杂合并、历史改写、批量操作——终究要回到命令行。图形化工具帮你降低上手门槛，但不要把它当成逃避命令行的借口。
7.2 TortoiseGit：Windows右键菜单里的效率神器
TortoiseGit俗称“小乌龟”，是Windows平台上一款老牌的Git图形客户端。它的特色是深度集成到资源管理器右键菜单：选中文件，右键就能看到“Git Commit”“Show log”“Check for modifications”等选项，图标还能实时显示文件状态（新增、修改、冲突等）。
安装时注意两点：
- 安装包和语言包要分别下载，装上语言包后右键菜单才能显示中文。
- 安装时记得勾选关联Putty密钥页，否则SSH密钥配置可能会走弯路。
小乌龟现在更新得不算频繁，但功能稳定，在老项目维护和需要高频查看文件级别的历史变更时，它比VS Code面板还要直观。
7.3 Git Bash的几个实用技巧
Git Bash是Windows下随Git一起安装的类Unix终端环境。它里面集成了大量Linux常用命令（ls、grep、sed等），适合在Windows上体验类Linux操作。几个实用小技巧分享给你：
命令别名。如果你厌倦了反复输入git status，可以配置别名：
bash复制git config --global alias.st status
git config --global alias.ci commit
git config --global alias.br branch
git config --global alias.lg "log --oneline --graph --decorate --all"
之后输入git st等于git status，git lg直接看完整的提交图谱。
Tab补全。Git Bash里输入命令和路径时按Tab键会自动补全，路径很长时非常好用。这也是为什么很多教程推荐用Git Bash而不是CMD来跑Git命令的原因之一。
临时保存改动。如果你正在改某个功能，突然要切换分支处理一个紧急Bug，但改动做到一半不想提交，也不舍得丢，用git stash：
bash复制git stash push -m "登录功能改了一半"
git checkout main
# 处理完紧急事务后切回来
git checkout feature/login
git stash pop
git stash会把工作区的改动暂时收起来，让你可以自由地切换分支。这个命令在多人并行开发时极其有用，值得记下来。
最后说几句实在话
学Git最忌讳的就是把命令背得滚瓜烂熟，却从不理解它背后的逻辑。我从带过的每个新人身上都发现一个规律：一旦搞懂了工作区、暂存区、版本库这三层结构，以及分支和合并的基本原理，Git的学习曲线会突然变得很平缓。剩下的，无非是遇到问题查文档、踩了坑记住教训。
这些年我养成了一个习惯：每次提交前先看一眼git diff，确认自己改了什么，再决定要不要提交。 这个动作帮我挡住了很多次“提交了一堆调试代码”“把配置文件带上去了”的尴尬。写提交信息时，我先写一句“这解决了什么问题”，如果写不出来，说明这次改动本身就有问题，我会停下来重新想想。
再推荐一个练习方法：拿一个不重要的仓库，新建一个分支，随便改、随便合并、随便reset，把能踩的坑都踩一遍。本地操作不会影响任何人，但你会收获对Git最直观的感觉。等你练过几遍，就会发现Git其实没那么可怕——它只是需要你多用几次，多信它几次。