1. 从“代码存档”到“时光机”：Git到底解决了什么麻烦
很多人第一次接触Git，是被“版本控制”这四个字吓退的。听起来像是某种只有大型团队才用得上的重型武器，跟个人开发者、写文档的、做设计的没什么关系。但实际情况恰恰相反——Git最初被创造出来，就是为了解决一个非常具体、非常要命的麻烦：如何让一群人同时改同一堆文件，还不把彼此的活儿搞丢。
在Git出现之前，Linux内核的开发团队用的是一套叫BitKeeper的商用版本控制工具。这套工具确实好用，但它有个致命问题：授权是收费的，而且授权条款随时可能变。2005年，BitKeeper的授权被收回，整个Linux内核社区一下子失去了协作的“中枢神经”。你可以想象那个场面：几千个开发者，每天提交上百个补丁，突然之间没有工具来合并这些改动了。用邮件列表硬扛？试过，结果是补丁满天飞，冲突处理到崩溃。
于是，Linux的创始人做了一个决定：自己写一个。目标很明确——快、分布式、能扛住大规模并发提交。这就是Git的起点。它不是为了做“更好的BitKeeper”，而是为了解决一个当时没人解决好的问题：在没有中心服务器的情况下，让每个开发者手里都有一份完整的代码历史，同时还能高效地合并彼此的改动。
这个“分布式”的设计，是Git最核心的基因。它意味着你本地就有一个完整的仓库，提交、回滚、查看历史，全都不需要联网。你可以把它理解成：每个人手里都有一本完整的账本，而不是只有会计那里有一本总账。这个设计带来的好处是显而易见的——离线工作、速度快、不怕中心服务器挂掉。但代价也很明显：概念模型比集中式工具复杂得多，学习曲线陡峭。
我见过太多人卡在“暂存区”这个概念上。为什么改完文件还要git add一下？直接提交不行吗？这个问题的答案，藏在Git的设计哲学里。Git把“工作区”和“仓库”之间加了一个“暂存区”，不是为了折腾你，而是为了让你能精确控制每一次提交的内容。你可以改了十个文件，但只想提交其中三个相关的改动，剩下的七个继续改。暂存区就是那个“挑选台”，让你把要提交的改动先放上去，确认无误再打包提交。
理解了这一点，你就能明白为什么Git的命令看起来“多此一举”了。git add不是多余的步骤，而是给你一个反悔的机会。git commit也不是简单的保存，而是给当前暂存区的内容拍一张快照，并附上一句说明。这张快照会永久保存在本地仓库里，除非你主动删除，否则它一直在。
所以，Git的本质是什么？它是一个分布式的快照管理系统，每个快照都指向一个完整的文件状态，而不是记录文件之间的差异。这个设计让分支和合并变得极其轻量——创建一个分支，只是新建一个指针，指向某个快照；合并两个分支，就是把两条快照链上的改动整合到一起。这也是为什么Git的分支操作快得离谱，几乎瞬间完成。
2. 快照、指针与对象：Git内部到底在存什么
如果你只停留在“会用”的层面，git add、git commit、git push三板斧确实能应付大部分日常。但一旦遇到冲突、回滚、找回丢失的提交，不懂内部原理就会寸步难行。Git的底层其实非常简洁，核心就三种对象：blob、tree、commit。理解了它们，你就理解了Git的一切。
2.1 blob：文件内容的“指纹”
blob是Git里最基本的存储单元，它只存文件的内容，不存文件名、不存路径、不存权限。你可以把它理解成文件内容的“指纹”——同样的内容，不管放在哪个文件里，blob都是一样的。Git会对内容做一次SHA-1哈希运算，得到一个40位的十六进制字符串，这个字符串就是blob的ID。
举个例子，你有一个文件叫readme.txt，内容是hello git。Git会计算hello git的哈希值，假设是abc123...，然后把内容压缩后存到.git/objects/abc/123...这个路径下。注意，文件名readme.txt并没有被存进blob里。那文件名存哪儿了？答案是tree对象。
这个设计的好处是：如果你把readme.txt改名为readme.md，内容不变，Git不需要重新存储文件内容，只需要新建一个tree对象，把文件名和blob的对应关系改一下就行。这就是为什么Git的重命名操作几乎不占空间——它只改指针，不复制内容。
2.2 tree：目录结构的“快照”
tree对象解决的是“文件和目录的对应关系”。它里面存了一堆条目，每个条目包含：文件模式（比如普通文件、可执行文件、目录）、文件名、以及指向blob或子tree的哈希值。一个tree可以包含多个blob和多个子tree，这样就形成了完整的目录树。
你可以把tree理解成一个目录的快照。根目录是一个tree，里面的每个子目录也是一个tree，层层嵌套，直到最底层的文件blob。当你执行git commit时，Git会为当前暂存区的所有内容生成一棵完整的tree，然后把根tree的哈希值存进commit对象里。
这里有个细节值得注意：Git只存储发生变化的tree和blob。如果你改了根目录下的一个文件，Git只会新建这个文件的blob、新建包含这个文件的子tree、新建根tree，其他没变的子tree直接复用之前的哈希值。这就是Git高效存储的核心——内容寻址 + 结构共享。
2.3 commit：快照链上的“时间戳”
commit对象是最容易理解的：它包含一个指向根tree的指针、作者信息、提交时间、提交说明，以及一个或多个父commit的指针。第一个commit没有父指针，之后的每个commit都指向前一个commit，形成一条链。
这条链就是“历史”。当你执行git log时，Git就是从当前commit开始，沿着父指针一路往回走，把每个commit的信息打印出来。分支是什么？分支就是一个指向某个commit的可变指针。main分支指向最新的commit，dev分支指向另一个commit。切换分支，就是让HEAD指向不同的分支指针。
理解了这个模型，很多“神奇”的操作就变得理所当然了。比如git reset --hard HEAD~1，本质上是把当前分支的指针往回挪一个commit，同时把工作区和暂存区也重置成那个commit的状态。git revert则是新建一个commit，这个commit的内容是“反向应用”目标commit的改动，历史不会被改写，适合已经推送到远端的场景。
2.4 引用日志：你的“后悔药”
Git还有一个极其重要的机制：引用日志。每当你移动分支指针或HEAD时，Git都会在.git/logs/目录下记一笔。这意味着即使你误删了分支、执行了reset --hard，只要引用日志还在，你就能找回之前的commit。
我踩过最惨的一次坑，是在一个功能分支上执行了git reset --hard，把三天的改动全清了。当时第一反应是“完了”，但冷静下来后，用git reflog查了一下，发现之前的commit哈希还在，直接git checkout回去，三天的活儿全回来了。从那以后，我养成了一个习惯：执行任何可能丢失改动的命令之前，先跑一遍git reflog确认一下当前状态。
引用日志默认保留90天，足够你应对绝大多数误操作。但要注意，它只记录本地操作，不会同步到远端。所以如果你在本地删了分支又没推送到远端，引用日志就是唯一的救命稻草。
3. 分支模型：为什么Git的分支“不要钱”
如果你用过集中式版本控制工具，一定对“创建分支”这件事有心理阴影——慢、占空间、合并起来像打仗。但在Git里，创建一个分支只需要新建一个41字节的文件（40位哈希值加一个换行符）。这个差异背后，是两种完全不同的设计哲学。
3.1 分支的本质：一个可移动的指针
在Git里，分支不是“复制一份代码”，而是一个指向commit的指针。当你执行git branch dev时，Git只是在.git/refs/heads/目录下新建了一个叫dev的文件，里面写着当前commit的哈希值。就这么简单。
这意味着什么？意味着你可以毫无心理负担地创建几十个分支，每个分支做一件小事，做完就合并、删除。分支的创建和销毁成本几乎为零，这直接改变了开发者的工作方式。在集中式工具里，大家倾向于“少开分支，多提交”；在Git里，正确的做法是“每个功能一个分支，频繁切换，快速合并”。
我见过一个团队，所有人都在main分支上直接提交，理由是“开分支太麻烦”。结果就是：任何一个人的半成品代码都会影响其他人，代码审查形同虚设，回滚一个功能要手动挑拣commit。后来他们改成“功能分支 + 合并请求”的模式，代码质量立刻上了一个台阶。不是因为他们突然变勤快了，而是因为Git让正确的做法变得比错误的做法更省事。
3.2 合并与变基：两种整合策略的取舍
把两个分支的改动整合到一起，Git提供了两种方式：merge和rebase。这两个命令经常被拿来比较，但很多人没搞清楚它们各自的适用场景。
git merge的做法是：找到两个分支的共同祖先，然后把两个分支的改动合并成一个新的commit。这个commit有两个父指针，历史呈现出“分叉再汇合”的形状。优点是保留了完整的历史脉络，你能清楚地看到哪些改动是在哪个分支上做的。缺点是历史图会比较乱，尤其是频繁合并的时候。
git rebase的做法是：把当前分支的commit“摘下来”，然后“重新应用”到目标分支的最新commit上。历史变成一条直线，看起来非常干净。但代价是改写了commit的哈希值，如果这些commit已经推送到远端，其他人拉取时就会遇到冲突。
我的经验是：本地分支用rebase保持整洁，公共分支用merge保留历史。具体来说，你在自己的功能分支上开发时，可以定期git rebase main把主分支的最新改动同步过来，这样你的commit始终“长在”最新的代码上。但当你把功能分支合并回main时，用git merge --no-ff，强制生成一个合并commit，这样主分支的历史上能清楚地看到“这里合并了一个功能”。
注意：永远不要对已经推送到远端的公共分支执行rebase。如果你不确定某个分支是否被别人依赖，先用
git branch -r看看远端有没有对应的分支，有的话就别rebase。
3.3 冲突处理：不是“错误”，而是“信息”
很多人遇到合并冲突就慌，觉得是自己操作错了。其实冲突不是错误，而是Git在告诉你：这两个改动都改了同一块地方，我无法自动决定保留哪个，需要你来判断。冲突是信息，不是故障。
处理冲突的标准流程是：先git status看哪些文件冲突了，然后打开这些文件，找到<<<<<<<、=======、>>>>>>>标记的区域，手动决定保留哪部分内容，删掉标记，保存文件，然后git add标记为已解决，最后git commit完成合并。
但这里有个容易被忽略的细节：冲突标记里的HEAD和分支名，代表的是两个不同来源的改动。<<<<<<< HEAD下面的内容是当前分支的改动，>>>>>>> dev上面的内容是dev分支的改动。搞清楚这一点，你就能有依据地做决定，而不是凭感觉乱删。
我处理冲突时有个习惯：先不急着改，先把冲突文件复制一份到临时目录。这样万一改错了，还能对照原始版本重新来。另外，如果冲突文件很多，我会用git mergetool打开可视化工具，比手动改效率高得多。常用的工具有meld、kdiff3、Beyond Compare，配置好之后git mergetool会自动调用。
4. 从“单机”到“协作”：远端仓库的工作流设计
Git是分布式的，这意味着你可以完全在本地工作，不需要任何服务器。但绝大多数项目都需要协作，这就需要引入“远端仓库”的概念。远端仓库本质上就是一个大家都能访问的裸仓库，它没有工作区，只存commit和对象，充当“交换中心”的角色。
4.1 裸仓库与非裸仓库的区别
git init默认创建的是“非裸仓库”，它有一个工作区，你可以在里面直接编辑文件。而git init --bare创建的是“裸仓库”，它没有工作区，只存Git对象和引用。远端仓库通常用裸仓库，因为没人会直接在服务器上编辑文件，工作区是多余的。
这个区别看起来很小，但影响很大。如果你不小心把一个非裸仓库当成远端仓库推送，Git会拒绝，因为推送的目标分支不能是当前检出的分支。这是Git的一种保护机制，防止你推送到一个正在被编辑的工作区，导致状态混乱。
4.2 推送与拉取：同步的两种方向
git push是把本地commit上传到远端，git pull是把远端commit下载到本地。但git pull其实是两个操作的组合：git fetch+git merge。git fetch只下载远端的最新commit，不修改你的工作区；git merge则把这些commit合并到当前分支。
我强烈建议新手先用git fetch再手动git merge，而不是直接git pull。原因很简单：git pull会自动合并，如果出现冲突，你会在毫无准备的情况下被扔进冲突处理流程。而git fetch之后，你可以先git log HEAD..origin/main看看远端有哪些新commit，心里有数了再决定怎么合并。
另外，git pull --rebase是另一种常见的拉取方式。它不生成合并commit，而是把你的本地commit“垫”到远端commit之上，保持历史是一条直线。这个方式适合本地有未推送的commit、远端也有新commit的场景。但同样要注意：如果本地commit已经推送过，就不要用rebase。
4.3 分支策略：从“能用”到“好用”
小团队协作，最简单的策略是“main分支 + 功能分支”：main分支始终保持可发布状态，每个功能开一个分支，做完后合并回main。这个策略足够应付大多数场景，但有个问题：如果功能分支开发周期长，合并时冲突会很多。
稍微复杂一点的策略是“develop分支 + main分支”：develop分支是集成分支，功能分支先合并到develop，测试通过后再合并到main。这样main分支始终稳定，develop分支可以承受一定的混乱。这个策略适合有明确发布周期的项目。
再复杂的就是“Git Flow”那一套：main、develop、feature、release、hotfix五种分支，各有明确的职责。这套流程很完整，但对小团队来说太重了。我见过不少团队一开始照搬Git Flow，结果被各种分支的合并方向搞晕，最后又退回简单策略。
我的建议是：从最简单的策略开始，遇到痛点再升级。如果“main + 功能分支”够用，就别引入develop。如果合并冲突频繁，再考虑加一个集成分支。工具是为人服务的，不是反过来。
5. 那些年我踩过的Git坑：从“误删分支”到“提交错文件”
Git的命令行界面不算友好，错误提示也经常让人摸不着头脑。但大部分“坑”其实都有规律可循，理解了背后的原理，就能快速定位和修复。
5.1 提交了不该提交的文件
这是最常见的坑：不小心把密码文件、编译产物、大体积二进制文件提交进去了。如果还没推送，可以用git reset HEAD~1撤销最后一次commit，然后重新提交。如果已经推送了，就得用git revert新建一个反向commit，或者用git filter-branch重写历史（慎用，会改写所有commit的哈希值）。
预防这个坑的最好办法是在项目根目录放一个.gitignore文件，把不该提交的文件模式写进去。比如*.log、node_modules/、.env、dist/。但要注意，.gitignore只对未跟踪的文件生效，如果文件已经被提交过，得先用git rm --cached把它从暂存区移除，再提交一次。
我见过有人把数据库密码写进代码里提交了，发现后慌得不行。其实如果只是本地仓库，git reset就能解决；如果已经推送到远端，除了git revert，还得立刻修改密码，因为历史记录里已经有了，谁知道有没有人拉取过。
5.2 分支删错了，commit找不回来
git branch -D会强制删除分支，如果这个分支的commit没有被合并到其他分支，这些commit就会变成“悬空对象”，最终被Git的垃圾回收机制清理掉。但别慌，只要引用日志还在，你就能找回来。
操作步骤是：先git reflog找到被删除分支最后一次commit的哈希值，然后git checkout -b 分支名 哈希值，分支就恢复了。如果引用日志里也找不到，还可以用git fsck --lost-found扫描悬空对象，但成功率取决于垃圾回收有没有跑过。
这个坑教会我一件事：删除分支之前，先确认它的commit有没有被合并。用git branch --merged列出已经合并的分支，这些可以放心删；git branch --no-merged列出未合并的，删之前要三思。
5.3 合并冲突处理到一半，想放弃
合并冲突处理到一半，发现改动太复杂，想回到合并前的状态。这时候不能直接git reset --hard，因为合并操作已经修改了工作区，硬重置会丢失所有未提交的改动。正确的做法是git merge --abort，它会尝试恢复到合并前的状态。
但git merge --abort不是万能的。如果合并过程中有未跟踪的文件被覆盖，或者有本地修改与合并冲突，它可能无法完全恢复。所以在执行合并之前，先确保工作区是干净的——要么提交，要么暂存，要么丢弃。这是避免麻烦的最好办法。
5.4 推送被拒绝：远端有新commit
git push被拒绝，提示“远端包含本地没有的commit”。这说明有人在你之前推送了新的commit，你需要先拉取再推送。这时候如果直接git pull，可能会产生一个合并commit；如果git pull --rebase，则会把你的commit垫到远端commit之上。
选择哪种方式取决于你的commit有没有推送过。如果没推送过，用rebase保持历史整洁；如果推送过，用merge避免改写历史。但不管哪种方式，推送之前先拉取应该成为肌肉记忆。我现在的习惯是：git fetch→git log HEAD..origin/main→ 确认远端改动 →git rebase或git merge→git push。
5.5 大文件拖慢仓库速度
Git不适合存大文件，因为每次修改都会存一份完整的内容，而不是差异。一个几百MB的二进制文件，改几次之后仓库体积就会爆炸。如果已经提交了大文件，可以用git filter-branch或BFG工具清理历史，但操作复杂且有风险。
预防的办法是：在项目初期就配置好.gitignore，把大文件、编译产物、依赖包排除在外。如果确实需要版本管理大文件，可以考虑Git LFS，它把大文件存在单独的地方，仓库里只保留指针。但Git LFS需要额外配置，不是所有远端仓库都支持。
6. 从“会用”到“用得好”：几个提升效率的实战技巧
Git的命令有几百个，但日常高频使用的也就二十来个。掌握这些核心命令的组合用法，比死记硬背所有参数有用得多。
6.1 用别名简化高频命令
Git允许你给命令起别名，把常用的长命令缩短。比如：
git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg "log --oneline --graph --all"配置好之后，git st就是git status，git lg就是带图形化历史的日志。这些别名会写进全局配置文件，所有仓库通用。我自己的配置里还有git unstage（取消暂存）、git last（查看最后一次commit）等，用习惯了之后效率提升很明显。
6.2 用交互式暂存精确控制提交内容
git add -p是很多人不知道但极其好用的命令。它让你逐个代码块地选择要暂存的改动，而不是整个文件一起暂存。比如你改了一个文件，其中一部分是修复bug，另一部分是新增功能，你可以用git add -p只暂存bug修复的部分，先提交这个，再暂存功能部分，提交另一个commit。
这个命令的交互界面会逐个展示代码块，问你Stage this hunk [y,n,q,a,d,s,e,?]?。常用的选项有：y暂存这个块，n跳过这个块，s把这个块拆成更小的块，e手动编辑要暂存的内容。刚开始可能觉得麻烦，但用几次之后就会发现，它能让你的commit历史清晰十倍。
6.3 用stash临时保存工作区
正在开发一个功能，突然需要切换到另一个分支修bug，但当前工作区有未提交的改动。这时候git stash就是救星：它把当前工作区和暂存区的改动“藏”起来，让工作区回到干净状态。修完bug后，git stash pop把藏起来的改动恢复回来。
git stash可以多次使用，每次藏起来的改动会形成一个栈。git stash list查看所有藏起来的记录，git stash apply stash@{2}恢复指定的记录。但要注意：stash不会保存未跟踪的文件，如果有新创建的文件没被跟踪，得先用git add加进去，或者用git stash -u把未跟踪文件也藏起来。
6.4 用bisect定位引入bug的commit
如果发现某个功能在某个版本之后坏了，但不知道是哪个commit引入的，git bisect可以帮你快速定位。它的原理是二分查找：你告诉它一个“好”的commit和一个“坏”的commit，它会自动检出中间的commit，让你测试，然后根据结果缩小范围，直到找到第一个“坏”的commit。
操作流程是：git bisect start→git bisect bad（标记当前为坏）→git bisect good 某个好commit的哈希→ Git自动检出中间commit → 你测试后告诉它git bisect good或git bisect bad→ 重复直到定位到问题commit →git bisect reset结束。
这个命令在大型项目里特别有用，因为手动翻commit历史可能要看几百个提交，而bisect只需要log2(N)次测试。比如1000个commit，只需要10次左右就能定位到。
6.5 用worktree同时检出多个分支
git worktree允许你在同一个仓库里同时检出多个分支到不同的目录。比如你正在main分支上工作，突然需要切到dev分支改个东西，但又不想打断当前的工作。用git worktree add ../dev-work dev，Git会在../dev-work目录下检出dev分支，你可以在那个目录里操作，当前目录不受影响。
这个功能在需要同时对比两个分支的代码、或者需要在不同分支上跑测试时特别有用。但要注意：同一个分支不能在多个worktree里同时检出，这是Git的限制，防止两个工作区互相干扰。
7. 理解Git的“性格”：为什么它的命令设计成这样
Git的命令行界面经常被吐槽“反人类”，但如果你理解了它的设计哲学，很多看似奇怪的命令就变得合理了。
7.1 一切皆本地
Git的所有操作默认都在本地完成，commit、branch、log、diff都不需要联网。只有push、fetch、pull才涉及远端。这个设计让Git的速度极快，也让你在飞机上、地铁里都能正常提交代码。
但这也意味着本地和远端是两套独立的状态。你本地提交了，不代表远端就有了；远端有了新commit，不代表你本地会自动同步。理解这一点，就能明白为什么git status有时候会说“你的分支比origin/main领先3个commit”——它是在告诉你，本地和远端不同步。
7.2 暂存区的“中间态”
暂存区是Git最独特的设计之一。它介于工作区和仓库之间，让你能精确控制每次提交的内容。很多人觉得这个设计多余，但正是它让Git能支持“部分提交”“交互式暂存”“冲突解决”这些高级操作。
你可以把暂存区理解成一个购物车：工作区是货架，你从货架上挑东西放进购物车（git add），确认购物车里的东西没问题了，再结账（git commit）。这个比喻虽然不完美，但能帮你理解为什么改完文件还要git add——因为Git不想替你决定哪些改动该提交。
7.3 内容寻址的“不可变性”
Git用内容的哈希值作为对象的ID，这意味着同样的内容永远得到同样的ID，内容变了ID就变了。这个设计让Git的对象天然具有“不可变性”——你不能修改一个已经存在的commit，只能新建一个commit来替代它。
这个特性带来的好处是：数据完整性极高。如果存储过程中有任何一个字节损坏，哈希值就对不上，Git会立刻发现。但代价是：改写历史很麻烦，因为所有后续commit的哈希值都会变。所以Git不鼓励改写已推送的历史，rebase、commit --amend这些操作都要谨慎使用。
7.4 分支的“轻量级”
Git的分支只是一个指针，创建和切换的成本极低。这个设计鼓励开发者频繁使用分支，每个功能、每个bug修复都开一个独立分支。相比之下，集中式工具的分支是“重量级”的，创建分支要复制整个目录，导致开发者倾向于少开分支。
这个差异直接影响了工作流。在Git里，正确的做法是“分支即上下文”——你切换到哪个分支，就进入哪个上下文，做完就合并、删除。分支不是长期存在的东西，而是临时的工作空间。
8. 从“个人工具”到“团队基础设施”：Git在协作中的角色
Git本身只是一个工具，但围绕它形成的协作模式，已经成为现代软件开发的基础设施。理解这些模式，比单纯掌握命令更重要。
8.1 代码审查：合并请求的价值
合并请求（或者叫拉取请求）是Git协作的核心机制。它的价值不在于“合并”这个动作，而在于合并之前的审查。通过合并请求，团队成员可以查看改动的diff、发表评论、提出修改建议，确保代码质量。
一个好的合并请求应该小而聚焦：只解决一个问题，改动量控制在几百行以内。太大的合并请求没人愿意仔细看，审查就流于形式。我见过一个团队规定“合并请求超过500行必须拆分”，刚开始大家觉得麻烦，后来发现代码质量明显提升，因为小改动更容易发现问题和遗漏。
8.2 持续集成：每次提交都验证
Git的分布式特性让“频繁提交”成为可能，而持续集成（CI）则让“每次提交都验证”成为现实。每次推送commit到远端，CI系统自动拉取代码、运行测试、构建产物，如果有问题立刻通知开发者。
这个机制的价值在于快速反馈。如果测试失败，开发者能在几分钟内知道，而不是等到发布前才发现。但前提是测试要快——如果CI跑一次要半小时，开发者就会倾向于攒一批commit再推送，快速反馈的优势就没了。
8.3 版本发布：标签与语义化版本
Git的标签（tag）是用来标记发布版本的。和分支不同，标签是一个不可变的指针，一旦创建就不会移动。发布版本时，用git tag -a v1.0.0 -m "发布说明"创建一个带注释的标签，然后git push origin v1.0.0推送到远端。
标签的命名建议遵循语义化版本规范：主版本号.次版本号.修订号。主版本号变了表示有不兼容的改动，次版本号变了表示新增了向后兼容的功能，修订号变了表示修复了向后兼容的bug。这个规范让使用者能快速判断一个版本升级的风险。
8.4 保护分支：防止误操作的最后一道防线
远端仓库通常支持“保护分支”功能，比如禁止直接推送到main分支，必须通过合并请求；禁止强制推送，防止改写历史；要求状态检查通过才能合并，确保CI通过。
这些规则看起来是限制，实际上是保护。我见过一个团队因为没设保护分支，有人在main上执行了git push --force，把其他人的commit全冲掉了。虽然最后用引用日志找回来了，但浪费了半天时间。从那以后，他们把所有长期分支都设了保护规则。
9. 学Git的正确姿势：从“背命令”到“建模型”
最后聊聊学习方法。很多人学Git的方式是“背命令”：遇到问题搜一下，找到命令复制粘贴，能用就行。这种方式在简单场景下没问题，但一旦遇到复杂情况，就会手足无措。
更有效的方式是建立心智模型：理解Git的对象模型（blob、tree、commit）、引用模型（分支、标签、HEAD）、以及操作模型（工作区、暂存区、仓库）。有了这些模型，你就能推导出该用什么命令，而不是搜索该用什么命令。
比如，你知道git reset的本质是“移动HEAD和分支指针”，那么--soft、--mixed、--hard的区别就很好理解了：--soft只移动指针，--mixed移动指针并重置暂存区，--hard移动指针并重置暂存区和工作区。不需要死记硬背，理解原理就能推导出来。
另一个建议是多用git status和git log。这两个命令是你的“仪表盘”，告诉你当前处于什么状态、历史是什么样的。遇到不确定的情况，先跑一遍git status，看看Git建议你做什么。它的提示通常很准确，只是很多人不看。
还有，不要怕犯错。Git的容错机制比你想象的强大：引用日志能找回误删的commit，git reflog能恢复误重置的分支，git fsck能扫描悬空对象。只要你不执行git gc --prune=now这种强制清理，大部分误操作都能挽回。我踩过的坑比大多数人吃过的盐还多，但正是这些坑让我真正理解了Git。
提示：如果你刚开始学Git，建议在本地建一个练习仓库，随便折腾。创建一个文件、提交、改分支、合并、制造冲突、解决冲突、回滚、找回。把每个命令都试一遍，看看
git log和git status的输出有什么变化。这种“破坏性学习”比看十篇教程都管用。
Git的“传奇身世”其实是一个关于解决问题的故事：为了解决分布式协作的问题，设计了一套分布式的版本控制系统；为了让提交更精确，引入了暂存区；为了让分支更轻量，用指针代替复制。每一个设计决策背后，都有具体的场景和权衡。理解这些，你就不只是在学一个工具，而是在学一种思考方式。
