Git 和 GitHub，这两个词对写代码的人来说，基本是躲不开的。哪怕你只是个刚入门的学生，第一次把代码传到网上，用的多半也是它们。但说实话，很多人对 Git 的认知停留在“照着命令敲，能 push 上去就行”的程度，遇到冲突、误删、回退、协作乱套的时候，才开始觉得这玩意儿没那么简单。
这篇笔记不是官方文档的翻译，也不是命令大全的罗列。我把它定位成一份从“会用”到“能用明白”的实操记录，里面包含我实际工作中反复用到的东西、踩过的坑，以及我对 Git 设计逻辑的一些理解。适合刚接触 Git 的同学通读建立体系，也适合已经用了一段时间但总觉得哪里没搞透的人查漏补缺。
1. Git 的核心机制与认知重构
1.1 快照存储：Git 不是差异备份
很多人一开始会用 Git 记版本，但内心其实把它理解为“每次保存一个文件的副本”，或者类似网盘的同步工具。这是最大的认知误区。
Git 的核心存储模型是快照（Snapshot），不是差异（Delta）。每次 commit，Git 会对所有文件进行整体快照，并保存指向这个快照的引用。如果某些文件没变，Git 不会重复存文件内容，而是直接引用之前的文件对象。这意味着：你每次 commit 的其实是整个项目的状态，而不是“这次改了哪几行”。
这个设计带来的好处非常实在：Git 的仓库历史本质上是一棵有向无环图，你可以在任意节点之间跳转、对比、合并，而不需要从头计算增量。对比 SVN 那种集中式的差异存储，Git 在分支切换和合并时快得多，原因就在这里。
我试过用一个文件数量很多的旧项目做测试，项目里有大量类似但不同的资源文件。在 SVN 下切分支可能要几十秒，因为要从服务器拉取差异；Git 下几乎是瞬时的，因为本地就有完整的快照。这也是后来我彻底转投 Git 的核心理由。
1.2 三个区域：工作区、暂存区、版本库
理解 Git 的第二个关键，是把“三个区域”刻在脑子里：
- 工作区（Working Directory）：就是你电脑上能看到、能编辑的文件目录。
- 暂存区（Staging Area / Index）：可以理解成“提交候选区”。git add 就是把改动放进暂存区。
- 版本库（Repository）：commit 之后，暂存区的快照就被永久记录到版本库里。
这三个区域的划分，是 Git 最容易被忽略但极其重要的设计。它让你可以把一次提交拆分成“改代码”和“挑代码”两步：你在工作区里可能改了五六个文件，但不一定想把这五六个文件全放进同一次 commit 里。比如你修了一个 bug，又顺手改了一点格式化，你想把这两件事分开提交，那就靠暂存区来筛选。
实际工作中我是这么用的：改完代码先 git add 指定文件，再 git status 看一眼暂存区里到底有哪些文件，确认没有“夹带私货”再 commit。这么做的好处是提交历史干净整齐，后续用 git bisect 二分定位问题时，每一条记录都能对应一个逻辑变更，非常省心。
1.3 指针模型：分支只是一张贴纸
Git 里的分支，本质上就是一个可移动的指针，指向某个 commit。创建分支不是复制代码，而是创建一个新的引用。这是 Git 分支操作极轻量的原因。
配合理解这个概念，HEAD 也是一个指针，它指向你当前所在的提交（更准确地说，是当前分支的引用）。当你切换分支时，Git 做的事就是改变 HEAD 的指向，然后更新工作区的文件内容。理解了这层模型，你就明白为什么 Git 鼓励多建分支、多合并——因为分支成本极低。
很多人怕建分支，觉得“分支出去了就收不回来”。我最初也有这种顾虑，后来明白分支就是贴纸，随便撕随便贴，后悔了删掉重建就行（只要没被垃圾回收）。
2. 日常高频操作与场景化用法
2.1 提交信息规范：写清楚比写多更重要
提交信息（Commit Message）这件事，看起来人人会写，实际上大部分人都写不好。我见过太多“update”“fix bug”“提交”这种完全无法定位问题的历史记录。等出问题需要翻历史时，简直灾难。
我的习惯是，提交信息严格遵循以下格式：
<type>(<scope>): <subject> <body>type 用固定词表：feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（杂项）。scope 是影响的模块，比如 auth、storage。subject 用祈使句简洁描述，body 是补充说明，写清楚动机和影响面。
比如：
fix(auth): 修复 token 过期后跳转逻辑错误 移动端在 token 过期后没有清理本地缓存， 导致用户退出后再次登录时出现白屏。这种规范的好处是，git log --oneline 一眼扫过去，整个项目的演进脉络清清楚楚。配合 git blame 查代码时，也能快速定位到具体改动意图。
2.2 撤销与回退：吃后悔药的正确姿势
撤销操作是我见过最容易翻车的环节。很多人在网上抄命令，git reset --hard 一敲，然后发现丢了一堆代码，心态直接炸了。
我把常见的“后悔药”场景整理成表，大家按需取用：
| 场景 | 正确命令 | 说明 |
|---|---|---|
| 改了工作区文件，想还原 | git restore | 从暂存区或版本库恢复文件 |
| 已经 add 但不想提交 | git restore --staged | 取消暂存，改动保留在工作区 |
| 提交了但想重新提交 | git commit --amend | 修改最近一次提交信息或内容 |
| 提交了，想回退到某个版本 | git reset --soft | 保留改动在暂存区 |
| 提交了，想彻底丢弃 | git reset --hard | 危险，丢弃所有改动 |
| 提交了，但远程已同步 | git revert | 生成反向提交，安全 |
这里重点说 git revert 和 git reset 的区别。很多人不理解为什么有 revert 这个命令。简单说，reset 是“改写历史”，revert 是“追加历史”。如果提交已经 push 到远程，并且有其他人基于它工作，你用 reset 改写历史会让所有人的仓库都不同步，这是团队协作的大忌。revert 则是生成一个新提交，把之前的改动反向应用一次，历史是线性的，谁都不用额外处理。
2.3 忽略文件：.gitignore 的正确写法
.gitignore 是每个项目必备的文件，但很多人是一路复制粘贴，压根不知道自己忽略了什么。
我遇到过不止一次：项目里该忽略的没忽略，不该忽略的被忽略，结果别人克隆下来跑不起来。最常见的是把 .env 这种环境变量文件提交到了仓库，直接把各种密钥泄露了出去。
我的 .gitignore 编写思路是：
- 按语言和框架分类，用平台生成基础模板（很多工具都能生成），但一定自己过一遍。
- 必须忽略的：依赖目录（node_modules、vendor）、构建产物（dist、build）、临时文件（*.log、.DS_Store、Thumbs.db）、环境配置（.env、.env.local）。
- 谨慎忽略的：不要随手把整个目录无脑忽略，确认某些自定义资源目录需要被跟踪后再加入白名单。
- 提交前验证：用 git check-ignore -v 查一下某个文件到底是被哪条规则忽略的，避免误判。
注意：如果你已经把一个文件提交到了仓库，之后才加进 .gitignore，它依然会被 Git 跟踪。需要用 git rm --cached 把它从索引中移除，再提交变更，才能真正“忘记”它。
3. 分支模型与团队协作实战
3.1 Git Flow 与 GitHub Flow 怎么选
分支模型这东西，没有绝对的对错，只有适不适合团队状态。我经历过的项目里，最常被讨论的是 Git Flow 和 GitHub Flow。
Git Flow 是相对重的模型，包含 master（生产）、develop（集成）、feature（功能）、release（发布）、hotfix（热修）五类分支。它的优点是流程严谨，适合版本发布节奏明确、需要长期维护多个版本的产品。
GitHub Flow 则轻量得多，主干分支就是 master（或 main），所有开发从主干拉 feature 分支，完成后直接向主干发起 Pull Request，审查通过即合并。它不区分 develop 和 release，一切流动都通过 PR 完成。适合持续部署、发布节奏快的团队。
我的经验是：小团队或者个人项目，GitHub Flow 基本够用，复杂分支模型只会在流程上拖慢速度。真正需要 Git Flow 的往往是版本要并行维护、需要给老版本打补丁的项目。
选定模型后，一定要在团队内部统一约定。我见过最混乱的局面是：一部分人习惯直接 push 主干，一部分人走 PR 审查，结果每个人的提交历史各有各的风格，合并时冲突不断。工具本身不会带来协作问题，混乱的使用规则才会。
3.2 Pull Request 的代码审查细节
Pull Request（PR）不只是代码合并的入口，它更是代码审查的载体。我提 PR 和审 PR 有一些固定的检查习惯，分享出来供参考。
提 PR 的人，我建议自查以下问题：
- PR 描述里是否写清楚了“为什么做这个改动”和“怎么验证”？没有好的描述，审查者很难理解你的意图。
- 是否把大改动拆成了多个小 PR？一个 PR 超过 500 行变更，审查效率会直线下降。
- 是否在 PR 标题里标注了类型（feat/fix/docs）？方便对方快速判断优先级。
审 PR 的人，我有一套自己的关注顺序：
- 先看 diff，理解改动的逻辑边界，确认这个 PR 是不是“顺手”改了不该改的东西。
- 再看测试：对应功能有没有补充测试？改动是否破坏了现有测试？
- 最后看命名和注释：变量、函数名是否表意清晰？有没有留下让人摸不着头脑的魔法数字？
有一次审查某个 PR 时，我在 diff 里发现了一个明显的逻辑漏洞：某人用!list.isEmpty()判断是否有元素，但 Java 里list可能本身就为 null，直接空指针。这种情况机器不一定查得出来，但人眼在 code review 时很容易看到。审查的意义就在这。
3.3 合并策略：Merge、Squash、Rebase
Git 合并有几种策略，它们的区别在很多教程里被一笔带过，实际使用时却影响深远。
- Merge Commit：保留所有分支的提交历史，合并时生成一个新的 merge commit。好处是历史完整；坏处是提交图会变得复杂，像一团毛线。
- Squash Merge：把分支的所有提交压缩成一次提交，然后合并到主干。好处是主干历史非常干净；坏处是丢失了分支内提交的细节。
- Rebase Merge：把分支的提交逐个“重放”到主干最新提交之后，历史变成线性的。好处是历史清晰；坏处是重写了提交哈希，绝不能对已推送的公共分支做。
我的使用习惯是：个人开发分支用 Rebase 保持同步，功能完成提交给主干用 Squash Merge 保持历史整洁。但对于长期存在的 release 分支，一次完整的 Merge Commit 能保留合入的上下文，对追溯版本内容很有帮助。
团队协作里有个铁律：不要对已经推送的公共分支做 Rebase。这条规则违反一次，就能体会到什么叫“全组人一起定投到坑里”。
4. 常见问题排查与避坑实录
4.1 合并冲突：别怕，冲突是家常便饭
很多新手遇到冲突就慌，其实冲突只是 Git 告诉你：“我在自动合并时遇到两种改法，不知道该听谁的，你来定一下吧。”
冲突标记长这样：
function greet(name) { <<<<<<< HEAD console.log("Hello, " + name); ======= console.log("Welcome, " + name); >>>>>>> feature/rename-greet<<<<<<< HEAD 到 ======= 之间是当前分支的内容，======= 到 >>>>>>> 是合并分支的内容。你需要做的不是“选一边”，而是根据实际业务语义，把最终想要的结果写出来，然后把三行标记删掉。
解决冲突后，记得用 git status 查看所有冲突文件确认都已处理，再 git add 标记为已解决，最后 commit 完成合并。
我的经验是：大部分冲突其实可以通过“先沟通、后动手”避免。两个人同时在同一个文件的同一个区域改代码，大概率是双方对需求的理解没对齐。Git 只是把这种“没对齐”显性化了而已。
4.2 误删文件与误操作恢复
有一种非常常见的场景：一时手快执行了 git reset --hard，然后发现某次提交里的文件被删了。这时候千万别慌，Git 给了你后悔药，但前提是你得知道药瓶在哪。
只要你的提交还在 reflog 里，就有救。reflog 是 Git 的“操作记录”，记录了 HEAD 指针每一次移动的历史。
操作步骤：
git reflog输出里会列出所有的 HEAD 移动历史，形如：
a123456 (HEAD -> main) HEAD@{0}: reset: moving to a123456 b234567 HEAD@{1}: commit: fix typo in module找到记录误操作之前的提交编号，然后直接：
git reset --hard b234567就能恢复到那次提交的状态。这也是为什么我强烈建议：不要频繁清理 .git 目录下的日志文件，那些是你误操作时的保命符。
4.3 远程仓库连接失败：排查接管
远程仓库（origin）连接出问题，最常见的场景就这几种：
- 认证失败：提示权限不足或用户名密码错误。建议改用 SSH 方式连接，生成密钥后配置到托管平台，比每次输入密码省心得多。
- 地址错误：检查 git remote -v 输出的远程地址，确认是否写错仓库路径。
- 网络问题：长时间无响应，大概率是网络环境导致的。确认请求能正常到达托管平台后，再排查具体报错。
排查远程连接问题的基本步骤：
git remote -v # 查看远程仓库地址 ssh -T git@托管平台域名 # 测试 SSH 认证是否成功 git fetch origin # 测试远程拉取是否正常我用一条经验总结：遇到 Git 报错，先把英文报错原文复制到搜索框里搜一遍，比自己去猜省时间得多。Git 的报错信息通常都写得非常明确，问题是很多人只看“红字”就慌了，根本没仔细读内容。
5. 把 Git 用好的一些额外心得
5.1 用别名精简日常操作
Git 命令有时候确实啰嗦，我给自己配了一批别名，每天都能用到：
git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg "log --oneline --graph --decorate --all"配置之后，git lg 可以清晰看到提交历史的分支图结构，比默认的 git log 直观得多。第一次给同事展示这个效果时，对方说“原来我从来没用对过 git log”。
5.2 用 Git 做备份与实验
很多人只在“写代码要发给别人”时才想到 Git，这是对的，但不够聪明。Git 完全可以当作个人项目的即时备份工具和实验沙箱：
- 重要节点打标签（git tag），后续想找某个状态一找一个准。
- 想试一个大胆的重构，先建分支再改，改坏了删分支重来，完全无副作用。
- 跨设备同步代码，用远程仓库作为中转。我在公司和家里各有一套环境，同步只需一条 push 和一条 pull。
这种用法把 Git 从“代码工具”升级成了“生产工具”，价值完全不同。
5.3 提效套路：从复用模板到自动化检查
基于多年使用经验，我每次初始化仓库都会做几件固定的事：
- 配好 .gitignore，避免垃圾文件入库。
- 写一个规范化的 README，包含项目简介、启动命令、目录结构、环境依赖。
- 创建多个分支（main、develop，如果团队需要再加别的），并在托管平台设置默认分支和分支保护规则。
- 如果项目是多人协作，写一份 CONTRIBUTING 文档，说明提交信息和 PR 的规范。
这几件事能省掉后续协作中大量“解释成本”。毕竟，工具用得再熟练，不如从一开始就不制造混乱。
在我个人的实际操作中，最深的体会是：Git 的学习曲线不在命令记没记住，而在“模型理没理清”。快照、三个区域、指针、远程引用——这四个概念想透了，所有命令都只是表达方式。之后再遇到诡异问题，你能推断出它背后发生了什么，而不是搜一个命令碰运气。这份笔记写到最后，我依然觉得 Git 最迷人的地方，是它在设计上给了操作者极大的自由度和安全感。只要你的快照还在，你就永远有退路。
