Git入门到精通：从版本控制基础到团队协作实战

你有没有经历过这样的时刻：项目文件夹里躺着一堆“项目方案最终版2.0（千万别动）”“项目方案_改稿_备份_final”这种名字的文件？我有。那是刚工作的第一年，三个人改同一个文档，没有版本管理，每天最害怕的，就是自己辛辛苦苦写的东西被另一个人直接覆盖。后来接触了Git，又慢慢搞清楚了Git、GitHub、Gitee、GitLab之间的关系，才明白当初的混乱完全可以用一个工具彻底解决。

这一篇是这个系列的第一篇，我会把重点放在Git本身。很多刚入门的朋友容易把Git和GitHub当成一回事，或者会在网上搜一堆零散的命令来复制粘贴，今天这篇文章就是帮你把这些碎片串成一张完整的网。我会从一个版本控制工具的底层逻辑讲起，到安装配置、日常命令、分支合并、远程协作，最后再补几个实战中容易踩的坑。内容不追求面面俱到，但一定保证你读完能真正理解Git在做什么，而不是只会背命令。

1. 先搞清楚：Git到底在解决什么问题

1.1 没有版本控制的协作，是一场灾难

想象一下这个场景：你和同事同时打开同一个Word文档，一个写了产品方案的初稿，另一个在原有基础上改了市场分析部分，你俩都保存了，谁后保存谁就覆盖了对方的内容。没有历史记录，没有任何中间版本，等发现的时候，其中一版的内容已经彻底没了。这种痛，做过文档协作的人应该都很熟悉。

Git的出现就是为了解决这个困扰。它本质上是一个“版本控制系统”，核心能力只有三件事：一是可以记录每一次文件变动，任何时刻都能回退到历史某个状态；二是允许多人同时修改同一批文件，最后合并到一起；三是不需要服务器也能在本地独立完成以上所有操作。这三个能力听起来简单，但在没有工具辅助的情况下，靠人工给文件夹命名来维护版本，几乎是不可能做到稳定可靠的。

我自己带团队的时候，经常被新同事问一句：“Git和GitHub不是一个东西吗？”这个问题其实问得很好。Git是工具，是运行在你电脑上、负责管理代码版本的那套程序。GitHub、Gitee、GitLab则是构建在Git之上的远程托管平台，他们提供服务器存储你的Git仓库，并提供网页界面、协作功能、代码审查之类的服务。比喻来说，Git是发动机，三个平台是装了发动机的不同车型。没有平台，Git照样能本地运行；但没有Git，这三个平台的根基就不存在。

1.2 三个核心区域：工作区、暂存区、版本库

理解Git的第一道门槛，是搞懂它把仓库分成了三个区域。这三个区域的划分，决定了之后所有命令的语义。

工作区就是你在电脑上看得见的那个项目文件夹，里面是你正在编辑的实际文件。暂存区是一个藏在.git目录里的中间状态区域，你可以理解成快递站的分拣区：你还没把包裹发出去，但已经决定哪些东西要进入这次寄送。版本库就是仓库本体，里面存放着一次次的提交历史，每次提交都相当于给当时的文件快照盖了一个章，之后可以随时翻出来。

平时用的git status命令，输出的就是这三个区域之间的差异：哪些文件在工作区改了但没进暂存区，哪些进了暂存区但还没提交。刚开始用Git时，我总觉得一次操作里要区分“改动已暂存”和“已提交”，太繁琐了。后来才明白这个设计的妙处：它允许你在一堆改动里只挑一部分提交，比如把修bug的文件和加新功能的文件分开，提交历史就干净得多。毕竟真正遇到问题要回溯的时候，没有人希望看到一条“更新了一些东西”的提交信息。

1.3 快照与提交链：看懂Git的数据模型

Git的底层存储模型也值得花两分钟理解一下。大多数传统版本控制工具保存的是“文件差异”，也就是每次记录“这次改了哪几行”。Git则不同，每次提交保存的是一份完整的文件快照。也就是说，当你在某个提交里看到一个文件，Git实际上是原样存了一份当时的完整内容。它会用压缩算法处理，所以仓库不会无限膨胀，但逻辑上要清楚：Git的每一次提交，都是一个独立完整的状态。

每次提交除了文件快照之外，还会记录提交人、提交时间、提交信息，以及一个指向父提交的引用。这一串提交连起来，就成了一条链条，而每一个提交的哈希值（一串类似a3f2b8c1...的十六进制字符）就是它在链条中的唯一编号。分支的本质更简单：分支不过是一个指向某次提交的“指针”名字。这也是为什么Git创建分支是瞬间完成的，因为它并不复制文件，只是在指针表里加了一行。

我先把数据模型讲清楚，是因为后面所有命令都能在这个模型上推演出来。比如git reset，本质就是把当前分支的指针重新指到历史的某一次提交上；git merge，本质就是找一个共通的提交，然后把两条分支的改动合并到新的提交里。理解了这一层，你就不必死记硬背命令参数了。

2. 安装与环境准备：把第一步走稳

2.1 各平台安装方式与版本选择

Windows用户有两种主流方式。第一种是去Git官网下载Windows安装包，这是一站式的exe安装程序，装完就带Git Bash、Git GUI和基础配置。第二种是用包管理器，Windows 10及以上系统可以直接在PowerShell里执行winget install --id Git.Git -e，装完需要重新打开终端才能用。我个人推荐第一种，因为Git Bash这个终端环境对新手非常友好，它的命令风格和Linux保持一致，很多教程里的命令在Windows自带的CMD里会出问题，但在Git Bash里都能正常跑。

macOS上如果装了Homebrew，执行brew install git是最省事的；也可以去官网下dmg。Linux下不同发行版命令不一样，Debian/Ubuntu系用sudo apt install git，CentOS/RHEL系用sudo yum install git。版本方面不用追求最新，稳定版即可，2.40以上的版本在日常使用中都没什么差别，重要的是安装后先验证：git --version能正常输出版本号，就说明装好了。

这里有个容易被忽略的细节：安装完成后，Git自带的换行符处理方式建议保持默认。Windows环境装Git时，安装向导会问“Checkout Windows-style, commit Unix-style line endings”，这个选项能自动把文件在本地转成Windows换行，提交到仓库时又统一成Unix换行。千万别自作聪明去改，否则一个项目里不同人提交出来的文件换行符不一致，会引发大量无意义的merge冲突。

2.2 安装后必做的两件小事：user.name与user.email

很多新手第一次提交后打开日志，发现提交人姓名是一串乱码或者空的，就是因为跳过了全局配置。Git在每次提交时必须记录“谁提交的”，这个身份信息来自两个配置项：user.name和user.email。不设置的话，Git会尝试从系统用户名推断，要么生成一个乱七八糟的默认值，要么直接拒绝提交。

打开终端，依次执行两条命令即可：

git config --global user.name "zhangsan" git config --global user.email "zhangsan@example.com"

名字建议用拼音或英文，尽量避免中文，因为部分终端显示中文用户名会有编码问题。邮箱建议用你常用账号注册的邮箱，这个邮箱会和你在GitHub、Gitee、GitLab上的账号关联，以后提交记录会自动指向对应的平台账号。

还可以用git config --list查看当前所有配置。如果一个人同时有工作项目和个人项目，需要不同身份，可以去掉--global参数，在具体仓库目录里单独设置这套配置，Git采用的原则是“就近生效”，仓库级别的配置覆盖全局配置。这个设计很实用，比如在公司电脑上，工作仓库用公司邮箱，个人项目用个人邮箱，提交记录不会混乱。

2.3 SSH密钥配置：一次配置，长期免密

配置SSH密钥，是入门阶段最值得花时间的一件事。Git和远程平台之间的数据传输方式一般有两种：HTTPS和SSH。HTTPS用起来简单，克隆地址直接填，但每次推送通常都需要输入账号密码，后来GitHub和Gitee出于安全考虑严格要求用Personal Access Token替代密码，这个过程“劝退”了不少新手。而SSH方式采用的是公私钥认证，把公钥上传到平台的账号设置里，私钥留在本地，之后所有git push、git pull都直接走加密通道认证，不再需要输密码。

生成密钥的标准步骤是这样的：

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

这条命令会在你本机生成一对密钥：公钥是~/.ssh/id_ed25519.pub，私钥是~/.ssh/id_ed25519。执行过程中会提示设置安全短语，直接回车即可，意思是私钥不额外加密，方便日常使用。然后用cat ~/.ssh/id_ed25519.pub查看公钥内容，把那一整行复制下来。

接下来分别到GitHub的Settings → SSH and GPG keys、Gitee的设置 → SSH公钥、GitLab的User Settings → SSH Keys页面，粘贴保存即可。同一个公钥放到三个平台，完全没有问题，因为公钥本来就是公开的，真正保密的是私钥。配置完后，用ssh -T git@github.com、ssh -T git@gitee.com、ssh -T git@gitlab.com分别测试，看到成功提示就说明认证已经通了。选ed25519而不是传统RSA的原因有两个：一是算法更现代、长度更短、安全强度更高，二是现在主流托管平台都完整支持，没必要用老的非对称加密算法。

3. 日常使用高频命令：提交、查看、回滚

3.1 两种开始方式：clone与init

接触一个Git项目，第一种情况是从现有的远程仓库拿到代码，这时候用git clone。执行git clone <仓库地址>之后，Git会自动把远程仓库完整复制到本地，同时默认配置好一个叫origin的远程引用，并自动帮你关联到当前的主流分支。你在本地立刻就能看到所有历史提交，也能正常修改和提交。对于“加入一个已有项目”的场景，clone是最标准的起步方式。

第二种情况是本地已经有了一个项目，想把它变成Git仓库，这时候在项目根目录执行git init。执行之后，目录里会多出一个隐藏的.git文件夹，Git的全部状态数据都放在这里面。注意这个文件夹非常重要，不要手动去删或改里面的文件，否则仓库可能损坏。

init之后往往跟着第一次提交。新手常见的问题是不知道第一次提交要不要把所有文件都加进去。我的建议是：先想清楚哪些文件不该进Git仓库（比如IDE配置、依赖包目录、构建产物），把忽略规则设置好，再执行git add .把剩余文件加入暂存区，然后提交。一上来就把所有东西无脑提交，后面再想把误提交的文件从历史里清理干净，要费很大功夫。

3.2 完成一次提交的完整路径

一次标准的Git提交流程是三个命令的组合：先git status看看当前状态，再git add把指定文件加入暂存区，最后git commit做快照记录。

git status git add src/App.js git commit -m "修复登录页面的表单校验逻辑"

这里的git add可以指定具体文件，也可以用git add .把所有改动一次性加入。后一种方式图省事，但存在隐患：如果你在项目里临时生成了日志、调试文件，它们也会被一起加入暂存区。所以更稳的做法是，每次提交前养成git status的习惯，看清楚到底哪些文件会被纳入这次提交。

提交信息也是一门学问。好的提交信息应该能让人不看代码，就知道这次提交干了什么。不要写“update”这种废话，哪怕多写几个字，比如“修复用户头像上传后无法显示的bug”，过三个月你自己回来看，也能一眼明白这次改动的意图。如果改动比较复杂，可以用两个-m参数，第一个写简短标题，第二个写详细说明，这样在log里既能看到简明摘要，也能查到背景信息。

提交完成后用git log --oneline --graph --decorate查看提交历史，--oneline让每次提交只显示一行标题，--graph显示分支拓扑，--decorate显示分支和标签指向。这个命令我几乎每天都会敲，它是我理解项目演进历史的窗口。

3.3 撤销操作全家桶：restore、reset、revert

撤销大概是Git里最让人迷惑的区域，因为不同场景对应不同命令。我按“改动处在哪个阶段”来梳理一遍。

改动还在工作区，尚未add，发现写错了，想直接丢弃：

git restore <file>

这个命令是Git 2.23以后推荐的写法，老版本用的是git checkout -- ，旧项目里看到后者也不用惊讶，两者效果一致。改动已经add进暂存区，想撤销暂存：

git restore --staged <file>

提交之后发现信息写错了，或者只想回退本地这次提交、保留文件改动，用软回退：

git reset --soft HEAD~1

这里的HEAD~1表示当前提交的上一级，也就是前一次提交。--soft的含义是“只移动分支指针，工作区和暂存区都保留”，所以撤销提交后的改动内容全部还在，可以重新提交。如果把--soft换成--hard，危险性立刻上升：工作区和暂存区都会恢复到目标提交时的状态，所有未提交的改动会直接消失，而且不可找回。新手慎用，我自己就因为git reset --hard误删过一整个下午的代码。

以上这些命令都只适用于提交尚未被推到远程的情况。一旦已经push到远程仓库，就不能再用reset去“改写历史”了，因为远程可能已经被其他人基于旧历史继续提交，你强行把历史倒回去，别人那边会直接卡住。正确做法是用revert：

git revert HEAD

git revert会生成一次新的提交，这个提交的内容是“反向操作上次的改动”。比如上次提交新增了3行代码，revert会在新提交里删除这3行。这样处理的好处是历史完全线性往前推进，不会产生分叉，其他人的pull不会出问题。

3.4 修改已提交消息：git commit --amend的实战用法

很多新手在第一次提交后马上发现提交信息写错了，这时候最容易想到“那我去搜一下怎么改”。其实Git内置了amend，专门处理“最后一次提交”的修正。

要把最近一次提交的信息改成正确内容：

git commit --amend -m "新的提交信息"

如果你发现漏了一个文件，想把它并入最近一次提交，而不额外增加一条提交记录，先add那个文件，再执行git commit --amend，不加-m参数，Git会复用原来的提交信息。这种用法非常适合在开发一个功能的迭代过程中，保持提交粒度统一。

但amend有一个必须牢记的前提：只适用于“还没推送”的最后一次提交。如果已经push，你在本地amend之后，本地历史就比远程多出一个新的哈希，普通的git push会被拒绝，因为远程和本地已经分叉了。此时强行解决需要git push --force，这个操作会把远程历史强行覆盖成你本地版本。如果仓库里只有你一个人用，这么干问题不大；一旦有同事的提交基于旧历史，他会突然发现自己本地的东西全都不见了。我在这上面吃过亏，团队协作时原则就是：已经推送的提交，绝不用amend去改，哪怕信息写错了，老老实实再补一条revert或新的提交。

4. 分支管理：团队协作的地基

4.1 分支的本质：指针与提交链

很多人对分支感到恐惧，觉得分支操作很复杂。其实一旦理解了分支就是一个指向提交的指针，一切都豁然开朗。某个时刻你执行git branch dev，Git做的事情只是新建了一个名为dev的指针，指向当前所在这条提交链的顶端。这个操作不需要复制任何文件，所以速度极快。

那么HEAD又是什么？HEAD是一个特殊的指针，它指向“你当前所在的分支”。你切换分支时，本质上只是把HEAD这个指针从dev移到main；与此同时，Git会根据目标分支指向的提交去更新工作区的文件内容。这就是为什么切换分支前最好先提交或暂存当前改动——Git在切换时会让工作区匹配目标提交的文件状态，如果工作区有未提交的修改，就可能导致切换失败或者把混乱状态带到别的分支上。

4.2 常用分支操作与合并方式

一套完整的分支操作命令大致是：

git branch dev # 创建dev分支 git branch -a # 查看所有本地和远程分支 git switch dev # 切换到dev分支 git switch -c feature/login # 创建并切换到新分支 git branch -d dev # 删除已合并的分支

请注意，新版Git推荐用switch命令切换分支，语义比checkout清晰；checkout同时承担“切换分支”和“恢复文件”两个职责，新手容易混，switch只干一件事：切换分支。

合并分支时，git merge dev会把当前分支和dev分支的改动汇合。如果当前分支从分叉之后没有产生新提交，Git会走fast-forward方式，直接把当前分支指针前进到dev的提交上，历史是线性的。如果两个分支都有各自的新提交，Git会做一次three-way merge，生成一个包含合并内容的“合并提交”。有些团队希望保留分支存在的痕迹，会刻意用git merge --no-ff dev强制生成合并提交，这样在历史上能清楚看到哪些功能是从哪些分支汇入的。

merge之前有个小建议：保持当前工作区的干净。如果有未提交的改动，Git可能会拒绝merge，或把改动带到合并后的状态里。实在想带，要么先提交，要么用git stash把改动临时存起来，合并完再git stash pop取回。

4.3 合并冲突：为什么会冲突，以及如何处理

冲突是Git里不可避免的一部分，理解它就不怕它。冲突的本质是：两个分支都修改了同一个文件的同一个区域，Git不知道应该以谁为准。比如你和同事都在配置文件的第三行加了内容，你commit，他commit，把两条分支合并到一个点时，冲突就出现了。

冲突发生时，Git会在冲突文件里插入冲突标记：

<<<<<<< HEAD 你当前分支的内容 ======= dev分支的内容 >>>>>>> dev

不需要害怕这些标记，它们只是提示你去做人工决策。打开文件，把需要的内容保留，把不需要的内容和冲突标记一起删除，保存后再执行git add ，然后git commit完成合并。整个过程里不要用git commit --amend，正常的合并提交就是最好的结果。

减少冲突的最好方式不是“少写代码”，而是保持同步节奏。在一个功能分支上开发时，定期把main分支的最新改动合并进来，避免分支落后太久，这样每次要合并回main时，需要协调的差异范围会小很多。还有一条实操经验：统一团队的代码格式化规则，换行、空格这类差异经常制造毫无意义的冲突。

5. 远程协作：把本地仓库和远程仓库打通

5.1 GitHub、Gitee、GitLab：三个托管平台怎么选

既然讲远程协作，绕不开三个平台。GitHub是目前全球最大的开源代码托管社区，几乎所有的知名开源项目都在上面，找源码、参与开源、学习业界知名项目的代码，首选它。Gitee是国内广泛使用的代码托管平台，中文界面、本土化做得比较完善，无论是个人项目还是企业协作，在国内团队中都有大量用户。GitLab则是一款完整的开源DevOps平台，除代码托管外，还内置了完善的CI/CD流水线、依赖扫描、容器镜像管理等功能，最有特色的是它支持私有化部署，很多企业出于数据安全和内部流程的考虑，会把GitLab部署在自己的服务器上。

选择建议是这样的：做开源、想和国际社区接轨，选GitHub；团队在国内、希望协作流程和平台操作更贴近中文环境，Gitee很合适；如果公司需要在内网搭一套完整的研发平台，数据完全由自己掌控，GitLab是最成熟的方案。这三个平台都基于Git，命令层面的操作完全一致，无非是在网页上创建仓库后，复制给你一段“通过命令行推送代码到远程仓库”的指令，地址前缀不同而已。

这三者其实并不冲突。很多开发者的做法是GitHub和Gitee同时维护同一份代码，本地配置两个远程地址，push时各推一份。我在Gitee和GitHub上都建立了一些镜像项目，本地根目录下Git会自动记住每个远程站点分支的分支跟踪状态，日常操作不会有任何打架。

5.2 远程四件套：remote add、push、pull、fetch

在远程平台创建好一个新仓库后，本地把一个既有项目推送上去的完整流程是：

git remote add origin <仓库地址> git branch -M main git push -u origin main

第一行给远程仓库起了一个简短别名。习惯上大家都用origin代表“主远程仓库”。第二行把当前分支重命名为main，这是现在Git和各类平台默认的主流分支名。第三行的-u参数是“设置上游跟踪关系”，意思是让本地main分支记住它对应的远程分支是origin/main，有了这层关系，以后直接敲git push不再需要每次指定远程和分支。

再说pull和fetch的区别。git pull是一个复合动作：先fetch（从远程下载最新提交和分支信息），再根据情况执行merge（把远程内容合并到当前分支）。你可以直接用git pull，省心。但有些场景需要更细腻的控制，比如你想先看看远程到底有哪些变化、会不会冲突，就先用git fetch，然后用git log origin/main查看远程分支的提交，等确认无误后再git merge origin/main手动合并。如果当前工作区有未提交的改动，直接pull可能被拒绝，Git为了保护你的工作区会自动拦截，并提示“Your local changes would be overwritten”。

5.3 一次真实的远程冲突处理流程

假设你和同事都在main分支上开发。你改了A文件，他改了B文件。你先推送，push成功。之后他push之前，先执行git pull，Git会把远程的最新提交拉下来，跟他的本地改动一合并，他没有冲突，于是git push成功。这样的协作很顺畅。

但如果你们俩都改了同一个文件，比如config.js，他pull的时候Git就会提示合并冲突。冲突处理后，他需要git add config.js，再git commit生成一个合并提交，最后git push。这里的关键点在于：远程仓库不会直接接受一个和最新历史有分叉的push，Git要求“先同步，再推送”。所以遇到“git push rejected（non-fast-forward）”的提示时，先冷静，git pull解决冲突，再push即可。不要为了省事去用git push --force，那会覆盖远程历史，把同事的提交丢弃掉。

团队协作中还有一个值得养成的习惯：push之前先pull，把同步当作每日操作的默认动作。很多冲突其实都是因为分支长期没有同步，积累了大量碰撞点才触发的。

6. 常见问题与避坑指南

6.1 提交信息写错、误删分支、误reset后怎么救

Git最强大的地方在于，大部分误操作都有救，关键是知道去哪找。

误reset后的恢复，用reflog。git reflog会展示HEAD最近的每一次移动记录，包括reset、merge、checkout等所有操作的前后哈希。即使你git reset --hard把分支指针倒回了旧提交，reflog里依然能查到刚才那个“未来”的提交哈希。查到之后，git reset --hard <那个哈希>就能回到误操作之前的状态。这个命令可以看作是Git的时光机，是我处理过最多新人求助的场景。

误删分支也类似。删掉的分支并不会立刻从仓库消失，它最后一次指向的提交还在对象库里躺着。用git reflog找到那个提交哈希，git branch <恢复的分支名> <哈希>就能把分支重新拉回来。要注意的是，reflog记录只是本地仓库的“操作日志”，它不会因为网络而同步，所以也意味着误操作后越早处理越稳妥，别拖太久，否则记录可能被新的提交淹没。

6.2 认证失败与免密配置的几种解法

HTTPS协议推送时要求输入凭证，这是新手高频问题。现在GitHub和Gitee都已经不支持直接用账号密码做git操作，而必须使用Personal Access Token。在平台网页生成一个只具有相应权限的token，然后把它作为密码输入，这是第一种解决方式。

更顺手的解决方案还是回到SSH密钥。把公钥配置到平台后，把仓库的remote地址从HTTPS换成SSH格式即可：

git remote set-url origin git@gitee.com:用户名/仓库名.git

也可以保留HTTPS方式但配置Git的凭证管理器，让系统帮你记住凭证，配置方式是对应平台的账号设置里开启持久化，或者是Git自身维护一个本地凭证文件。

此外还有一些和远程平台无关的缓存在本地的问题。比如你在一台电脑上同时配置了多个平台，或者换了新电脑后密钥没复制过去，这时推送会提示权限拒绝。依次检查ssh-keygen生成的密钥是否存在于~/.ssh目录，公钥是否已粘贴到目标平台，以及远程地址是否正是SSH格式，基本就能定位问题。

6.3 那些不该提交进仓库的文件

新手最常见的仓库混乱，是把一堆不该提交的文件塞了进去。比如.env环境变量文件，里面经常写着数据库密码、API密钥，一旦推到远程再被公开到开源仓库，等于泄露了敏感信息；再比如node_modules、target、build这些依赖目录或构建产物，它们体积大，人工生成，完全可以重新构建，没有任何进仓库的必要。还有IDE专属配置，比如.idea、.vscode，这些内容和个人偏好强相关，别人拉下来也用不上，反而会造成大量无意义的diff。

解决方法是在仓库根目录创建.gitignore文件，把文件和目录写进去。一个简单的示例：

# 环境变量 .env .env.local # 依赖目录 node_modules/ # 构建产物 dist/ build/ target/ # IDE配置 .idea/ .vscode/ # 系统文件 .DS_Store

git status里还会看到一些已经被跟踪的文件，就是你之前误提交的。把它们从跟踪列表里移除，但保留本地文件，用：

git rm -r --cached <路径>

执行后再提交一次，文件就会从版本库里消失，但本地磁盘上仍然存在。

如果你问“Gitee怎么上传大文件”，我的回答是：不要直接传，Git的设计目标本来就是保存文本代码。对于超过平台限制的文件，正确的方案要么是用Git LFS扩展来跟踪和存储大文件，要么就把大文件放到专门的对象存储，把下载地址放进代码里。把几GB的安装包硬塞进Git仓库，只会让仓库膨胀到clone都缓慢，还会很快撞上平台的大小限制。

6.4 新手上路高频错误速查表

我把日常答疑里出现频率最高的几个问题整理成了一张表，直接照着排查，比自己乱试要快得多。

最后说点我个人的体会。带新人这些年，我发现大多数人学Git卡住，不是因为记不住命令，而是因为没有建立“三个区域 + 提交链 + 指针”这套心智模型。一旦想明白提交是一连串快照、分支只是一个指针、工作区和暂存区决定了命令作用对象，几乎所有操作都能靠逻辑推导出来。这套模型打通之后，GitHub、Gitee、GitLab上的各种功能，无非就是在这套核心机制上叠加上去的外围服务。

这一篇把Git本身的根扎稳了，后续我会分别拆GitHub的开源协作、Gitee的项目托管细节、GitLab的私有化部署与CI/CD实践，到时候再继续聊。