企业官网建设流程全解析

别再被命令行吓退了。很多刚接触版本控制的同学，看到 Git 第一反应就是“要背命令”，其实 Windows 上有一款老牌图形化客户端，能让整个 Git 流程变成“右键点几下”的事，它就是 TortoiseGit。这款工具对从 SVN 迁移过来的老用户尤为友好，因为它延续了资源管理器右键菜单的操作习惯，而且把提交、拉取、合并、解决冲突这些高频场景全部做成了可视化界面。这篇文章我要聊的不是怎么背git add .和git commit -m，而是日常实际项目里，用 TortoiseGit 怎么把一个仓库从“拉下来”到“改完合回去”的全过程，以及只有真正在项目里用过才会遇上的坑和解决办法。

1. 为什么坚持用鼠标点出 Git 操作

1.1 TortoiseGit 到底解决了谁的痛点

先说结论：TortoiseGit 是给两类人准备的。第一类是刚入门、还不熟悉 Git 工作流的新手，把提交、拉取、推送变成按钮之后，出错概率会低很多；第二类是从 SVN 时代过来的老员工，SVN 时代在资源管理器里右键提交、右键更新已经形成肌肉记忆，切到 Git 以后最大的障碍不是 Git 本身逻辑难，而是命令行界面带来的陌生感。

我自己刚接触代码托管时其实很抗拒命令行，因为只要命令敲错一个参数，轻则仓库状态一团乱，重则把本地分支搞到需要重新克隆。后来用了 TortoiseGit，感受最明显的一点是：每一次操作前，它会把“即将对仓库做什么”这件事用弹窗讲清楚。比如提交时它会列出所有改动文件，拉取时它会让你看到远端过来了哪些提交，这些信息在命令行里要自己敲git status、git log才能看到，在图形界面里是默认展示的。

还有一类很典型的用户是设计、文档、配置类文件的维护者。他们不是职业开发，但需要参与内容协作。对他们来说，学习git pull --rebase这种命令根本不现实，反倒是右键菜单里的“拉取”“提交”“推送”三个词直观得多。我见过不少团队里非技术岗位的同事就是用 TortoiseGit 正常参与协作，一次错都没出过。

1.2 右键菜单背后的 Git 操作逻辑

TortoiseGit 最核心的设计思路是把 Git 命令映射到 Windows 资源管理器的右键菜单。你在任意文件夹上点右键，看到的“Git 同步”“Git 提交”“Git 拉取”这些入口，本质上都是对同一目录下的 Git 仓库执行对应的命令。

这里要强调一个容易被忽略的点：TortoiseGit 的右键菜单是“上下文相关”的。在仓库根目录、子目录、单个文件上分别点右键，菜单项会不一样。比如在文件上右键可以直接看“查看修改日志”或“查看差异”，因为在文件级别，它知道你想查的是这个文件的历史；在文件夹上右键则更多是“提交”“合并”“推送”这类仓库级操作。

理解了这个逻辑之后，你就不会在错误的地方找功能了。比如你想对比两个版本的文件差异，就应该先选中文件再右键，而不是在仓库根目录上盲找。这也是为什么我建议新用户从一开始就留意右键菜单的动态变化，它本身就是最好的 Git 入门教材。

2. 安装与首次配置，避开最容易踩的坑

2.1 先装 Git 还是先装 TortoiseGit

这个问题我每次都会被问到。标准答案是：先装 Git for Windows，再装 TortoiseGit。TortoiseGit 本身不包含 Git 内核，它只是一个图形壳，真正干活的是 Git 命令行程序。安装顺序反了也不会完全不能用，但安装器在检测 Git 路径时可能会找不到，后面还要手动指定，很麻烦。

安装 Git for Windows 时有一个选项要留意：在“Adjusting your PATH environment”这一步，默认的 “Git from the command line and also from 3rd-party software” 选项一定要保留。如果选成“只从 Git Bash 使用”，TortoiseGit 可能找不到 git.exe。实际上这也是很多“装了 TortoiseGit 却提示找不到 Git”的原因之一。我个人建议全程保持默认选项，一路 Next 就行，不需要做任何定制。

TortoiseGit 的安装包分 32 位和 64 位，这个不用多说，按系统选就行。安装完成后系统会要求重启资源管理器，因为图标覆盖（图标叠加）需要注册到资源管理器里。这里可以记住一句话：所有图标不显示的毛病，八成都是重新启动资源管理器或者改注册表项之后才能恢复。

2.2 SSH 密钥与认证方案的选择

克隆仓库之前先要解决认证问题。常见的有两种方式：HTTPS（或者叫 http 克隆）和 SSH。HTTPS 的好处是部署简单，缺点是推送时每次可能都要输账号密码；SSH 的好处是配置好密钥之后一劳永逸，缺点是密钥生成和添加需要多几步操作。

TortoiseGit 对两种方式都支持。我用 SSH 比较多，所以这里重点说密钥配置。第一步是生成密钥对，可以用 Git Bash 里的命令跑：

ssh-keygen -t ed25519 -C "your_email@example.com"

生成之后你会得到两个文件，默认放在用户目录下的.ssh文件夹里，没有扩展名的是私钥，.pub结尾的是公钥。公钥的内容需要添加到代码托管平台的 SSH 公钥列表里，私钥则留在本机。这一步各家平台界面不同，但核心动作一致：把*.pub文件的全部文本复制粘过去。

最关键的一步是告诉 TortoiseGit 这个私钥在哪。在 TortoiseGit 的设置里，“Git” 选项卡下方可以找到“远端”配置，也可以直接用右键菜单里的“Settings”进入。如果你是用 OpenSSH 格式生成的密钥，通常不需要做额外设置；但如果你在安装时选择了 PuTTY 风格的 SSH 客户端，那么 TortoiseGit 会要求你把 OpenSSH 私钥转换为 PuTTY 格式的.ppk文件，这个转换工具叫 PuTTYgen，TortoiseGit 安装包里自带。

我踩过这个坑：一开始选择了 PuTTY 模式，生成 OpenSSH 密钥之后直接填路径，TortoiseGit 一直提示认证失败。后来才发现需要先用 PuTTYgen 把私钥文件加载进去，另存为 PPK 格式，再在设置里指向这个 PPK 文件。如果你不想折腾格式转换，最省事的办法是在安装 TortoiseGit 的 SSH 客户端选择页选“OpenSSH”，这样你的密钥路径直接指向默认的id_ed25519就行。我个人现在更推荐这个方案，路径清晰，也不存在格式不兼容的隐性问题。

2.3 全局配置与显示效果

安装完第一件事是设置用户名和邮箱。虽然代码托管平台有自己的账号，但 Git 每次提交都会把用户名和邮箱写进提交记录里。如果全局不配置，TortoiseGit 提交时可能会弹窗提示，甚至直接提交失败。设置入口在右键菜单的“Settings -> Git -> 全局”，你只需要填 “User Name” 和 “Email Address”。注意这里的名字和邮箱会出现在每一次提交记录中，所以尽量用真实常用的，别随便写个“test123”。

另一个与体验强相关的是 TortoiseGit 的图标叠加效果。默认情况下，文件或者文件夹会显示小绿勾、小红点这类图标标记文件状态。但 Windows 资源管理器对图标叠加的数量有限制，最多好像十几个，所以装了 OneDrive 之类的云同步软件之后，这些图标会有概率突然消失。解决办法是在 TortoiseGit 的 “Settings -> Icon Overlays” 里调整“状态缓存”模式，从默认的“自动”改成“仅当前目录”试试。这个选项能显著减少图标不显示的频率，代价是状态刷新会变慢一点，看你怎么取舍。

3. 克隆、提交、拉取、推送，日常四件套

3.1 克隆仓库时 URL 与目录的讲究

项目交接过来，第一步自然是把远端仓库拉到本地。在资源管理器里你要存放项目的目录上右键，选“Git 克隆”，然后会出现一个对话框，让你填仓库 URL 和存放目录。

URL 这块要着重说一下。HTTP 模式的 URL 一般是https://example.com/group/project.git这种样子，SSH 模式则通常是git@example.com:group/project.git。复制 URL 的时候，注意别从浏览器地址栏直接复制网页地址，那通常不是 Git 协议地址，克隆时一定会失败。应该从代码托管平台的“克隆/下载”按钮那里复制真正的 Git 地址。

存放目录最好不要手动填到已有代码的文件夹里。Git 克隆会把远端仓库完整下载到你指定的位置，如果你填了一个已经存在的非空目录，TortoiseGit 可能会拒绝克隆，或者生成嵌套仓库导致后续提交混乱。我的习惯是先在项目根目录下建一个空文件夹，或者干脆用克隆对话框自动生成的文件夹名，保证这个目录从一开始就是干净的。

克隆完成后，TortoiseGit 会在资源管理器里显示这个目录的图标，并且右键菜单从“Git 克隆”变成一大堆“Git 提交”“Git 同步”“Git 拉取”等操作。到这一步，你才真正拥有了这个仓库的本地副本。

3.2 提交前一定要看清的两类信息

改完代码准备提交时，在仓库文件夹里右键选择“Git 提交”，会弹出一个很大的窗口。这个窗口左侧列出的是所有被修改、新增、删除的文件，右侧是对应文件的差异预览。很多人上去就填提交信息然后点确定，这是要吃亏的。提交窗口里最有价值的是左下角的“文件列表”，它在下一次提交前让你有机会审一遍自己到底动了哪些文件。

这里有两类信息最容易看走眼。第一类是“意外修改”：比如你只想改 A 文件，结果项目里还出现了 B 文件的改动，很可能是因为自动格式化、编译输出或者本地配置被误提交了。遇到这种情况，可以在文件列表里右键单个文件，选择“还原文件”，把它撤回到工作区原本的状态。第二类是“.gitignore 不生效”：如果你新建的项目里有一批本应忽略的文件（比如编译生成目录、IDE 配置文件）突然出现在提交列表里，大概率是.gitignore写错了或者文件还没被追踪过。

提交信息怎么写也有讲究。纯个人项目随便写，协作项目最好遵循团队约定。我个人的最低标准是：一句话说清楚“改了什么”，如果涉及 issue 或者任务编号，随手带上。比如“修复列表页筛选条件重置问题（任务号 1234）”就比“update”强一百倍。TortoiseGit 的提交窗口支持多行提交信息，第一行写摘要，空一行之后再写详细描述，这个格式在日志里显示最清晰。

3.3 拉取和推送的双向理解

在 TortoiseGit 里，“拉取”对应git pull，“推送”对应git push，是每个用了 Git 的人都会高频操作的两个按钮。但很多人对它们的理解只停留在“拉取就是把远端代码拿下来，推送就是把本地代码传上去”，实际上这两步的时序关系容易出错。

拉取本质上做了两件事：先从远端把新提交下载到本地仓库（这步叫 fetch），再把远端追踪分支的变化合并进当前分支（这步叫 merge）。所以如果你本地也有未推送的提交，拉取时大概率会产生一次“合并提交”或者冲突提示。这就引出了一个选择：拉取时要不要用“变基”方式？用命令行的话是git pull --rebase，TortoiseGit 里也提供了类似选项。

我的建议是协作分支上尽量用变基模式拉取，这样本地历史保持线性，不会出现那么多两两合并的额外节点。但变基会改写提交记录，如果你已经把自己的提交推送到了远端，并且别人可能已经基于它拉了分支，这时候再变基就会把历史弄乱。记住一个相对安全的判断标准：只有尚未推送的本地提交，才适合用变基方式整理；已经推送出去的提交，老老实实用合并方式拉取。

推送前还有一个隐性问题：远端分支有别人推送的新提交，而你本地没有拉取。这时候推送会被拒绝，TortoiseGit 会弹出一条类似“远端有变化需要先拉取”的提示。遇到这种情况的正确顺序是：先拉取，解决冲突，再推送。千万别用“强制推送”按钮硬推，那会把别人的提交覆盖掉，我见过因为这操作导致整个分支需要重建的事故，真的会让人崩溃。

3.4 更新与合并策略的个人习惯

日常迭代中，我比较推荐两个习惯。第一个是“先拉再改”：每天开始动手前，先右键拉取一次，把远端最新代码同步到本地，然后开始今天的工作。这样改的是最新代码，最后提交时冲突概率会小很多。第二个是“小步提交”：每次只提交一个逻辑完整的小改动，不要攒一整天到晚上一次性提交。小步提交的好处是出问题容易定位，回退也不至于把无关修改一起退掉。

TortoiseGit 本身也内置了“Git 同步”对话框，可以一次完成拉取、推送、查看远端更新等动作。我其实不建议大家太依赖这个多合一窗口，因为把多个操作揉在一起，犯错时不容易判断是哪一步出了问题。还是老老实实分开操作：拉取是拉取，推送是推送，每步都看清楚了再点下一步，对新手来说是最稳妥的路径。

4. 分支管理与合并冲突，图形化的真正主场

4.1 新建、切换、删除分支的鼠标流程

分支是 Git 里最强大的设计，但也是新手最容易晕的地方。用 TortoiseGit 管理分支，核心入口是右键菜单的“Git 分支”和“切换/检出”两个选项。

新建分支的操作路径是：右键仓库文件夹 -> TortoiseGit -> 分支，在弹出的窗口里输入新分支名，然后选择基点是当前分支还是某个历史提交。基点这个选项很关键，它决定了新分支从哪个位置分出去。默认是“HEAD”，也就是你当前所在的提交。如果你希望新分支基于另一个分支的最新提交，可以先用“切换/检出”切到那个分支，再新建分支。我见过有人想不开，从旧的提交点生成新分支，结果新分支里代码不完整，排查了半天才发现基点选错了。

切换分支则是右键 ->“切换/检出”，对话框里列出本地所有分支，选中一个点确定就切换过去了。这里有一个体验细节：如果你工作区里有未提交的改动，TortoiseGit 会询问如何处理。默认情况下它会尝试把改动带到目标分支，但如果两个分支对同一文件有不同改动，切换可能失败并提示冲突。所以切换前最好先提交或者用“贮藏”把改动暂存起来。TortoiseGit 的菜单里也有贮藏功能，相当于把当前半成品先搁到一边，切完分支再“贮藏弹出”取回来，这个操作比强行切换安全得多。

删除分支的入口也在“Git 分支”窗口里，选中分支点删除即可。需要注意：不能删除你当前所在的分支，也不能删掉尚未合并的分支，除非你勾选“强制删除”。强制删除意味着这个分支独有的提交会被直接丢掉，这个操作要慎点。

4.2 合并视图与冲突文件的三种状态

把某个分支的改动合入当前分支，操作路径是右键 ->“Git 合并”。对话框会让选择合并来源分支，并提供一个模式选项：默认是“合并提交”，还有一个“变基”选项。这里我建议新手先别碰“变基”模式，等把普通合并弄懂了再用不迟。

点击确定之后，如果两个分支没有改动重叠，TortoiseGit 会直接完成合并并生成一个新提交，整个过程几乎是静默的。但只要有冲突，它就会弹窗提示“合并过程中出现冲突”，这时才是图形界面的高光时刻。

冲突文件的三种状态你一定会遇见。第一种是“文本冲突”，同一个文件的同一段内容被两个分支以不同方式修改了；第二种是“文件级冲突”，一个分支删除了某个文件，另一个分支修改了它；第三种是“模式冲突”，比如一个分支把文件的换行符做了整体转换，另一个分支只改了其中几行，Git 会认为所有行都有变化，导致大面积冲突。第三种在实际项目里非常容易出现，尤其是 Windows 和 Linux 环境混用的团队，建议在.gitattributes里统一声明换行符规则，能省掉大量无谓冲突。

TortoiseGit 处理文本冲突时会列出这个文件的三个版本：我的版本（当前分支）、远端版本（要合并进来的分支）、以及常见的合并基准版本。界面上可以逐段选择“使用我的”“使用对方的”或手动编辑合并结果。操作完之后记得在文件上右键选择“标记为已解决”，不然 TortoiseGit 会认为这个文件仍然是冲突状态，无法完成提交。这个步骤被我见过好几次漏掉，结果整个合并卡在半路，提示“还有未解决的冲突”。

4.3 回退操作的三层含义

回退大概是 Git 里语义最容易混淆的概念。TortoiseGit 把回退分散在三个不同场景里，每个操作对应的结果完全不同，一定不能搞混。

第一层是“还原”工作区未提交的修改。如果你改了一些文件不想保留，可以在文件列表或右键菜单里选“还原”，把文件恢复到最近一次提交的状态。这个操作会直接丢弃你的本地改动，且没有撤销通道，等于把文件内容抹掉重来。所以操作前 TortoiseGit 会弹窗确认，我建议所有“还原”类操作先看清楚提示再点。

第二层是“回退”刚才的提交。在日志窗口里选中某次提交，右键可以看到“恢复更改并提交”之类的选项。它相当于git revert，会创建一个新的提交来抵消目标提交的更改，而不是把历史提交删除。这种方式适合已经推送出去的提交，因为它不改变历史，其他人拉取后会自动应用反向修改。

第三层是“重置”当前分支到某个历史提交。在日志窗口右键选择“重置主分支到此处”，可以把当前分支的指针强行移动到历史位置。这里特别容易出事：如果你选择“硬重置”，本地未提交的改动和该提交之后的所有本地提交都会被删除；如果你选择“软重置”或“混合重置”，改动会回到工作区或暂存区，还有挽救机会。我对所有新人的建议是：除非你知道自己在做什么，否则不要碰“硬重置”。平时回退提交，首选第一层和第二层，安全性高很多。

5. 日志、diff 与忽略文件

5.1 日志图里你能得到什么信息

TortoiseGit 的“显示日志”窗口大概是所有图形化功能里信息量最大的一个。它默认展示当前分支的提交历史，每一条提交记录包含提交信息、作者、时间、所在分支和提交哈希值。左上角的图形化区域用线条和节点把各个分支的合并、分叉关系画出来，对理解团队协作特别有帮助。

我每次接一个新项目，第一个动作就是打开日志图，看最近二三十次的提交记录。通过提交信息能看出团队的工作习惯，比如提交粒度大还是小、有没有规范前缀、是单人开发还是多人协作。更重要的是能看出当前分支最近有没有合并过其他分支、有没有回溯过历史。如果日志图里出现很多叉开又合拢的线条，说明分支管理比较频繁，或者有人拉取时总用“合并方式”而不是变基。这些信息在命令行里也能看，但绝对没有图形化这么直观。

日志窗口还支持右键单条提交做很多操作，比如“查看差异”“复制哈希值”“创建分支”“还原提交”，“导出补丁包”。其中“导出补丁包”是一个容易被忽略却很实用的功能：把这条提交打成一个.patch文件，发给同事可以直接作为提交导入。TortoiseGit 里对应的是“导入补丁包”操作，这对于没有共享远端权限的临时协作非常有效。

5.2 diff 历史版本与工作区

“diff”这个词刚接触的人会陌生，其实就是“对比差异”。TortoiseGit 的 diff 功能分散在两个地方：一个是在日志窗口里选中某个提交查看它与上一次提交的差异，另一个是在右键菜单里选择“查看差异”对比工作区和暂存区的改动。前者回答“这次提交改了什么”，后者回答“我还没提交的改动有哪些”。

我个人最常用的操作是在日志窗口的提交列表里，直接双击某条提交，TortoiseGit 会弹出一个差异窗口，左侧是按文件整理的改动树，右侧是代码级别的增删对比，新增内容用绿色标识，删除内容用红色标识。这种按文件归类的展示方式，在快速 review 改动时比命令行里一长串diff输出要清晰得多。

还有一个很推荐的功能是“比较日志”或“比较两个提交/分支”。比如你想知道主干分支和功能分支之间到底差了多少个提交、各自改了什么，可以在日志窗口按住 Ctrl 选中两条提交，然后右键选择“比较”。TortoiseGit 会列出一个差异清单，包含共同祖先之后的全部变化。这个操作在合并前做一次，能帮你决定要不要直接合并，还是要先在功能分支上做一次变基。它比盲合能节省不少解决冲突的时间。

5.3 .gitignore 与 TortoiseGit 的配合

每个 Git 仓库根目录下都应该有一个.gitignore文件，它告诉 Git 哪些文件不应该被追踪。TortoiseGit 不会自动生成这个文件，但你可以从右键菜单的“Git 添加忽略文件”来快速生成一段规则。

实际项目里最常见的误操作是把本地配置文件提交进了仓库。比如 IDE 的项目配置、运行环境变量、日志目录、编译产物，这些东西每个开发者的内容都不完全一样，提交进仓库之后一旦被其他人拉取，就可能覆盖本地个性化内容，还会导致合并冲突。正确做法是进入这些目录后，在.gitignore里写入对应的规则。TortoiseGit 的“添加忽略文件”对话框支持选择文件或文件夹，也支持自定义规则，很方便。

但要注意一点：.gitignore只对“尚未被追踪”的文件生效。如果一个文件已经被提交到仓库，即使后来写入.gitignore，它仍然会被 Git 跟踪。比如某天你把某个config.yml提交了，之后发现不该提交，即使加进.gitignore也只是不再显示“新增”状态，原来的文件仍然会继续跟踪。这种情况下需要把文件从 Git 索引移除，在 TortoiseGit 里可以右键文件选择“删除并保留本地副本”，操作之后 Git 就不再跟踪它，同时本地文件还在。这个操作本质上相当于git rm --cached，理解它的原理后你就不会被“加了 ignore 怎么还在提交”这个问题绊住。

6. 高频问题排查与速查表

6.1 “git did not exit cleanly”这类报错怎么看

用 TortoiseGit 的甲乙双方都会遇到同一个经典报错：“git did not exit cleanly (exit code 128)”。第一次看到这个提示的人往往慌得不行，以为仓库坏了。实际上这个报错本身只说明一件事：TortoiseGit 调用底层 Git 命令时，Git 以非零状态退出了，也就是说某个操作失败了。真正的原因要看操作窗口下方的“Standard Error”输出，那里通常写着具体失败原因。

最常见的几种原因我列一下。第一种是拉取或推送时认证失败，提示 “Authentication failed” 或 “Permission denied (publickey)”，多半是密钥没配置好或者账号密码错误。第二种是合并冲突，提示 “Automatic merge failed; fix conflicts and then commit the result”，TortoiseGit 会弹出冲突界面，你需要去解决冲突文件。第三种是文件被占用或锁定，常见于.git/index.lock文件残留，说明上一次 Git 操作异常中断，解决办法是根据索引仓库目录下找到这个文件并删除。第四种是切换分支时工作区有改动但无法带入目标分支，提示 “Your local changes to the following files would be overwritten by checkout”，这时需要先提交或贮藏改动。

遇到报错不要急着去找“万能修复按钮”，先看 Standard Error 里的关键英文信息，其实大部分错误已经把解决方向写在里面了。这也是图形界面用户最需要补的一课：TortoiseGit 把命令行的复杂度藏了起来，但并没有消灭它。

6.2 图标不显示的解决方法

绿色勾、红色感叹号这些状态图标不显示，是 TortoiseGit 被问得最多的问题之一。首先要明白，这些图标是 Windows 资源管理器“图标叠加”机制的一部分，系统对这个机制有数量限制，TortoiseGit 只是注册叠加图标的众多软件之一。

遇到图标不显示，我按以下顺序排查。第一步，右键仓库文件夹看 TortoiseGit 菜单是否正常，如果菜单都正常只是图标不显示，说明功能没问题，只是显示层面的事。第二步，检查设置里的“图标叠加”是否只对内置状态启用，如果你把“无修改”这类状态也勾选为显示，可能占用了有限的叠加名额，可以只保留有意义的几个状态。第三步，双击regedit进入注册表编辑器，检查HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers这个路径下，是否有 Tortoise 开头的项排在后面，Windows 会按字母顺序取前若干个叠加图标，如果前面插入了太多其他软件的项，图标就会被挤出候选名单。把无关软件的项重命名，让它排到 Tortoise 后面，就能恢复显示。这一步对于装有网盘类软件的机器几乎是必经之路。

6.3 常见问题速查表

最后把我在项目中遇到的高频问题整理成一个速查表，方便你遇到对应场景快速定位。表格里只写结论和操作建议，具体原理都在前面章节讲过。

这张表只是引子，真正重要的是理解每个问题背后的 Git 机制。比如 index.lock 这种问题，删文件只是治标，知道它为什么产生，下一次就不会慌张；又比如“忽略列表不生效”，本质是 Git 追踪的是历史索引而非只看 ignore 规则，理解了这一点，你的 Git 水平就已经超越大部分“只会点按钮”的用户了。

说实话，用了这么久的 TortoiseGit，我的体会是它并不是让使用者逃避理解 Git，而是把 Git 的底层逻辑用更舒服的方式呈现出来。很多人不敢碰 Git 是因为怕黑框窗口，但如果因为用了图形界面就永远不关心背后发生了啥，早晚会在某个缓存、合并或重置问题上栽大跟头。我的建议是：日常操作大胆用 TortoiseGit 点鼠标，同时每隔一段时间打开 Git Bash 跑几条git status、git log、git branch -a看看输出，两边对照着学习，理解速度会快很多。这样既保留了图形界面的效率，又不至于在某个终端工具崩溃的时候完全没法干活。