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分支指向最新的commitdev分支指向另一个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 fetchgit 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 推送被拒绝远端有新commitgit 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 statusgit 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 devGit会在../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的容错机制比你想象的强大引用日志能找回误删的commitgit reflog能恢复误重置的分支git fsck能扫描悬空对象。只要你不执行git gc --prunenow这种强制清理大部分误操作都能挽回。我踩过的坑比大多数人吃过的盐还多但正是这些坑让我真正理解了Git。提示如果你刚开始学Git建议在本地建一个练习仓库随便折腾。创建一个文件、提交、改分支、合并、制造冲突、解决冲突、回滚、找回。把每个命令都试一遍看看git log和git status的输出有什么变化。这种“破坏性学习”比看十篇教程都管用。Git的“传奇身世”其实是一个关于解决问题的故事为了解决分布式协作的问题设计了一套分布式的版本控制系统为了让提交更精确引入了暂存区为了让分支更轻量用指针代替复制。每一个设计决策背后都有具体的场景和权衡。理解这些你就不只是在学一个工具而是在学一种思考方式。
