1. Git 到底是什么——先搞懂这三个核心概念很多人第一次接触 Git是在“严重问题”之下被迫开始的代码写到一半文件被自己改坏想退回昨天的版本却发现根本没保存或者小组几个人在同一台服务器上改代码互相覆盖最后谁也说不清哪份才是最新的。这时候同事丢过来一句“你用 Git 管理吧”于是你打开搜索引擎搜“Git 核心概念”看到一堆术语仓库、提交、分支、HEAD、工作区、暂存区……瞬间头就大了。我当初也是这么过来的。先用了一年 Git只玩add、commit、push、pull四个命令遇到冲突就慌遇到分支就绕道走。后来把原理补上才意识到之前那些“玄学报错”其实全是自己不懂模型导致的。这篇文章不讲花哨的进阶技巧而是把 Git 最核心的三个概念彻底讲透——快照存储、三区模型、分支本质然后再给你一条从安装配置到日常操作到团队协作的完整链路。看完你再看那些命令就不是背单词了而是顺着原理自己推出来的。这套内容适合谁刚入行的开发人员、在校做课程设计的同学、从 SVN 或 FTP 时代转过来的老程序员以及所有“用着 Git 但说不清它干嘛”的人。我不打算写成官方文档那种干巴巴的说明而是用我踩过的坑和验证过的流程带你把它当成一套“代码时光机 并行工作台”来理解。2. 快照存储模型——为什么 Git 能够“回到任意时刻”先来纠正一个常见的误解。很多人以为 Git 保存的是“文件的变化记录”也就是 diff——你今天改了哪几行它存下来明天又改了哪几行它再存一份。这是老牌版本管理工具比如 SVN的做法。Git 恰恰相反Git 保存的是每次提交时全部文件的一个完整快照。这句话怎么理解你可以把一次提交想象成对整个项目文件夹拍了一张“压缩照片”。照片里包含的是当前所有文件的内容哪怕某个文件一个字都没改它也会完整出现在这张快照里。Git 做了优化没改过的文件不会重复存储完整副本而是通过索引指向上一个快照里的同一个对象。但从逻辑层面每次提交确实代表了一个完整的项目状态。这个设计带来了什么好处最直接的好处是切换分支、回滚历史都极其快。你从昨天切到三天前Git 不需要把一串 diff 倒着叠加回去它只需要把整个快照解出来放到工作区。这也是为什么 Git 切换分支的速度通常比 SVN 快一个数量级。代价是仓库体积会偏大因为历史里存了很多完整快照但现在的硬盘容量根本不在乎这个。可以说Git 用空间换取了运行速度和逻辑简洁性。每次提交在 Git 内部对应一个 40 位十六进制的哈希值比如9b7b3f1a8e29f2e5d6c4a1c3b8d0e7f6a5b4c3d2。这个哈希不是随便生成的它由提交内容的树对象、父提交引用、作者信息、提交信息联合计算而来。只要其中任何一个字节变化哪怕只是提交信息里多打了一个空格生成的哈希就完全变了。这也意味着一个提交一旦生成它的内容和历史归属就是确定的不能被偷偷篡改——你改了内容哈希就对不上了。这种环环相扣的结构构成了 Git 在数据完整性上的底气。每一条提交记录里除了文件快照本身还存着父提交的引用。第一条提交没有父提交第二条提交指向第一条第三条指向前两条合并提交会有两个父提交。把这些引用串起来就形成了一条有向无环图。你在终端里用git log --graph看到的那堆星号和折线就是这张图的可视化呈现。理解了图而不是线性的“版本号 1.0、1.1、1.2”你对 Git 的理解就已经超越了大部分人。实操心得我见过有人为了“节省仓库空间”每隔几个月就删掉.git目录重新git init一次等于把整个历史一把火烧了。这是拿 Git 当 FTP 用。Git 的快照模型决定了它的历史本身就是资产。真正该做的是用.gitignore把依赖目录、构建产物、本地配置排除在版本控制之外而不是靠删历史来瘦身。3. 三区工作模型——每条提交之前代码到底经历了什么Git 的工作区状态可以被划分为三个区域工作区、暂存区、版本库。这三者的关系是所有 Git 操作绕不开的坐标轴。很多入门者搞不懂为什么git add和git commit要分开两步为什么要先“暂存”再“提交”还觉得多此一举。等你弄明白了三区模型会觉得这个设计简直是天才。3.1 工作区、暂存区、版本库分别是什么工作区就是你能直接看到和编辑的文件目录也就是你写代码的地方。你在 IDE 里改文件改的就是工作区的内容。这部分文件和 Git 没有任何“主动关系”除非你主动告诉 Git 去关注它。版本库是隐藏在项目根目录下的.git文件夹。所有已提交的历史快照、分支引用、配置信息都存在这里。正常情况下你不需要去动它更不要手贱去删它。暂存区夹在两者中间Git 官方叫它 index索引。它本质上是一个清单文件记录着“下一次要提交哪些文件、它们的内容对应哪个快照对象”。你执行git add就是把工作区里当前文件的内容快照打进暂存区并更新这个清单。暂存区里装的是你正在“打包”的一批东西打包完成不意味着已经寄出还需要git commit来确认。用一个寄快递的比喻工作区是你家里所有待寄的杂物暂存区是你已经放进纸箱里、用胶带封好的那一箱版本库是快递公司收件入库的记录。你可以持续往同一个箱子里塞东西重复 add也可以把某个东西从箱子里拿出来git restore --staged直到你确认封箱填好面单提交信息一按git commit这箱东西才正式进入仓库记录贴上唯一的快递单号哈希。3.2 为什么必须区分暂存和提交假设你同时改了两个文件一个是修 bug 的fix.js一个是加新功能的feature.py。这两个改动属于不同逻辑如果放在同一条提交里后续想单独回滚某一个功能就会非常痛苦。有了暂存区你可以只git add fix.js先提交修复再git add feature.py提交功能。一条提交对应一个逻辑单元这是写提交信息黄金法则的基础。另一个场景更实际你改了一半代码同事发消息说线上有问题让你顺带看一下某个文件。你不想把自己改到一半的脏代码全部提交只想把那个和线上问题相关的文件抢救出来。没有暂存区你只能要么全部提交、要么全部不提交。有了暂存区你就可以只挑那一两个文件提交其他半成品继续留在工作区。这也是 Git 相比很多“一键提交”型工具的优雅之处。3.3 三区联动时的常见误操作修改了文件但没git add就执行git commit提交结果不含这次修改。新手最容易栽在这。执行git add .把临时调试文件、日志文件也提交进去。建议每次提交前用git status检查一遍“被跟踪文件”列表别让.log和.env混进版本库。执行git reset --hard以为只是清暂存区结果工作区的改动也被一并抹掉。关于 reset 的三种模式后面会详细讲这里先记住带--hard时动的是三区全部状态务必谨慎。4. 工具篇Git 安装、初次配置与 IDE 集成光懂概念不装工具是不现实的。这一节覆盖的是初学者接触频率最高的三个场景安装 Git、配置基本环境、在 IDEA 里拉取项目。热词里那句“diea创建新项目拉取git”我猜就是打错的 IDEA这个问题我身边也确实常有人卡住这里一次讲清。4.1 从零到可用的安装流程Windows 用户去 Git 官网下载 Windows 版本现在的安装包通常叫Git-x.x.x-64-bit.exe。安装过程一路 Next 即可但有几个选项需要注意。第一个是“Select Components”界面勾选“Git Bash Here”和“Git GUI Here”这样右键菜单里就能直接打开 Git Bash。第二个是“Default editor”选择新手建议选 “Use Nano”如果选了 Vim之后写提交信息时可能会因为不会用 Vim 而卡死在编辑器里。第三个是“Adjusting your PATH environment”这一项务必选第二项 “Git from the command line and also from 3rd-party software”它不仅把 Git 加进系统 PATH还会顺手配置好C:\Program Files\Git\bin避免以后某些工具找不到 Git。装完按Win R输入cmd敲git --version能输出版本号就说明核心安装没问题了。macOS 用户最简单的方式是安装 Xcode Command Line Tools在终端里执行xcode-select --install系统会自带 Git。但自带版本通常偏旧我建议用 Homebrew 装新版本一条命令搞定brew install git。同样装完执行git --version验证。Linux 用户Debian/Ubuntu 系执行sudo apt install gitCentOS/RHEL 系执行sudo yum install git。源码编译安装不在本文讨论范围内没必要给自己找麻烦。4.2 第一次配置必须做的三件事Git 装好之后系统认为你是“临时访客”第一次提交通常会报错提示Please tell me who you are。这是因为每次提交都要签上用户信息方便团队知道改动是谁做的。需要执行三条命令git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main名字和邮箱会被永久写入全局配置用户主目录下的.gitconfig文件。这里有个实际注意点如果你用的托管平台是 GitHub / Gitee / GitLab邮箱务必填成你账号绑定的邮箱。如果填一个野生邮箱虽然本地能正常提交但推到远端后平台无法把提交关联到你的账号头像上你的提交会显示成一个无名灰色小动物头像。这个问我在不少同学的项目里见过不是 Bug但很难受。第三行设置默认分支名。老版本 Git 初始化仓库时默认分支叫master业界现在越来越倾向用main新版本 Git 也把默认改成main了。这里统一设成main避免以后同一台机器在不同项目里切来切去。配置完成后用git config --list可以查看当前所有配置确认有没有设置错。4.3 IDEA 里创建新项目并拉取 Git 仓库IntelliJ IDEA 是 Java 程序员和很多前端开发者的主力 IDE里面的 Git 集成做得很好但再好的工具也需要知道入口。以最新版 IDEA2023.x 之后为例打开 IDEA 欢迎界面点击 “Get from VCS”下拉菜单里选择 Git然后把托管平台上的仓库地址粘贴进 URL 栏选好目录点 Clone。仓库克隆完成后IDEA 会自动打开这个项目右下角弹出的 Git 分支面板能让你直接切分支、看历史。如果是创建新项目后再拉取已有 Git 仓库有两种方案。第一种在创建项目的弹窗里选 “Git” 作为版本控制再通过菜单栏Git - Manage Remotes添加远端地址。第二种用命令更省事——在 IntelliJ IDEA 内置终端可以按Alt F12打开里直接执行git init git remote add origin gitgithub.com:username/repo.git git fetch origin git checkout maingit init把当前目录变成一个 Git 仓库git remote add origin把目标仓库设置为默认的远端名为 origingit fetch把远端分支信息拉下来最后checkout main切到你想要的分支。之后你就可以像正常项目一样操作了。这里插一个 IDE 相关的坑有些同学把项目文件和.idea目录IDEA 自身的项目配置目录一起提交了。这会让同事之间互相覆盖 IDE 个性化配置很容易引发困扰。建议在项目根目录执行echo .idea/ .gitignore把这类 IDE 专用文件全部忽略掉。5. 核心命令实操——从初始化到分支合并的完整工作流概念和安装都铺垫完了现在进入真正的高频操作区。热词里出现了好几次“git命令”“git分支合并”说明大家最关心的还是日常命令怎么用、分支怎么合、合并产生冲突怎么处理。这一节我按一条真实开发主线来走初始化仓库 - 第一次提交 - 开分支 - 合分支。每一步讲用途、讲参数讲我踩过的坑。5.1 初始化仓库与第一次提交mkdir my-project cd my-project git init git statusgit init执行完毕后目录里出现.git文件夹项目正式成为“被 Git 管理的仓库”。git status是接下来你要用最高频的命令没有之一。它显示当前工作区、暂存区相对于版本库的差异状态。新仓库里所有未跟踪文件都会显示为Untracked files。接下来建一个测试文件比如README.md然后git add README.md git commit -m docs: 初始化项目添加README-m参数直接跟在提交信息后面免去打开编辑器的步骤。注意我用了“type: 描述”的写法这是业界比较通行的 Commit Message 规范Conventional Commits比如feat:表示新功能、fix:表示修复、docs:表示文档改动。规范不强制但能让你三个月后回看历史时秒懂每个提交做了什么强烈建议养成。第一次提交完成后git status会显示nothing to commit, working tree clean。这句话可以理解为“你的工作区和最近一次提交完全一致”也就是所谓的“干净状态”。5.2 分支的本质一个移动的指针现在说分支。我在前文强调过 Git 是快照模型分支的底层实现其实就是一个指向某个提交的指针。假设仓库里有两次提交当前分支叫main它就指向第二次提交的快照。当你执行git branch feature/loginGit 做的事非常简单——创建一个新的指针也指向当前这一条提交。真正发生“分叉”是从“在同一基础上各自提交”开始的。你切到feature/login分支提交了 A 提交main分支没有动之后别人回到main提交了 B 提交。这时两个指针指向了不同的历史Git 历史图就出现了一条分叉。所谓“分支合并”本质就是把两支的改动作整合。# 创建并切换分支 git switch -c feature/login # 等价于老写法 git checkout -b feature/login # 在分支上做改动并提交 git add . git commit -m feat: 新增登录页 # 切换回主分支 git switch main注意git switch是 Git 2.23 之后推荐的新命令职责更单一只负责“切换”比checkout这个什么都能干的老命令更不容易误操作。如果你用的 Git 版本还比较老git --version看得到 2.23 之前才需要用checkout系列。这也是我建议更新 Git 的原因之一。那为什么要用分支而不是直接在main上改因为分支提供了一个相对隔离的工作区。你自己开一条feature/xxx分支改坏了、做毁了直接删掉分支main毫发无损。多人协作时每个功能、每个 bug 修复各占一个分支互不干扰代码评审时也能按分支审查做到“小而美”的提交单元。分支名本身就是一种文档将来看 Git 历史时“哪些提交属于哪个功能”一目了然。5.3 合并分支的两种方式merge 与 rebase 的取舍合并是 Git 操作里最需要动脑的一类。先说 merge。# 确保当前在 main 上 git switch main git merge feature/login如果两个分支自分叉以来没有对同一个文件的同一区域做修改merge 会执行fast-forward也就是直接把main指针快速移动到feature/login所在提交。如果两边各自有新提交、且改动互不重叠Git 会自动创建一个merge commit把两支历史合并成一个交汇点。如果两边改了同一处代码就进入冲突状态需要手动解决。和 merge 形成对比的是 rebase。它的核心思路是“把当前分支的提交拆下来换个新基线重新放上去”从而得到一条线性历史git switch feature/login git rebase mainrebase 改写的是提交历史——它会把你这条分支上原来的提交哈希全部替换成新哈希。所以协作分支千万不要随意 rebase因为别人如果拉过你的旧提交之后你再推上去同事那边的基站就对不上了会出现一堆“重复提交”。merge 则不会改写历史协作时更安全。我自己的选择标准是如果这个分支只有我一个人在用且还没推送到远端用 rebase 整理出干净的线性历史很爽如果分支已经推到远端且有多人协作过一律用 merge。5.4 亲历的冲突解决过程冲突并不可怕关键是要沉住气。假设main分支和feature/login分支都修改了README.md的同一行merge 时终端会提示CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.打开README.md你会看到 Git 插入的冲突标记 HEAD 这里是 main 分支的内容 这里是 feature/login 分支的内容 feature/loginHEAD代表当前所在分支main的版本下面的部分代表被合并分支feature/login的版本。解决方案就是把这两段整理成你想要的结果保留其中一边、删除标记符、可能还需要加上两边内容的融合。手动编辑完成后执行git add README.md git commit -m merge: 解决 README 冲突git commit 在这里不会新开编辑器窗口因为 Git 已经匿好了默认的合并提交信息。冲突被正确解决后log 里就多了一个 merge commit。调试技巧解决冲突时如果心里没底最稳妥的办法是git merge --abort可以直接把整个 merge 状态还原到合并前。不用觉得丢面子先保证仓库不坏再重新合并比硬解解出个逻辑错误强太多。我的习惯是复杂冲突先在编辑器里肉眼对比两边代码确认语义后再动手。6. 团队协作要打通的最后一公里——remote 与 SSH 认证本地玩得再溜最终都要推到远端仓库跟队友协作。这一节解决热词里出现过的“ssh认证失败”“git下载安装教程”“git拉取git仓库”背后的核心疑问远端仓库怎么关联、SSH 认证怎么配、拉取推送的时候各种报错怎么应对。6.1 关联远端仓库与推送拉取最常用的托管平台是 GitHub、Gitee国内、GitLab公司内部。三个平台在 Git 层面的操作逻辑完全一致先有一个远端仓库地址在你本地仓库里执行git remote add origin gitgithub.com:username/repo.git git push -u origin maingit remote add给远端仓库起了个本地别名origin你不用每次敲完整仓库地址。-u参数是--set-upstream的简写把本地main和远端origin/main建立关联以后直接敲git push和git pullGit 就知道跟谁通信了。日常开发里比较典型的工作循环是git pull origin main # 自己写代码...... git add . git commit -m feat: xxx git push origin main这里有个老生长谈的问题一定要先 pull 再 push。如果多人同时开发你本地历史和远端历史出现了分叉直接 push 会被拒绝提示non-fast-forward。正确姿势是先git pull让 Git 把远端的新提交合并/变基到本地解决可能出现的冲突再 push。不 pull 就 push 被拒是新手遇到最多的远端相关报错。6.2 SSH 认证失败的根源排查托管平台目前提供两种远程仓库协议HTTPS 和 SSH。HTTPS 走用户名密码或 Token 认证SSH 走密钥对认证。热词里“ssh认证失败 git”这条搜索量很高说明它确实是团队协作里的第一道拦路虎。SSH 的基本原理是你在本地生成一对密钥——私钥id_ed25519或id_rsa和公钥.pub把公钥内容贴到托管平台后台。之后每次 Git 往远端推拉时双方通过密钥对完成身份验证全程不需要输密码。生成密钥的标准做法ssh-keygen -t ed25519 -C 你的邮箱执行后一路回车即可。生成的公钥内容可以通过cat ~/.ssh/id_ed25519.pub查看然后把输出整段复制粘贴到 GitHub 的Settings - SSH and GPG keys - New SSH key或者 Gitee 的设置 - SSH公钥保存。认证失败最典型的几个原因按我的排查经验排个序第一个原因公钥根本没配到平台上或者配到了错误的账号下。很多人忘了把公钥添加到托管平台直接克隆仓库时就会看到Permission denied (publickey)。检查方式是执行ssh -T gitgithub.com如果能连上会看到一段欢迎文字说明认证已成功如果提示Permission denied问题基本就在公钥没配对或者配到了别人的账号上。第二个原因本地多个 SSH 密钥而 Git 用了错误的那一把。这种情况在有多个托管平台、多个账号时尤其常见。解决办法是在~/.ssh/config文件里写上Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work这个文件的作用是告诉 SSH 客户端访问 github.com 时用id_ed25519_work这把私钥去认证而不是默认的那一把。第三个原因从 HTTPS 克隆的仓库后续操作却希望用 SSH 认证。因为两者放的是同一套远端地址但协议不同导致认证方式也完全不同。我最开始就踩过这个坑仓库是用https://github.com/xxx/yyy.git克隆的后来心血来潮换密钥发现 push 提示要输密码以为密钥配错了。其实只要执行git remote set-url origin gitgithub.com:xxx/yyy.git把远端地址从 HTTPS 切换成 SSH 格式push 就自动走密钥认证、不再要密码了。注意换地址前先git remote -v看当前 remote 是什么。第四个原因多平台共用一个密钥没问题一份公钥可以绑多个平台但同一台机器上同平台的多个账号不能共用一个密钥。GitHub、Gitee 都不允许一个公钥同时绑定两个账号。如果是这种场景老老实实生成两对密钥并在~/.ssh/config里用不同 Host 别名区分Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal这样在克隆仓库时把地址里的github.com替换成github-work或github-personalGit 就会自动选择对应的私钥。6.3 常用协作命令速查git fetch origin # 只拉取远端信息不改动工作区 git pull origin main # 拉取并合并等价于 fetch merge git push origin main # 推送本地 main 到远端 origin git remote -v # 查看当前仓库的远端地址列表 git clone gitgithub.com:xxx/repo.git # 完整克隆一个远端仓库到本地 git log --oneline --graph --all # 以图形化方式查看全部分支历史git clone会一次性把远端仓库的完整历史拉到本地自动建立origin关联。git fetch和git pull的区别是很多人容易混淆的fetch 只是把远端提交“下载”到本地但不会碰你的工作区文件你可以先看看远端改了什么再决定怎么整合pull 则是下载之后立刻尝试合并进当前分支一步到位但风险也更大。习惯上我会在不确定远端状态时先用 fetch git log origin/main --oneline观察确认没危险再 pull能少踩很多合并冲突的雷。7. 高频报错排查速查与避坑指南最后用一个实战总结来收尾。这一节我把这几年在带新人和自己项目中遇到的高频 Git 问题整理成一张速查表每个问题都附上原因和解法。这些问题单看都不难但集中在一个人身上真正发生时能卡住一个下午。报错/现象根因解决步骤Please tell me who you are没配置 user.name / user.email执行git config --global user.name 名字和git config --global user.email 邮箱再重新 commitPermission denied (publickey)SSH 公钥未配置或配置错误ssh -T gitgithub.com测试检查公钥是否已添加到平台账号设置中fatal: remote origin already exists已存在同名远端引用先git remote remove origin再重新git remote add origin 新地址non-fast-forward拒绝推送本地历史落后于远端git pull origin main处理完可能的冲突后再 pushCONFLICT (content)同一文件同一区域被多分支修改编辑冲突文件、git add、git commit或git merge --abort放弃合并Your branch is ahead of origin/main by 1 commit本地有未推送的提交git push origin main推送上去fatal: refusing to merge unrelated histories两个仓库没有共同历史比如两个不同 init 的项目合到一起确认确实要合并时用git pull origin main --allow-unrelated-histories误提交大文件或敏感文件缺少 .gitignore 或漏配加入.gitignore用git rm --cached 文件名从暂存移除跟踪提交后推送我再补充几个容易气血上涌的操作教训。第一个git reset --hard前务必三思。reset --hard会把工作区、暂存区全部强制重置到指定提交未提交的改动、未暂存的新文件全部丢失。我见过同学开发一整天的代码以为已经 commit 了结果只是 add 没有 commit一条reset --hard HEAD下去当天工作全部蒸发。保险做法是用git reset --hard HEAD之前先git stash把所有未提交改动暂存起来或者干脆先git diff确认有没有未提交内容。第二个删除分支不可怕但未合并的分支删了就找不回。git branch -D feature/xxx会强制删除一个尚未合并的分支如果该分支上有独有的提交这些提交虽然短时间内还能通过git reflog找回来但一旦被 GC 清理就真的没了。第三个提交信息写不好等于给未来的自己埋雷。三个月后看git log --oneline满屏都是 “update”“fix” 时你没法快速定位某次改动。哪怕团队不强制规范也建议自己养成feat:fix:docs:的前缀习惯。关于.gitignore我再多啰嗦一句。它能在源头上避免很多“误提交”问题。以 Node.js 项目为例最基本的.gitignore至少要包含node_modules/ dist/ .env *.log.env里通常有数据库密码、API 密钥一旦提交并被推到远端即使马上删除历史记录里依然存在安全性已经打了折扣。所以在项目初始化时就写好.gitignore比事后再补救省心得多。8. 最后说点实在的学 Git 的路线建议和一个实用小技巧我见过不少新手学 Git 时买了几百页的工具书从git config的每一个参数开始啃结果两周后连push都还没敢点。我的建议恰恰相反先跑通最小可用闭环再说深处。所谓最小闭环就是init-add-commit-branch-merge-push-pull。老老实实新建几个测试仓库把“改文件、提交、切分支、合代码、制造冲突、解决冲突”这套流程完整走三遍你对 Git 的信心会呈现指数级增长。在日常工作中我还养成了一个非常实用的小习惯在切换分支或执行 pull/merge 之前先看一眼git status。只要工作区不干净有未提交的改动切换分支或合并就可能把事情搞复杂。与其出了问题再补救不如在一开始就花三秒钟确认状态。另外一个很值得推荐的技巧是用git stash来“临时封存”手头的工作。有时候代码写到一半突然要切到别的分支去看一个问题但手头的改动还不想提交。这时执行git stash工作区就会变得干净你可以放心切换分支。等处理完那边再切回来执行git stash pop改动就原样恢复。这个命令我在日常开发里几乎每天都在用是“临时换挡”的最佳工具。如果一定要给自己的学习路线排个序我会给这样的清单先吃透快照、三区、指针这三个底层概念再熟练跑通单机流程然后掌握分支合并与冲突解决最后打通 remote 与 SSH 的协作链路。这条路径走完Git 就不会再给你添乱反而会成为你手边最得力的工具箱。这套东西我在不同场合给至少上百个人讲过有人说“听了概念才看懂命令”也有人说“直接照着冲突步骤解一遍就通了”。没有哪种学习方式适合所有人所以这也只是一份经验之谈。最终还是要你自己打开终端敲下第一条命令把仓库亲手建起来才能真正上手。