最近半年有好几个朋友问我同一个问题Git 怎么学最快说实话问这个问题的多半是被命令行吓到了要么就是被网上那种讲原理讲到云里雾里的教程劝退了。我自己带新人、带实习生、跟同事协作见过太多人卡在 Git 上。其实 Git 真不难难的是很多人一开始就把精力放错了地方去背一堆基本用不上的命令还搞不清每个命令到底在干嘛。这篇就按我的经验来写一个速成路线。不是给你罗列一百个命令而是只讲日常开发里真正高频要用到的那十几条配着真实场景讲清楚它们到底解决了什么问题顺便把我这几年踩过的坑也放进去。目标是让一个完全没接触过 Git 的人看完之后能正常上手开发日常操作不再慌。1. 理解 Git 的三件事它到底在解决什么问题1.1 版本管理的核心痛点在接触 Git 之前得先搞明白一个问题我们为什么要用版本控制工具我见过最经典的原始操作是拿文件夹来管理版本一个项目下放十几个文件夹命令分别是“项目最终版”“项目最终版2”“项目真最终版”“项目打死不改版”。这种搞法最大的问题不是乱是心里没底。你永远不知道当前这份代码相比昨天那份改了什么某段代码什么时候被加进来的改坏了一个文件之后能不能退回去。Git 干的事情本质上就是给整个项目的每一次变动拍快照并且把这些快照串成一条时间线。你改文件、加文件、删文件Git 全都能感知到只要你主动提交一次当时的整个项目状态就被永久记录下来。以后任何时候你都可以回到任意一个快照或者对比任意两个快照之间的差异。“后悔药”这件事是 Git 带给开发者最大的安全感。这种安全感任何不依赖版本控制工具的协作方式都给不了。1.2 工作区、暂存区、仓库三个概念必须一次搞懂很多教程喜欢一上来就画一大堆图来解释内部机制说实话没什么必要。你只需要掌握三个区域就行工作区、暂存区、仓库。这三个词理解了Git 至少懂了一半。工作区就是你现在电脑上能看到的项目文件夹你正常写代码改代码的地方。暂存区你可以理解成一个中转站用来把你准备好要提交的改动先收集起来。仓库则是 Git 真正保存历史快照的地方一般藏在项目文件夹下的隐藏目录里。日常操作对应的关系就是在工作区改代码把想要提交的改动用 add 放进暂存区最后用 commit 把这些改动打包成一个快照存进仓库。很多人刚开始搞不懂为什么要这么绕一下不能直接提交吗其实这个设计很有用。它让你可以控制“一次提交里面包含什么”。比如你同时改了两个文件一个是修 bug 的另一个是加新功能的如果直接提交就把它们混在同一个历史记录里了。用暂存区先只加第一个文件提交一次再加第二个文件提交一次这样以后查历史的时候每次提交是干嘛的一目了然。提示刚上手不要急着背那些深入原理的命令先把 add、commit 这两个操作练到形成肌肉记忆后面所有操作都会顺很多。2. 从零跑通第一个完整流程从安装到推送2.1 环境准备与全局配置先把 Git 装上。Windows、macOS、Linux 都有对应的安装包各平台安装方式就不展开细说了照着官网操作就行。装完之后打开命令行输入git --version如果能看到版本号说明装好了。接下来要做的是全局配置。这一步很多人容易跳过但它非常关键。Git 每次提交的时候都要记录作者信息如果没配置提交时就可能报错或者把身份信息用错误的方式写进提交记录。执行下面两行把用户名和邮箱换成你自己的git config --global user.name 你的名字 git config --global user.email 你的邮箱这个配置是全局生效的也就是说不管你电脑上建了多少个项目默认都用这套身份来提交。如果要针对某个项目单独用另一套身份可以去掉 --global 参数在那个项目目录里重新执行一次。还有些人喜欢给命令行加颜色方便看状态和差异执行下面这个命令可以打开彩色输出git config --global color.ui true配置完成后可以用 git config --list 查看当前的配置项确认没有遗漏。2.2 初始化、提交、推送一条路走通现在假设我手上有一个全新的项目文件夹里面放了几个代码文件还没有任何版本管理。进入这个文件夹后执行初始化命令git init这个命令执行完之后项目目录里会多出一个隐藏的 .git 目录这就是你的本地仓库。Git 从这一刻开始能感知到这个目录下所有文件的变动。接下来往里面放一个新文件比如 index.html然后正常操作流程是先查看当前状态再添加文件到暂存区最后提交。git status git add index.html git commit -m 初始化项目添加首页文件git status 是用来查看当前工作区状态的它会告诉你哪些文件有改动、哪些改动还没进暂存区、当前在哪个分支上。我几乎每做一步操作都会敲一下 git status这算是个很好的习惯。git add 是把文件放进暂存区。如果想把所有改动的文件都加进去可以执行 git add .但要小心这会把当前目录下所有未忽略的改动全部加入暂存区。新手阶段建议逐个添加至少得知道自己在提交什么。git commit 正式创建快照。-m 后面的内容是这次的提交说明用来描述这次改动做了什么。提交完成之后这次快照就永久存在本地仓库里了。如果项目是托管在某个代码托管平台上的给仓库加一个远程地址然后把本地仓库推上去git remote add origin https://xx.com/your/repo.git git push -u origin main这里第一个命令把远程仓库地址绑定到本地的 origin 这个名字上。第二个命令把当前分支推送到远程的 main 分支-u 是建立本地分支和远程分支的关联以后再执行 git push 就不再需要指定远程和分支名了。2.3 提交信息怎么写才不遭同事白眼提交信息这件事很多人不重视但它直接影响协作效率。你在团队里拿到一份代码git log 打开一看提交信息全是“update”“修改”“aaa”这种你会是什么感受根本没法知道哪次提交对应哪个需求、哪个 bug 修复。规范一点的写法是用一个简短的类型前缀加描述。比如fix: 修复登录接口在空密码时返回 500 的问题 feat: 新增用户头像上传功能 docs: 更新 README 部署说明 refactor: 重构订单状态判断逻辑fix 和 feat 是最常见的两种分别表示修复和功能新增。这样的提交信息将来回查历史、出 changelog、定位问题都会省非常多的力气。个人经验是提交信息一句话能写清楚就绝不废话超过一行的说明放到正文里用空行隔开。3. 分支和合并团队协作的命脉3.1 分支到底是什么为什么要分支初学 Git 的人看到 git branch 这个命令往往不太理解分支的意义。简单说分支是从主线上分出来的一个独立工作空间。你在分支上做任何改动、提交都不会影响主线和其他同事的工作。这就是分支的核心价值隔离。我见过一个很形象的比喻主分支是主干道分支是施工现场旁边的临时绕行路线。你修路开发功能的时候不能把主干道堵死于是先绕行绕行路线修好了再接回去。Git 里的分支就是这个绕行路线。大家各自在分支上开发互不打扰开发完成经过审核确认没问题再合并回主分支。单人开发时分支的威力还不明显顶多是给自己一个安全的开发环境。到了多人协作分支基本是唯一的协作方式了。每个人从主分支拉一个自己的分支改完再合回去没有分支的话几个人同时改同一份代码冲突场面会非常混乱。3.2 合并与冲突处理创建一个新分支并切换过去最常用的命令是git checkout -b feature/login这个命令相当于做了两件事创建名为 feature/login 的分支并切到这个分支上。它等价于 git branch feature/login 然后 git checkout feature/login。在新分支上做了一些提交确认功能完成之后切回主分支把新分支合并进来git checkout main git merge feature/loginmerge 操作会把 feature/login 分支上的所有提交合并到 main 分支上。如果两个分支都改了同一个文件的同一处地方合并时就会产生冲突。冲突的表现形式是 Git 会把冲突区域的代码以特殊标记写进文件让你手动选择保留哪部分。处理冲突说起来很简单打开冲突文件找到冲突标记保留正确的代码删掉标记符然后重新 add、commit。但实际操作中冲突往往不那么好处理。我的建议是第一别慌冲突不是坏事说明 Git 很诚实地告诉你“这个合并我不能自己做决定”第二看不懂的冲突内容先把同事叫过来一起看宁可多沟通也别凭感觉删代码第三冲突标记内 、、 这三行标记在解决完冲突后一定要清理干净漏掉任何一个代码编译可能过不去。3.3 Pull Request 到底在做什么现在很多团队是在代码托管平台上做代码评审流程一般是开发者在分支上提交完代码之后发起一个 Pull Request简称 PR请求把分支合并进主分支。在 PR 里可以看到这次改了哪些文件、每个文件具体改了什么团队成员可以在这里讨论、提意见确认没问题后由有权限的人点击合并。对新手来说PR 是一个学习的好机会。你得学会看懂一次 PR 里的 diff文件差异对比搞清楚自己到底改了什么也得学会回应别人提的意见。我自己带过的人里有刚入职的小朋友第一次开 PR把几百行代码全塞进一个提交里评审人根本没法看。后来我给他的建议是拆提交。一个大功能分成几个逻辑完整的提交每个提交解决一个点这样评审人有顺序地看效率高很多。4. 撤销与回滚做错了怎么修4.1 五种后悔场景对照写代码最怕的不是出错是出错后不知道怎么办。我整理了几个最常见的“后悔场景”以及对应的解决办法。场景一改了工作区的文件还没 add想放弃修改。用 git checkout -- 文件名比如 git checkout -- index.html这个文件就会恢复到最近一次提交时的状态。场景二已经把文件 add 进暂存区了想把它从暂存区拿出来。用 git reset HEAD 文件名注意这个操作不会动工作区文件只是取消暂存。场景三已经 commit 了但是提交信息写错了。用 git commit --amend它会打开编辑器让你重新编辑上次提交的说明保存后上一条提交信息就被替换了。注意这个命令只适合还没有推送的提交如果已经推送了改动下次提交信息会导致远端历史不一致需要强制推送才能更新团队协作时尽量别这么干。场景四commit 之后发现漏了一个文件没提交想补进同一次提交。可以执行 git add 漏掉的文件然后再执行 git commit --amend这样漏掉的文件就补进上一条提交里了不用多出一条“补充提交”来污染历史。场景五已经 commit 了但发现代码有严重问题想把整个提交撤销。这就涉及下面要重点讲的两个命令git reset 和 git revert。4.2 reset、revert、checkout 三条命令的区别这三个命令初学者很容易搞混。我用最直白的方式说git checkout 用来解决“工作区或者暂存区层面的反悔”不影响提交历史。git reset 用来“回退提交历史”它是把 HEAD 指针以及分支指针移动到指定的提交上可以让你的分支状态“假装”某次提交之后什么都没发生过。git revert 则相反它不是移动指针而是创建一个“反向提交”把之前某次提交的改动反向执行一遍生成一个新的提交记录。什么场景选哪个如果你在自己本地的分支上提交之后发现全错了想干脆忘掉这次提交那就用 reset。如果你推送到了远程和大家共享了这个分支想撤销某次改动那就用 revert。原因很简单reset 会重写历史一旦推过远程别人的本地仓库里还留着旧历史两边就对不上了revert 不重写历史只是增加一条新提交所有人 pull 之后自然就同步了。reset 有三个模式软soft、混合mixed、硬hard新手记太多容易晕。我只说最实用的一条如果确定不需要回退点之后的代码了直接 git reset --hard 提交号如果只是想移动 HEAD 指针、保留工作区改动用 git reset --soft 提交号。日常用得最多的是 --hard但在执行之前务必确认自己真的不需要这些改动了因为这命令一敲那些改动就彻底没了。4.3 误删分支的恢复分支删了能恢复吗能。git 的分支本质上是一个指向某个提交的引用删分支只是删了引用提交本身在仓库里还在只要你记得那个分支最后指向的提交号就能再拉回来。假定我误删了 feature/login 分支先在 git reflog 里找回提交号git reflogreflog 是 Git 的“操作日志”记录了你所有本地操作中 HEAD 指针的移动情况。在 reflog 输出里找到删分支之前 HEAD 指向的那个提交号然后重新创建分支指回去git branch feature/login 目标提交号这样分支就回来了。我做过好多次这种救援操作成功率非常高。但有个前提reflog 里的记录有过期时间默认 90 天超期就找不回来了。所以分支这种东西别乱删删之前想清楚。5. 高频翻车现场与排障手册5.1 提交错文件、误包含敏感信息怎么办先说误提交的修复。如果只是多提交了一个文件而且还没有推送最优雅的处理方式是用 git reset --soft 回退到上一个提交让所有提交过的改动回到暂存区然后把不该提交的文件从暂存区移除重新提交一次。git reset --soft HEAD~1 git reset HEAD 不该提交的文件 git commit -m 正确的提交说明如果已经推送到了远端情况就比较麻烦。尤其是在公开仓库里提交了敏感信息比如数据库密码、密钥之类的哪怕是马上删掉再推送历史记录里依然留着这些信息。这种时候正确的做法是马上重置密钥密码不只是删代码。因为历史记录里的敏感信息可能已经被别人看到了。然后修改该文件中的敏感内容用新内容重新提交推送。至于清历史记录里的敏感信息可以借助工具重写历史但这是个进阶操作团队协作中强制推送会影响到其他人需要提前沟通好。注意任何情况下密钥、口令这类东西都不应该提交进 Git 仓库。正确的做法是用环境变量或者专门的密钥管理服务代码里只引用变量的名字。5.2 push 被拒的两种情况新手最常见的 push 失败场景有两种。第一种远程分支存在你没有的提交。比如同事已经推过代码了而你的本地还停留在旧状态此时执行 git push 会被拒绝因为远端不接受“会覆盖别人提交”的推送。解决办法很简单git pullpull 会把远程新的提交拉下来合并进你的本地分支。如果合并过程产生了冲突就按前面说的方法解决冲突然后重新 push。如果想保持提交历史干净整洁可以用 git pull --rebase它的效果是把你本地的提交“搬到”远程提交的后面而不是生成一次多余的合并提交。第二种本地当前分支没有设置远程追踪分支。执行 git push 时如果提示 “fatal: The current branch has no upstream branch”说明本地分支和远程分支还没有建立关联。按提示执行git push --set-upstream origin 分支名关联一次之后后续再 push 就什么都不用带直接 git push 就行。5.3 .gitignore 不生效的问题很多新手配置 .gitignore 文件之后发现某些文件还在被 git status 跟踪着就会很困惑。原因是.gitignore 只作用于“尚未被跟踪”的文件。如果一个文件已经被 Git 跟踪了也就是已经被 add 或者 commit 过了再写进 .gitignore 是不生效的。解决办法是先把这些文件从跟踪状态移除git rm -r --cached 文件或目录--cached 表示只移除暂存区/仓库里的跟踪记录保留工作区的文件。执行完加上注释说明然后 git add .gitignore git commit把这些文件的跟踪状态更新一下之后 .gitignore 就正常生效了。另外还有一个常见错误就是 .gitignore 里的路径写错。比如忽略 build 目录应该写 /build 或者 build/不要写 build二者的匹配范围完全不一样。这些细节踩过一次就很记住了。5.4 其他零碎但实用的高频细节最后分享几个日常 Git 使用中很容易被忽略、但实际非常提效的小操作。git log --oneline --graph把提交历史压缩成一行一条同时画出分支合并的图形一眼就能看出整个仓库的分支走向和提交脉络。git stash正在某个分支上改到一半突然需要切到另一个分支处理紧急事但改动还没完成不想提交。这时执行 git stash所有未提交的改动会被暂时存放起来工作区变干净可以放心切分支。处理完紧急事件切回来后执行 git stash pop 把改动恢复进度一分不少。git diff提交之前先看一眼具体改了哪些内容比 git status 的信息详细得多。git status 只看文件名git diff 能看到具体每一行。养成“先 diff 再 commit”的习惯可以帮自己过滤掉不少误改动。grep 命令同样可以用在 Git 相关的搜索里。比如想查某行代码是哪个提交引入的用 git log -S 关键词 可以搜索历史提交中某段字符串的变更记录。这个命令在排查问题时特别好用定位哪次提交改坏了什么比人肉翻代码高效太多。我个人实际操作中的体会是Git 的学习曲线其实很平缓最难的部分往往不是命令记不住而是命令背后的心智模型没建立好。刚开始就不要着急着去搞那些花哨的 rebase 交互式操作把 add、commit、push、pull、branch、merge、checkout 这几条最核心的命令练熟配合 git status 和 git log 随时确认状态日常开发已经完全够用。后面遇到更复杂的场景比如需要整理提交历史、跨分支挑拣改动那时候再针对性查资料学反而是最快的路径。另外也建议你从第一个项目开始就坚持用 Git 管理哪怕只是自己一个人写的练习项目。没有真实项目的压力命令敲再多也容易转头就忘只要自己真正在项目里走完几轮“改动—提交—推拉—合并—解决冲突”的循环这种感觉是看多少教程都替代不了的。 
长河君 · 2026/10/20 15:47:00 · 阅读 1.2k Git 速成路线：从核心概念到高频命令实战
最近半年有好几个朋友问我同一个问题Git 怎么学最快说实话问这个问题的多半是被命令行吓到了要么就是被网上那种讲原理讲到云里雾里的教程劝退了。我自己带新人、带实习生、跟同事协作见过太多人卡在 Git 上。其实 Git 真不难难的是很多人一开始就把精力放错了地方去背一堆基本用不上的命令还搞不清每个命令到底在干嘛。这篇就按我的经验来写一个速成路线。不是给你罗列一百个命令而是只讲日常开发里真正高频要用到的那十几条配着真实场景讲清楚它们到底解决了什么问题顺便把我这几年踩过的坑也放进去。目标是让一个完全没接触过 Git 的人看完之后能正常上手开发日常操作不再慌。1. 理解 Git 的三件事它到底在解决什么问题1.1 版本管理的核心痛点在接触 Git 之前得先搞明白一个问题我们为什么要用版本控制工具我见过最经典的原始操作是拿文件夹来管理版本一个项目下放十几个文件夹命令分别是“项目最终版”“项目最终版2”“项目真最终版”“项目打死不改版”。这种搞法最大的问题不是乱是心里没底。你永远不知道当前这份代码相比昨天那份改了什么某段代码什么时候被加进来的改坏了一个文件之后能不能退回去。Git 干的事情本质上就是给整个项目的每一次变动拍快照并且把这些快照串成一条时间线。你改文件、加文件、删文件Git 全都能感知到只要你主动提交一次当时的整个项目状态就被永久记录下来。以后任何时候你都可以回到任意一个快照或者对比任意两个快照之间的差异。“后悔药”这件事是 Git 带给开发者最大的安全感。这种安全感任何不依赖版本控制工具的协作方式都给不了。1.2 工作区、暂存区、仓库三个概念必须一次搞懂很多教程喜欢一上来就画一大堆图来解释内部机制说实话没什么必要。你只需要掌握三个区域就行工作区、暂存区、仓库。这三个词理解了Git 至少懂了一半。工作区就是你现在电脑上能看到的项目文件夹你正常写代码改代码的地方。暂存区你可以理解成一个中转站用来把你准备好要提交的改动先收集起来。仓库则是 Git 真正保存历史快照的地方一般藏在项目文件夹下的隐藏目录里。日常操作对应的关系就是在工作区改代码把想要提交的改动用 add 放进暂存区最后用 commit 把这些改动打包成一个快照存进仓库。很多人刚开始搞不懂为什么要这么绕一下不能直接提交吗其实这个设计很有用。它让你可以控制“一次提交里面包含什么”。比如你同时改了两个文件一个是修 bug 的另一个是加新功能的如果直接提交就把它们混在同一个历史记录里了。用暂存区先只加第一个文件提交一次再加第二个文件提交一次这样以后查历史的时候每次提交是干嘛的一目了然。提示刚上手不要急着背那些深入原理的命令先把 add、commit 这两个操作练到形成肌肉记忆后面所有操作都会顺很多。2. 从零跑通第一个完整流程从安装到推送2.1 环境准备与全局配置先把 Git 装上。Windows、macOS、Linux 都有对应的安装包各平台安装方式就不展开细说了照着官网操作就行。装完之后打开命令行输入git --version如果能看到版本号说明装好了。接下来要做的是全局配置。这一步很多人容易跳过但它非常关键。Git 每次提交的时候都要记录作者信息如果没配置提交时就可能报错或者把身份信息用错误的方式写进提交记录。执行下面两行把用户名和邮箱换成你自己的git config --global user.name 你的名字 git config --global user.email 你的邮箱这个配置是全局生效的也就是说不管你电脑上建了多少个项目默认都用这套身份来提交。如果要针对某个项目单独用另一套身份可以去掉 --global 参数在那个项目目录里重新执行一次。还有些人喜欢给命令行加颜色方便看状态和差异执行下面这个命令可以打开彩色输出git config --global color.ui true配置完成后可以用 git config --list 查看当前的配置项确认没有遗漏。2.2 初始化、提交、推送一条路走通现在假设我手上有一个全新的项目文件夹里面放了几个代码文件还没有任何版本管理。进入这个文件夹后执行初始化命令git init这个命令执行完之后项目目录里会多出一个隐藏的 .git 目录这就是你的本地仓库。Git 从这一刻开始能感知到这个目录下所有文件的变动。接下来往里面放一个新文件比如 index.html然后正常操作流程是先查看当前状态再添加文件到暂存区最后提交。git status git add index.html git commit -m 初始化项目添加首页文件git status 是用来查看当前工作区状态的它会告诉你哪些文件有改动、哪些改动还没进暂存区、当前在哪个分支上。我几乎每做一步操作都会敲一下 git status这算是个很好的习惯。git add 是把文件放进暂存区。如果想把所有改动的文件都加进去可以执行 git add .但要小心这会把当前目录下所有未忽略的改动全部加入暂存区。新手阶段建议逐个添加至少得知道自己在提交什么。git commit 正式创建快照。-m 后面的内容是这次的提交说明用来描述这次改动做了什么。提交完成之后这次快照就永久存在本地仓库里了。如果项目是托管在某个代码托管平台上的给仓库加一个远程地址然后把本地仓库推上去git remote add origin https://xx.com/your/repo.git git push -u origin main这里第一个命令把远程仓库地址绑定到本地的 origin 这个名字上。第二个命令把当前分支推送到远程的 main 分支-u 是建立本地分支和远程分支的关联以后再执行 git push 就不再需要指定远程和分支名了。2.3 提交信息怎么写才不遭同事白眼提交信息这件事很多人不重视但它直接影响协作效率。你在团队里拿到一份代码git log 打开一看提交信息全是“update”“修改”“aaa”这种你会是什么感受根本没法知道哪次提交对应哪个需求、哪个 bug 修复。规范一点的写法是用一个简短的类型前缀加描述。比如fix: 修复登录接口在空密码时返回 500 的问题 feat: 新增用户头像上传功能 docs: 更新 README 部署说明 refactor: 重构订单状态判断逻辑fix 和 feat 是最常见的两种分别表示修复和功能新增。这样的提交信息将来回查历史、出 changelog、定位问题都会省非常多的力气。个人经验是提交信息一句话能写清楚就绝不废话超过一行的说明放到正文里用空行隔开。3. 分支和合并团队协作的命脉3.1 分支到底是什么为什么要分支初学 Git 的人看到 git branch 这个命令往往不太理解分支的意义。简单说分支是从主线上分出来的一个独立工作空间。你在分支上做任何改动、提交都不会影响主线和其他同事的工作。这就是分支的核心价值隔离。我见过一个很形象的比喻主分支是主干道分支是施工现场旁边的临时绕行路线。你修路开发功能的时候不能把主干道堵死于是先绕行绕行路线修好了再接回去。Git 里的分支就是这个绕行路线。大家各自在分支上开发互不打扰开发完成经过审核确认没问题再合并回主分支。单人开发时分支的威力还不明显顶多是给自己一个安全的开发环境。到了多人协作分支基本是唯一的协作方式了。每个人从主分支拉一个自己的分支改完再合回去没有分支的话几个人同时改同一份代码冲突场面会非常混乱。3.2 合并与冲突处理创建一个新分支并切换过去最常用的命令是git checkout -b feature/login这个命令相当于做了两件事创建名为 feature/login 的分支并切到这个分支上。它等价于 git branch feature/login 然后 git checkout feature/login。在新分支上做了一些提交确认功能完成之后切回主分支把新分支合并进来git checkout main git merge feature/loginmerge 操作会把 feature/login 分支上的所有提交合并到 main 分支上。如果两个分支都改了同一个文件的同一处地方合并时就会产生冲突。冲突的表现形式是 Git 会把冲突区域的代码以特殊标记写进文件让你手动选择保留哪部分。处理冲突说起来很简单打开冲突文件找到冲突标记保留正确的代码删掉标记符然后重新 add、commit。但实际操作中冲突往往不那么好处理。我的建议是第一别慌冲突不是坏事说明 Git 很诚实地告诉你“这个合并我不能自己做决定”第二看不懂的冲突内容先把同事叫过来一起看宁可多沟通也别凭感觉删代码第三冲突标记内 、、 这三行标记在解决完冲突后一定要清理干净漏掉任何一个代码编译可能过不去。3.3 Pull Request 到底在做什么现在很多团队是在代码托管平台上做代码评审流程一般是开发者在分支上提交完代码之后发起一个 Pull Request简称 PR请求把分支合并进主分支。在 PR 里可以看到这次改了哪些文件、每个文件具体改了什么团队成员可以在这里讨论、提意见确认没问题后由有权限的人点击合并。对新手来说PR 是一个学习的好机会。你得学会看懂一次 PR 里的 diff文件差异对比搞清楚自己到底改了什么也得学会回应别人提的意见。我自己带过的人里有刚入职的小朋友第一次开 PR把几百行代码全塞进一个提交里评审人根本没法看。后来我给他的建议是拆提交。一个大功能分成几个逻辑完整的提交每个提交解决一个点这样评审人有顺序地看效率高很多。4. 撤销与回滚做错了怎么修4.1 五种后悔场景对照写代码最怕的不是出错是出错后不知道怎么办。我整理了几个最常见的“后悔场景”以及对应的解决办法。场景一改了工作区的文件还没 add想放弃修改。用 git checkout -- 文件名比如 git checkout -- index.html这个文件就会恢复到最近一次提交时的状态。场景二已经把文件 add 进暂存区了想把它从暂存区拿出来。用 git reset HEAD 文件名注意这个操作不会动工作区文件只是取消暂存。场景三已经 commit 了但是提交信息写错了。用 git commit --amend它会打开编辑器让你重新编辑上次提交的说明保存后上一条提交信息就被替换了。注意这个命令只适合还没有推送的提交如果已经推送了改动下次提交信息会导致远端历史不一致需要强制推送才能更新团队协作时尽量别这么干。场景四commit 之后发现漏了一个文件没提交想补进同一次提交。可以执行 git add 漏掉的文件然后再执行 git commit --amend这样漏掉的文件就补进上一条提交里了不用多出一条“补充提交”来污染历史。场景五已经 commit 了但发现代码有严重问题想把整个提交撤销。这就涉及下面要重点讲的两个命令git reset 和 git revert。4.2 reset、revert、checkout 三条命令的区别这三个命令初学者很容易搞混。我用最直白的方式说git checkout 用来解决“工作区或者暂存区层面的反悔”不影响提交历史。git reset 用来“回退提交历史”它是把 HEAD 指针以及分支指针移动到指定的提交上可以让你的分支状态“假装”某次提交之后什么都没发生过。git revert 则相反它不是移动指针而是创建一个“反向提交”把之前某次提交的改动反向执行一遍生成一个新的提交记录。什么场景选哪个如果你在自己本地的分支上提交之后发现全错了想干脆忘掉这次提交那就用 reset。如果你推送到了远程和大家共享了这个分支想撤销某次改动那就用 revert。原因很简单reset 会重写历史一旦推过远程别人的本地仓库里还留着旧历史两边就对不上了revert 不重写历史只是增加一条新提交所有人 pull 之后自然就同步了。reset 有三个模式软soft、混合mixed、硬hard新手记太多容易晕。我只说最实用的一条如果确定不需要回退点之后的代码了直接 git reset --hard 提交号如果只是想移动 HEAD 指针、保留工作区改动用 git reset --soft 提交号。日常用得最多的是 --hard但在执行之前务必确认自己真的不需要这些改动了因为这命令一敲那些改动就彻底没了。4.3 误删分支的恢复分支删了能恢复吗能。git 的分支本质上是一个指向某个提交的引用删分支只是删了引用提交本身在仓库里还在只要你记得那个分支最后指向的提交号就能再拉回来。假定我误删了 feature/login 分支先在 git reflog 里找回提交号git reflogreflog 是 Git 的“操作日志”记录了你所有本地操作中 HEAD 指针的移动情况。在 reflog 输出里找到删分支之前 HEAD 指向的那个提交号然后重新创建分支指回去git branch feature/login 目标提交号这样分支就回来了。我做过好多次这种救援操作成功率非常高。但有个前提reflog 里的记录有过期时间默认 90 天超期就找不回来了。所以分支这种东西别乱删删之前想清楚。5. 高频翻车现场与排障手册5.1 提交错文件、误包含敏感信息怎么办先说误提交的修复。如果只是多提交了一个文件而且还没有推送最优雅的处理方式是用 git reset --soft 回退到上一个提交让所有提交过的改动回到暂存区然后把不该提交的文件从暂存区移除重新提交一次。git reset --soft HEAD~1 git reset HEAD 不该提交的文件 git commit -m 正确的提交说明如果已经推送到了远端情况就比较麻烦。尤其是在公开仓库里提交了敏感信息比如数据库密码、密钥之类的哪怕是马上删掉再推送历史记录里依然留着这些信息。这种时候正确的做法是马上重置密钥密码不只是删代码。因为历史记录里的敏感信息可能已经被别人看到了。然后修改该文件中的敏感内容用新内容重新提交推送。至于清历史记录里的敏感信息可以借助工具重写历史但这是个进阶操作团队协作中强制推送会影响到其他人需要提前沟通好。注意任何情况下密钥、口令这类东西都不应该提交进 Git 仓库。正确的做法是用环境变量或者专门的密钥管理服务代码里只引用变量的名字。5.2 push 被拒的两种情况新手最常见的 push 失败场景有两种。第一种远程分支存在你没有的提交。比如同事已经推过代码了而你的本地还停留在旧状态此时执行 git push 会被拒绝因为远端不接受“会覆盖别人提交”的推送。解决办法很简单git pullpull 会把远程新的提交拉下来合并进你的本地分支。如果合并过程产生了冲突就按前面说的方法解决冲突然后重新 push。如果想保持提交历史干净整洁可以用 git pull --rebase它的效果是把你本地的提交“搬到”远程提交的后面而不是生成一次多余的合并提交。第二种本地当前分支没有设置远程追踪分支。执行 git push 时如果提示 “fatal: The current branch has no upstream branch”说明本地分支和远程分支还没有建立关联。按提示执行git push --set-upstream origin 分支名关联一次之后后续再 push 就什么都不用带直接 git push 就行。5.3 .gitignore 不生效的问题很多新手配置 .gitignore 文件之后发现某些文件还在被 git status 跟踪着就会很困惑。原因是.gitignore 只作用于“尚未被跟踪”的文件。如果一个文件已经被 Git 跟踪了也就是已经被 add 或者 commit 过了再写进 .gitignore 是不生效的。解决办法是先把这些文件从跟踪状态移除git rm -r --cached 文件或目录--cached 表示只移除暂存区/仓库里的跟踪记录保留工作区的文件。执行完加上注释说明然后 git add .gitignore git commit把这些文件的跟踪状态更新一下之后 .gitignore 就正常生效了。另外还有一个常见错误就是 .gitignore 里的路径写错。比如忽略 build 目录应该写 /build 或者 build/不要写 build二者的匹配范围完全不一样。这些细节踩过一次就很记住了。5.4 其他零碎但实用的高频细节最后分享几个日常 Git 使用中很容易被忽略、但实际非常提效的小操作。git log --oneline --graph把提交历史压缩成一行一条同时画出分支合并的图形一眼就能看出整个仓库的分支走向和提交脉络。git stash正在某个分支上改到一半突然需要切到另一个分支处理紧急事但改动还没完成不想提交。这时执行 git stash所有未提交的改动会被暂时存放起来工作区变干净可以放心切分支。处理完紧急事件切回来后执行 git stash pop 把改动恢复进度一分不少。git diff提交之前先看一眼具体改了哪些内容比 git status 的信息详细得多。git status 只看文件名git diff 能看到具体每一行。养成“先 diff 再 commit”的习惯可以帮自己过滤掉不少误改动。grep 命令同样可以用在 Git 相关的搜索里。比如想查某行代码是哪个提交引入的用 git log -S 关键词 可以搜索历史提交中某段字符串的变更记录。这个命令在排查问题时特别好用定位哪次提交改坏了什么比人肉翻代码高效太多。我个人实际操作中的体会是Git 的学习曲线其实很平缓最难的部分往往不是命令记不住而是命令背后的心智模型没建立好。刚开始就不要着急着去搞那些花哨的 rebase 交互式操作把 add、commit、push、pull、branch、merge、checkout 这几条最核心的命令练熟配合 git status 和 git log 随时确认状态日常开发已经完全够用。后面遇到更复杂的场景比如需要整理提交历史、跨分支挑拣改动那时候再针对性查资料学反而是最快的路径。另外也建议你从第一个项目开始就坚持用 Git 管理哪怕只是自己一个人写的练习项目。没有真实项目的压力命令敲再多也容易转头就忘只要自己真正在项目里走完几轮“改动—提交—推拉—合并—解决冲突”的循环这种感觉是看多少教程都替代不了的。