第一次带新人做代码托管我就发现一个规律讲半小时git commit、git branch、git merge不如让人打开一个网页在里面敲几行命令然后盯着右边那棵提交树实时长出新枝。git 可视化教程网站干的就是这件事——把抽象的对象模型、指针移动、分支分叉画成一张随时会变的图你每执行一次操作图上就动一次理解的闭环在一秒钟内完成。这篇文章想解决的问题很具体你不想背命令也不想看满屏枯燥的手册想找到几个真正好用的可视化教程站点从零把 git 用到能干活的程度。我会把自己长期筛选下来、反复推荐给团队新人的几个站点拆开讲清楚包括每个站点适合什么阶段、进去之后先点哪里、哪些地方是它的教学简化、真实项目里要小心什么。同时我会补上光看教程学不到的部分——Git 安装与配置里的那些勾选项、git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks这种命令到底在干什么、凭据和密钥怎么配、误操作之后怎么用可视化找回。不管你是刚下完安装包的新手还是已经能敲命令但一直没搞懂分支图的老手下面这些内容都能直接用。1. 为什么我更推荐用可视化方式入门 Git1.1 命令行恐惧背后其实是模型没建立起来大多数人卡在 git 上不是因为命令太多而是因为脑子里没有那棵树。git commit到底改了什么HEAD是什么东西为什么git checkout既能切分支又能还原文件这些问题的答案都是一张图而命令行只给你一行文字回显。文字是线性的git 的数据结构是图形化的中间隔着一层翻译新手就是在这层翻译上卡死的。可视化教程网站把这一层翻译干掉了。你在输入框敲git commit -m first右边的图立刻多出一个圆点你敲git branch feature图上多出一个指向同一个圆点的标签你再敲git checkout featureHEAD那个特殊标记跑到新标签上。三次操作三个视觉结果分支指针的概念根本不需要文字解释。我试过用纯命令行的方式给新人讲课平均要两轮才能让人理解分支只是一个指向提交的可移动指针换成可视化沙盒一轮就够因为他们是看见的不是记住的。还有一个隐性好处可视化工具天然带有撤销焦虑的免除。在命令行里新手最怕的是敲错一条命令把东西搞坏于是每次回车前都要犹豫。而在沙盒网站里刷新页面一切重来成本为零敢于乱按恰恰是学 git 最快的路径。我在实际带人的过程中发现进步最快的那批人几乎都是把沙盒当玩具乱玩出来的。1.2 可视化与命令行的分工边界该怎么划有种说法是命令行才是正统图形界面是拐杖。这话在效率层面部分成立在入门阶段则完全是误导。我的划分标准很清晰理解阶段用可视化执行阶段用命令行或成熟的图形客户端。原因在于两者的信息密度方向不同——图形界面把结构化信息一次性铺开适合建立认知命令行把操作压缩成一行适合批量、脚本化、可复现。举个实际场景。你要把一个开发了两周的功能分支合进主干中间主干被别人推了五个提交。这时候你需要判断是merge还是rebase、要不要先fetch、冲突可能出在哪几个文件。打开图形化的提交历史一眼就能看出分叉点和重叠文件范围心里有数之后再敲命令或者干脆在客户端里点几下完成。反过来如果你要批量重命名十个分支、要写进 CI 脚本、要在几十个仓库里统一执行操作命令行和git -c参数才是唯一解。所以我在下面推荐站点时会明确标注每个站点的定位教学型、图解型、沙盒型、通关型。不要指望一个站点解决所有问题也不要在通关型游戏里指望学到生产环境的坑。1.3 我筛选这些站点时看的四个硬指标市面上叫git 教程的页面太多了质量差距极大。我筛的时候主要看四件事这也是你可以拿去评估任何教程的标准。第一有没有实时反馈的图。纯文字教程讲分支合并配几张静态截图说服力很弱因为你无法验证自己的理解。能在你操作后立刻重绘提交图的价值高一个量级。第二中文支持是否完整。不是机翻是术语翻译得对不对。比如detached HEAD翻成分离头指针是合适的翻成脱离脑袋就没法看。很多站点提供语言切换进去先切中文能省掉大量查词时间。第三是否覆盖到 rebase 和远程操作。只讲add/commit/push三件套的教程遍地都是但真正让人栽跟头的是rebase、cherry-pick、reset三种模式的差别以及fetch和pull的区别。教程止步于基础命令的学完就废。第四有没有告诉你教学简化在哪。好的教学站点会声明自己用的是简化模型或者提供与真实 git 行为的对照说明。差的站点会让人误以为git push永远不需要先pull结果第一次协作就冲突。提示把实时性和覆盖范围这两条放在最前面。一个站点哪怕界面丑只要能做到一次操作一次重绘就值得花两小时界面再漂亮、只能看不能操作的属于读物不属于教程。2. 值得收藏的 Git 可视化教程站点清单2.1 Learn Git Branching把分支操作做成闯关关卡如果只允许我推荐一个站点就是这个。它的核心是一块左右分屏的画布左边是命令行模拟器右边是提交树。你在左边敲的每一条命令右边都会实时重绘提交点的位置、分支标签、HEAD指向、远程跟踪分支全都可视化。它的内容组织成关卡制基础篇从git commit、git branch、git checkout开始到进阶篇的git rebase、git cherry-pick、相对引用^与~再到移动提交记录、多分支 rebase、远程仓库。我特别喜欢它对相对引用的处理。HEAD~3和HEAD^2这种写法看文字解释要花很久但在这里你敲一次图上的指针就跳过去一次第二次你就记住~是往上找几层父提交、^是找第几个父提交。这是纯文字教程做不到的效率。使用建议上我的路线是这样的先不碰命令行直接从基础篇第一关开始每关的提示可以看但先自己想。到了进阶篇把rebase那一组关卡反复做两遍特别是那个把多个分支重排到主干上的关卡做完之后你对变基会重写提交历史这句话会有体感。沙盒模式一定要用它有undo和reset按钮随便折腾。需要清醒认识的是它简化了什么。它的远程操作演示偏理想化push和fetch的模拟基本不会遇到真实的权限、凭据、网络问题它也不涉及.gitignore的匹配规则、大文件存储、子模块这些生产环境常见话题。把它当理解模型的工具不要当完整手册。2.2 图解型站点不操作只把命令和结果对照着给你看有一类站点不提供命令行输入只做命令 → 图示的一一对照适合在第一次接触某个命令之前扫一眼或者忘了的时候快速回查。我常翻的两个方向一个是命令效果对照图把git add、git commit、git reset --soft/--mixed/--hard三种模式画成工作区、暂存区、仓库三个区域的箭头图。我见过太多人搞不清reset --soft和--hard的差别看一眼这种三区图再配上一句--soft只动 HEAD 指针--hard连工作区一起清掉一辈子不会忘。另一个方向是提交图形态对照把merge和rebase在同一组提交上产生的两种历史画出来并排比较。左侧是合并产生的分叉再汇合右侧是变基产生的直线。这个对照图对团队规范到底该用哪种的讨论特别有用——我在分享会上就是放这两张图然后说主干保持线性是为了让git bisect定位问题更快代价是变基会重写提交哈希所以只对未推送的本地提交做。这类站点的问题在于不提供反馈你只能看不能验证。所以我的用法是看完立刻去沙盒验证。图解型站点负责建立预期沙盒负责确认理解两步合起来才闭环。另外提醒一句图解站点的图往往是手绘风格的示意坐标并不精确别拿它去理解提交的拓扑顺序细节。2.3 游戏化与引导式站点适合完全零基础和抗拒学习的人有一类站点走的是游戏化路线把 git 操作做成卡牌或者任务。比如用卡牌代表命令、用关卡代表目标让你在一个小世界里完成任务。这类站点的最大价值是降低启动门槛。对于听到命令行就头疼的人来说先用游戏把commit、branch、merge三个概念玩熟比直接看文档有效得多。还有一类是引导式实验给出一个个小任务比如创建一个分支并在上面提交一次然后合并回主干你照着做做完进入下一题。这类站点的好处是有明确路径不会像沙盒那样让人不知道从哪下手。我自己的经验是游戏化站点适合前两小时超过两小时就该往真实项目迁移了。原因很简单游戏的胜负条件是人设计的真实项目的正确操作取决于团队约定游戏里没有该不该 rebase 别人的分支这种判断题。我见过在游戏里通关很顺的人第一次参与协作就因为在共享分支上做了变基而被同事追着问这就是缺了规范这一层。顺便说一句如果目标是能看懂真实项目的历史图那除了教程站点还应该去翻几个开源仓库的提交历史。看别人怎么组织提交信息、怎么处理合并、分支命名有什么惯例这比任何教程都直观。建议先找两三个中等规模、活跃度高的仓库打开提交图翻二十页你会对什么样的提交历史是清晰的形成直观判断。2.4 官方文档与速查表当作字典不要当教材官方文档的地位必须说清楚。它是最准确的但最不适合作入门材料因为它是按功能组织的不是按学习路径组织的。你从第一页读到最后一页会在配置和底层命令附近迷失。我的用法是遇到具体问题时去查平时不读。比如忘了git stash的 pop 和 apply 有什么区别去查一下两分钟解决。速查表则是另一件必备工具。桌面上放一张单页速查表覆盖日常二十来条命令比记在脑子里靠谱。我建议自己动手整理一份不抄现成的——整理的过程本身就是记忆过程。我的那份按场景分组日常提交、分支操作、撤销修复、远程同步、查看历史每组五行以内。用了半年之后你会发现真正高频的其实只有十二三条。注意不要迷信任何单一来源。git 版本迭代会带来行为变化比如默认分支名从master到main的迁移、git switch和git restore的引入都在相对近的版本里发生。教程站点更新慢遇到命令能敲但行为和教程不一样的情况以官方文档和本地git help 命令为准。3. 把教程网站用出效果我的实操路径3.1 环境准备Git 安装里那些被忽略的勾选项光在网页上练回到本地还是两眼一抹黑所以第二步一定是装。Windows 上从官网下载安装包双击进入向导几个关键节点的选择我列一下因为这些选项直接影响后面会不会踩坑。第一处是组件选择页。建议至少勾上添加到 Windows 资源管理器右键菜单这样你在任意文件夹右键就能打开终端或图形界面省掉手动cd的功夫。至于把 Git 和可选的 Unix 工具添加到 PATH这一项推荐选 Git from the command line and also from 3rd-party software也就是中间那一档。选最保守的只用 Git Bash会导致你在其他终端里敲git提示找不到命令选最激进的使用 Windows 默认终端偶尔会和系统的控制台行为冲突。第二处是换行符转换。这一步是跨平台协作最大的坑源。Windows 用 CRLF类 Unix 系统用 LF不处理的话会出现整个文件都改了但内容没变的诡异 diff。Windows 上装的时候选 Checkout Windows-style, commit Unix-style line endings对应配置里的core.autocrlftrue。macOS 和 Linux 上设成input也就是提交时统一转成 LF检出时不动。第三处是终端模拟器和凭据管理器。默认的 MinTTY 终端体验不错能正常显示中文和颜色建议保留。凭据管理器强烈建议启用它会把你的凭据加密存到系统凭据库里避免每次推送都让你重新输入账号密码。装完之后先做最小配置这几条是必须的git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main git config --global core.quotepath false git config --global core.autocrlf true # WindowsmacOS/Linux 用 input git config --global pull.rebase false git config --global credential.helper manager # Windowscore.quotepath false这条特别值得说。默认情况下git 会把非 ASCII 文件名显示成八进制转义比如\346\226\207...中文文件名全变乱码。设成 false 之后正常显示中文。这就是很多git 中文乱码帖子的根因。还有一组参数你可能在某些 IDE 的日志里见过git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks status。这三个的含义分别是diff.mnemonicPrefixfalse让 diff 输出统一用a/和b/前缀而不是根据场景换成c/、i/、w/这些助记前缀——因为某些编辑器解析 diff 时只认a/bcore.quotepathfalse就是上面说的中文显示--no-optional-locks则指示 git 在执行这类只读命令时不去写索引锁文件避免和编辑器后台的扫描进程抢锁导致卡顿。当你知道它们在干什么看到这条长命令就不会再懵了。3.2 三小时速通路线从 commit 到 rebase 怎么分配我给新人排过一个三小时的路线实测下来接受度最高。第一个五十分钟全部给沙盒闯关站点目标是把commit、branch、checkout、merge四个操作和它们的图上效果对应起来。这一段的验收标准是能不看提示在图上把两个分支合并成一条带分叉的历史。中间五十分钟做rebase和相对引用。这是最关键的一段也是大多数人放弃的地方。我的建议是不要追求一次搞懂先接受三条事实变基会把提交复制到新位置并生成新的哈希变基能让历史变成直线变基后的原提交在reflog里还能找到。理解了这三条剩下的细节可以在实战中慢慢补。这一段结束时你至少要做到能在沙盒里把一条分叉变基成直线并且解释为什么这条直线和合并的结果内容一样但历史不一样。最后八十分钟做远程操作。这一段的重点是彻底分清fetch、pull、push三者的作用。fetch只下载不合并pull等于fetch加合并或变基push是把本地提交送到远程并且移动远程分支指针。我建议在这里配一个真实的远程仓库练手因为网页沙盒的远程模拟太理想化感受不到权限和凭据的存在。练手仓库用一个空仓库就好做几次推送、拉取、制造一次冲突、解决冲突比看十篇文章管用。3.3 三区模型与指针模型可视化真正帮你建立的底层认知用了这么多可视化站点我最后提炼出两个必须建立的心智模型理解了它们绝大多数 git 行为都能自己推导出来。第一个是三区模型工作区、暂存区、仓库。工作区是你编辑器里看到的内容暂存区是一次提交的草稿清单仓库是已经固化的历史。git add是把工作区内容登记进清单git commit是把清单固化成一次提交。理解了这三个区git reset的三种模式就非常自然--soft只退仓库里的指针清单和工作区不变--mixed默认退指针也退清单工作区不变--hard三者一起退。我见过有人把--hard当成日常撤销用结果一天的努力没了这就是没建立三区模型的代价。第二个是指针模型一个分支就是一个指向某次提交的可移动标签HEAD是指向当前所在分支的指针。提交的本质是让当前分支指针前移一格。理解了这一点git checkout切分支是移动HEADgit branch创建标签git reset移动当前分支标签git rebase是把一段提交搬家后重新贴上标签detached HEAD就是HEAD直接指向某个提交而不是分支。所有这些命令不再是散落的字符串而是同一套坐标变换的不同组合。这两个模型在网页沙盒里都能直接看到但要真正内化建议做一个小练习不看任何教程拿纸画一遍从初始提交开始创建分支、提交两次、切回主干、合并、再变基画出每个步骤结束时三个指针的位置。能画出来基本就通了。3.4 本地图形客户端怎么选配合教程站点的落地工具教程站点再好也是网页日常干活需要一个能看提交历史的本地客户端。我按使用场景分几类说。文件管理器集成型Windows 上的 TortoiseGit俗称小乌龟是典型代表。它的安装有个前置条件——必须先装好 Git for Windows然后再装本体和中文语言包顺序错了会提示找不到 git。装完后文件夹和文件上会有状态角标右键菜单里有提交、更新、显示日志等入口。它的显示日志窗口是我用过的最直观的提交图之一分支线、标签、合并来源都画得很清楚。需要注意它默认可能用自带的 SSH 客户端如果你希望统一用 Git 自带的那套去设置里把 SSH 客户端指向 Git 安装目录下的ssh.exe。独立客户端型GitKraken、Fork、SourceTree 这一类界面现代冲突解决和图形化变基做得好适合不想碰命令的日常使用。共同的问题是启动慢、大仓库卡顿而且部分高级功能要付费。编辑器内置VS Code 配合 Git Graph、GitLens 这类扩展能在编辑器里直接看提交图和逐行追溯。JetBrains 系列内置的提交视图也做得相当扎实还支持从历史里直接做cherry-pick这种操作。优点是不用切换窗口缺点是对理解 git 本身帮助有限因为它把很多操作都包成按钮了建议先用教程站把模型建好再用。终端型lazygit 这类 TUI 工具在终端里分栏显示状态、分支、提交键盘操作。适合长期在终端里的人启动快、资源占用低。我的选择是日常提交和查看用编辑器内置处理复杂历史操作时打开独立客户端写脚本和批量操作回命令行。三者不冲突。提示无论用哪个客户端第一次配置都要确认它读取的是同一份全局配置。有人的客户端里显示的提交作者名和命令行不一样就是因为客户端写了自己的配置而不是读~/.gitconfig。排查办法是命令行执行git config --list --show-origin看清楚每一条配置来自哪个文件。4. 常见问题与排查技巧实录4.1 装了 Git 但命令行提示找不到命令这是最高频的安装问题原因几乎都出在 PATH 上。要么是安装时选了只用 Git Bash那一档要么是装完没有重启终端。Windows 的 PATH 变更需要重新打开终端才会生效包括终端、编辑器内置终端、以及各类命令行工具全都要重启一遍。排查顺序是新开一个终端敲git --version还是不行就去系统环境变量里看 PATH 有没有 git 的 cmd 目录再不行就重新运行安装程序选择修改安装把 PATH 那一档改成中间档。还有一种情况是装了多个版本的 git 或者装了便携版PATH 里指向了一个不完整的目录这时候where git能把所有候选列出来逐个看。顺带说一个容易混淆的点Git Bash 里能用git不代表系统的其他终端也能用。两者读取的 PATH 可能不同。判断标准是在报错的那个终端里执行where gitWindows或which git类 Unix而不是在 Git Bash 里验证。4.2 提交能成但推送失败凭据与密钥配置本地提交不需要任何网络和身份验证所以能提交不能推送是新手最困惑的状态。原因通常是两类鉴权方式不对或者远程地址配错。先看远程地址git remote -v会显示当前的推送和拉取地址。HTTPS 形式的地址走账号密码体系SSH 形式的走密钥体系。我个人的建议是长期使用配 SSH因为一次配好之后不用反复输入也不受密码策略变更影响。配 SSH 在本地生成一对密钥用ssh-keygen -t ed25519 -C 你的邮箱一路回车会得到私钥和.pub公钥两个文件。公钥内容用cat ~/.ssh/id_ed25519.pub打印出来整行复制粘贴到代码托管平台的公钥设置里。之后用ssh -T gitgitee.com这类命令测试连通性看到欢迎信息就说明通了。Windows 上密钥默认在用户目录下的.ssh文件夹里注意别把私钥没有.pub后缀的那个传出去也别忘了给它设文件权限。密钥配好仍然失败的检查三件事一是测试命令里的用户名和平台一致二是如果用了非默认密钥文件名需要在~/.ssh/config里指定IdentityFile三是首次连接会提示确认主机指纹回答 yes 之后会写入known_hosts这一步在自动化环境里不能被跳过。如果坚持用 HTTPS那就把凭据管理器配好git config --global credential.helper managerWindows。不建议把账号密码写进远程地址里明文存着迟早出事。4.3 提交历史乱成一团merge 与 rebase 的取舍用了一段时间之后很多人会发现自己的提交图变成了一团麻线分叉再分叉还有一堆fix typo的提交。这时候需要的是规范不是更多的命令。我的做法分两层。个人本地分支随意提交但推送到共享分支之前做一次整理用交互式变基把零碎提交合并、把提交信息改清楚。共享分支上的历史不做变基因为别人可能已经基于这些提交做事了重写哈希会让他们全部对不上。合并方式上我倾向于主干只接受合并不接受直接的线性变基推送。这样主干上的每个节点都对应一次明确的合并能看出功能边界。代价是历史有分叉但用图形客户端看并不乱因为分叉是有意义的。至于要不要用 fast-forward 合并我的看法是保留合并提交更有利于追溯所以合并时加--no-ff参数强制产生一个合并提交。git commit --amend是整理本地提交最常用的一个工具改掉最后一次提交的信息或者把刚忘了加的文件塞进上一次提交。用法是先把文件git add进暂存区然后git commit --amend会打开编辑器让你修改提交信息。需要特别注意的是--amend会生成一个全新的提交哈希变了所以只能对还没推送的提交使用推送到共享分支之后再 amend别人拉取时就会出现历史分叉。4.4 误操作后的后悔药用可视化把东西找回来git 其实很少真正丢数据绝大多数误删都能救回来前提是你知道去哪儿找。git reflog是最重要的救命工具它记录了HEAD的每一次移动包括提交、切分支、变基、重置。误删了分支用git reflog找到那条分支最后一次提交的哈希然后git branch 分支名 哈希就恢复了。误做了reset --hard同样在 reflog 里找到重置之前的哈希git reset --hard 哈希退回去。图形客户端一般都有 reflog 视图找到对应条目右键就能操作比敲命令直观。还有一个场景是提交到了错误的分支。如果还没推送可以切到正确分支后git cherry-pick那个提交再回原分支把提交删掉。如果已经推送了用git revert生成一个反向提交更稳妥因为它不改历史。需要提醒的是真正无法挽回的是提交过但从未进入任何引用、也没被 reflog 记录的游离对象这类东西一般只在极端操作下产生而且会在后台被回收。另外工作区里从未add过的改动git 完全不知道它的存在删了就没了这不是 git 的问题。所以我的习惯是改动哪怕不完整也先提交一次反正后面可以合并整理。4.5 常见问题速查表下表中整理的场景都是我这两年在团队里被问得最多的按现象、原因、处理三列排列方便直接对照。现象常见原因处理方式提示 git 不是内部或外部命令PATH 未包含 git或终端未重启重装时选中间档 PATH重启所有终端中文文件名显示成八进制转义core.quotepath默认为 truegit config --global core.quotepath false提交时警告 LF 会被替换跨平台换行符不一致Windows 设core.autocrlftrue其他设input每次推送都要输密码未配置凭据管理器配置credential.helper或改用 SSH 密钥推送被拒绝提示需要先拉取远程有新提交先fetch看清差异再合并或变基冲突解决后发现多了很多文件改动编辑器或系统自动改了行尾、权限关掉无关的格式化插件检查core.fileMode分支图分叉太多看不清频繁在本地拉取合并或将未整理提交直接推送本地先整理提交合并时用--no-ff保留边界误删分支或误做硬重置操作前未确认目标用git reflog找到哈希后恢复提交到了错误分支切换分支前未确认HEAD位置未推送用 cherry-pick 迁移已推送用 revert 反向提交仓库意外暴露了版本控制目录部署目录直接指向工作区部署用独立目录只复制需要的产物服务器上限制访问控制目录最后一行的场景值得多讲两句。有些部署方式会把整个工作目录直接当成站点根目录结果版本控制的元数据目录也被暴露出去任何人都能顺着它把源码和提交历史翻出来。这不是 git 的问题是部署方式的问题。正确的做法是构建产物和源码分离部署时只把构建结果复制到目标目录或者在服务器配置里明确拒绝访问这类目录。养成部署目录里不该有版本控制元数据的习惯能省掉很多麻烦。5. 我踩过的坑和几条私房经验说几个只有实际操作过才会有的体会。第一别在刚学的时候同时学多个客户端。我试过一个月内换了三个图形客户端结果每个都只熟悉一半反而在切换时频繁出错。后来定下来一个用半年把快捷键和冲突处理流程练到不用想效率才起来。工具之间的迁移成本比想象中高。第二教程里的沙盒命令和真实 git 有差异这个差异要主动去找。比如沙盒里的远程推送不会遇到远程有新提交需要先拉取的情况也不会遇到权限不足。我的做法是每学完一个概念就到一个真实的小仓库里验证一次哪怕只是fetch一下看看输出也比只在沙盒里练扎实。第三配置一定要用--global和--local分层别全都堆在全局。公司项目和工作外项目用不同的邮箱这是很常见的需求。全局设一套默认值在具体仓库里用git config user.email覆盖这样提交记录里的身份就不会串。用git config --list --show-origin能清楚看到每条配置来自哪个文件排查为什么这个仓库用的是别的身份时这条命令是救命的。第四reflog 的默认保留期是有限的超过一定时间的游离提交会被回收。所以出事后尽快处理别拖几天再去找。同时如果你知道某个重要提交可能会被丢弃最稳妥的办法是给它打个标签标签会一直保留。第五把提交信息当代码写。我见过太多updatefix的提交三个月后自己都看不懂。现在的习惯是第一行写做了什么正文写为什么这么做以及有什么影响。这个习惯在看别人的提交历史时也能反过来用——如果一个项目的提交信息写得很清楚说明维护者值得信任看它的历史就是很好的学习材料。第六关于教程站点的使用节奏我的建议是集中两三天突击然后用半年在日常里慢慢固化。突击阶段把模型建立起来后面每次遇到新操作就去查一次官方帮助几个月下来覆盖面自然就全了。反过来如果指望一口气把所有命令学完大概率会在变基和撤销这两个主题上卡住然后放弃。第七有条件的话找一个人一起练。两个人互相推送、互相制造冲突、互相解决比自己闷头练快得多因为协作本身才是版本控制工具存在的理由。我最早真正理解fetch和pull的区别就是在一次两个人同时改同一个文件的过程中撞明白的。注意涉及凭据、密钥、部署目录访问控制的操作先在小范围验证确认无误再推到正式环境。配置类改动尽量写进统一的脚本或说明文档避免只在某一台机器上生效过段时间自己都忘了改过什么。整套东西走下来你会发现可视化教程站点的价值不在教你敲命令而在让你在脑子里装下那棵树。树有了命令只是查询方式换个客户端、换套参数都不影响判断。后面真正需要花时间的是对团队协作规范的磨合和对历史整洁度的持续维护这部分没有网站能替你做只能在实际项目里一点点积累。