很多人学了三年 Git还是复制粘贴那七八个命令。add、commit、push、pull再多就发怵。可一旦遇到需要回滚、整理历史、修复冲突的场景就只能靠删库重来或者去找“保命命令”的帖子。2026 年了Git 自身的能力早就不是当年那个只能提交代码的工具分支管理、历史改写、安全加固、仓库维护都已经内置得很成熟。这篇东西不是翻译 man page 的命令大全是我自己在实际维护项目、带新人、处理线上事故时真正高频使用的一套命令清单附带我踩过的坑和为什么这么用的思路。适合刚把 Git 用熟但想更进一步的人也适合能给团队定规矩、做代码评审的人。1. 2026 年使用 Git 前必须做好的三件事1.1 确认 Git 版本并了解默认行为变化在开始之前先看看你本地 Git 版本。如果你还在用两年前装的 2.3x 或者更老的版本那么很多我在下文提到的命令比如switch、restore、sparse-checkout都用不了或者行为跟新版本不一致。2026 年的主流 Git 版本已经进入 2.4x 时代安全策略和默认配置都有不少调整。git --version我见过不少团队统一要求 Git 版本不低于某个基线原因很简单不同版本对换行符处理、子模块行为、甚至pull的默认合并策略都有差异这些坑在团队协作时会变成莫名其妙的冲突。建议至少保持在 2.40 以上如果公司有统一的安装包直接跟着走就好。另一个重要的默认行为变化是初始分支名。新版 Git 默认初始分支已经是main但如果你从旧版本升级上来或者在老仓库里初始化可能还是master。这两种命名本身没有优劣但团队内如果不统一会出现“我推的main跟你的master不是同一个分支”这种低级问题。定好一条规则新仓库统一用main老仓库如果团队想切换可以在仓库设置里改默认分支并同步删除旧分支。1.2 先配置好你的身份和换行符Git 提交记录里每一笔都带着作者信息。如果没设置全局 name 和 email提交时会用一个根据机器名生成的默认身份提交历史会变成一堆“unknown”。这个配置建议在安装后就做掉git config --global user.name 你的名字 git config --global user.email 你的邮箱注意这里填写的邮箱尽量跟代码托管平台账号一致这样提交能正确关联到你的账号头像。另一个关键配置是换行符git config --global core.autocrlf input # mac / linux git config --global core.autocrlf true # windows小白最容易在这里翻车。Windows 默认换行符是 CRLFLinux/mac 是 LF跨平台协作时 Git 会看到大量“整行都改了”的假差异。设置core.autocrlf后Git 会在提交时自动把 CRLF 转成 LF在检出到工作区时再按平台还原。实际踩过坑的都知道这配置没设对diff 根本没法看。1.3 配置别名和常用选项让日常操作更快Git 的原生命令太长了。我每天敲得最多的不是git status而是git st、git ci、git lg。这些全靠别名。推荐一套我用了很久的配置git config --global alias.st status git config --global alias.br branch git config --global alias.co checkout git config --global alias.ci commit git config --global alias.lg log --oneline --graph --all --decorate git config --global alias.last log -1 HEAD --stat注意lg这个别名特别有用它会把提交历史画成一张带分支、带标签的拓扑图肉眼审阅分支结构非常直观。还有人习惯加--simplify-by-decoration之类的参数但我觉得基础版已经够了。以上三件事做完你才算有一个“正常的”Git 环境。下面进入正题。2. 日常开发循环从改代码到提交保存的正确姿势2.1 用 status 和 diff 建立“改动感知”在我看来几乎所有人对 Git 的恐惧都来源于不知道当前仓库处于什么状态。因此第一个要养成的肌肉记忆是动手改代码之前先看一眼status。git status它告诉你三件事哪些文件已修改但未暂存哪些已暂存待提交哪些是未跟踪的新文件。我见过有人一开始就git add .一把梭结果把本地的临时文件、日志文件全部提交进去了不仅污染仓库还可能在别人拉取后产生路径冲突。正确逻辑应该是先status看清楚再决定哪些文件要进版本库。如果需要看具体的修改内容用git diff # 看工作区与暂存区的差异 git diff --staged # 看已暂存的内容与当前提交的差异这里的差别很容易搞混。diff看的是你还没add的改动diff --staged看的是你准备提交的内容。很多新人一直敲git diff说“我改了代码怎么看不到差异”其实就是因为已经把文件add了改看--staged。2.2 用 add 精确控制提交内容而不是无脑 add .git add .是最方便的命令也是最容易出问题的命令。正确做法是分文件或者分目录地添加git add src/utils/format.js git add src/api/user.js tests/api/user.test.js为什么这么较真因为一次提交应该只做一件事。如果你同时改了日志工具和用户接口这两个文件应该拆成两个提交方便后续单独回滚。据说“提交原子性”是代码评审里最常被提到的词其实就是这个意思一条提交可以被理解、可以被解释、可以被回滚而不影响无关内容。如果你想在提交前快速审查自己的修改可以先暂存部分文件再git diff --staged看差异是否合理。这套流程比较适合需要严谨对待变更的场景比如维护生产仓库。2.3 提交信息怎么写才能让队友和你自己看懂git commit -m fix bug这种提交信息我强烈建议不要用。三年后你自己回看历史一行“fix bug”根本不知道修了什么。写提交信息的技巧是第一行概括改动空一行后写具体原因。比如git commit -m fix: 修正订单金额计算溢出问题 浮点累加在极端数据下会出现精度丢失改为使用整数分单位计算。 Closes #123如果你用的是git commit不带-mGit 会打开编辑器这样写多行说明更舒服。团队如果强制规范格式比如 Conventional Commits那就按团队的来。我自己习惯在信息里附带关联到的 Issue 编号这样日后看历史可以直接跳转。2.4 提交之后发现漏了东西怎么办最常见的场景刚 commit 完突然发现少了一个文件或者想改一行注释再进同一个提交。这时候用git add 忘记的文件 git commit --amend --no-edit--amend把新改动合并到上一个提交并重写它--no-edit表示沿用原本的提交信息。要特别注意不要amend已经推送到远端并被人拉取过的提交。这会让别人的仓库历史和你的历史分叉产生不必要的合并冲突。只在本地提交上使用这是原则。2.5 常用的历史查看命令组合除了git log --oneline我比较常用的一招是git log --oneline --author你的名字 -n 20排查自己最近几天改了什么很方便。还有git log -p src/core/engine.js这个命令会把指定文件每一次提交的差异全部打出来适合追溯一个模块的演化过程。配合git blame看某一行是谁在什么时候改的能省去很多“这行代码为什么这么写”的疑惑git blame src/core/engine.js -L 85,95-L指定行号区间我只对特别可疑的代码段使用否则输出会太长。3. 分支管理合并、变基与冲突解决的实战套路3.1 switch 和 checkout 到底用哪个2026 年官方推荐用git switch做分支切换用git restore做文件恢复这两个命令把原来checkout一个命令承担的两种职责拆开了。这样不容易误操作。git switch feature/login # 切到已有分支 git switch -c feature/payment # 创建并切到新分支 git restore README.md # 丢弃工作区对该文件的修改对应老命令是git checkout feature/login和git checkout -b feature/payment。都能用但新命令的语义更清晰。特别提醒一下switch有一个参数很实用git switch - # 切回上一个分支在几个分支间来回比较时这一条命令可以省不少事。3.2 merge 和 rebase 的选择逻辑这是团队里吵架最多的话题。先说区别。git merge会把两个分支的历史合并成一个新的合并提交保留两个人各自的分叉记录git rebase则是把你的提交逐个摘下来接到目标分支的最新提交后面得到一条线性历史。我自己的实践经验是功能分支为了跟上主分支的最新进度用rebase更干净后续合并回主分支时历史是直线。需要保留真实协作痕迹或者功能分支已经公开共享别乱 rebase直接 merge 更安全。一个典型操作git switch feature/login git fetch origin git rebase origin/main这里fetch再rebase而不是直接git pull是为了避免把默认的 merge 行为带进来。3.3 冲突解决的完整步骤不管怎么注意冲突总会出现。我第一次遇到冲突时慌得要命。其实冲突的本质就是 Git 不知道该怎么合并你对某一行和另一个人对同一行的不同修改。处理过程如下用git status找到标记为UU或both modified的文件。打开文件搜索冲突标记、、。手动把内容改成你想要的结果删除冲突标记。保存文件git add这个文件。继续git rebase --continue或git merge --continue。如果改到一半觉得不对劲想回到冲突前的样子git rebase --abort这不是“失败”而是保护自己不把坏状态提交上去。冲突和解决冲突是日常开发的必修课多处理几次就会熟练。需要特别留意的是解决冲突时不要顺手把对方的改动全部丢掉至少看一眼冲突区域上下文的代码。3.4 用 rerere 记住你的冲突解决方式git rerere全称是 reuse recorded resolution即“复用冲突解决”。开启后 Git 会记住你之前解决冲突的方式下次遇到完全相同的冲突会直接应用。git config --global rerere.enabled true这个配置我强烈建议打开。因为在一个大型重构过程里同一个冲突可能会在 rebase 不同批次提交时反复出现。没有 rerere 的话你要手动解很多遍一模一样的冲突开启后第一次手动解决后面 Git 自动处理。这是很多老手效率高但从不解释的秘密之一。3.5 分支清理保持仓库整洁合并完功能分支后把已经合并过的分支删掉git switch main git branch --merged git branch -d feature/login # 安全删除本分支 git push origin --delete feature/login # 删除远端分支git branch --merged先列出所有已经合进当前分支的本地分支确认无误再删。如果分支有未合并的提交-d会拒绝删除这时如果确实要强制删除用-D。这个保护机制比较有用可以避免误删工作成果。4. 远程协作推送、拉取、撤销的完整方案4.1 理清 fetch、pull、push 的关系在团队协作中最基础也最容易被误解的就是这三个命令。git fetch只是把远端的新提交下载到本地但不会改动你的工作区和当前分支。git pull等于 fetch merge或者 fetch rebase取决于配置。git push则把你本地提交上传到远端。我建议在需要保持工作区干净时显式使用fetch然后自己决定是merge还是rebase而不是直接pull。例如git fetch origin git log --oneline HEAD..origin/mainHEAD..origin/main会列出本地没有但远端分支上有的提交也就是合并前应该审阅的改动。这个操作看得很清楚能避免盲目pull之后撞上大冲突。4.2 用跟踪分支关联远端设置上游分支git push -u origin feature/login-u是--set-upstream的简写。设置之后在该分支上执行git pull或git push就不需要再带远端名和分支名了。如果 clone 一个仓库本地会自动把main关联到origin/main但自己新建的分支必须手动设置一次。查看本地所有分支的跟踪关系git branch -vv如果某个分支显示[origin/feature/x]说明跟踪已建立。这对维护多个功能分支的人特别重要。4.3 拉取时保持线性历史pull --rebase 的适用场景如果你在一个公用分支比如团队每天都在往里合代码的main上本地还有未推送的提交执行git pull默认会产生一个 merge 提交。这个提交会把历史变得杂乱。我的习惯是git pull --rebase这会把本地尚未推送的提交临时取下来拉取远端新提交后再把本地提交重新放上去。得到的是一条线性历史回看git log --graph非常干净。不过要注意一个边界如果你从来没有把本地提交推送到远端rebase 一般很安全只要远端分支上没有别人基于你的旧提交工作过就随便 rebase。反之如果这些提交已经被其他人拉取过rebase 会制造新的分叉反而更麻烦。4.4 推送被拒绝怎么办场景是这样的你用git push推代码结果提示! [rejected]。原因通常是远端有比本地更新的提交。此时先git fetch origin再git log --oneline HEAD..origin/main看看远端差异。如果确实只是远端新增了提交用git pull --rebase origin main git push如果远端已经存在本地会覆盖的分支但你有意要用本地覆盖远端比如你正在强行修正一个错误推送的功能分支才考虑git push --force-with-lease origin feature/login--force-with-lease比--force安全因为它在推送前会检查远端分支是否跟你上次看到的一致如果别人已经推了新的提交它会拒绝覆盖。这个细节很有用——--force会无条件覆盖而--force-with-lease则在你和队友同时都往这个分支推提交时保护你不误伤别人的工作。4.5 撤销已经推送到远端的提交不要在生产环境用git reset去回滚远端分支因为重置历史会导致别人本地分叉。正确做法是用git revert生成一个反向提交把“撤销”这件事记录到历史里git revert HEAD这样相当于提交一个新版本把上一次提交的内容倒回去历史仍然是一条直线所有已经拉取过这段代码的同事都能平滑更新。revert能指定任意一个提交比如git revert abc1234如果只想把某个提交从历史中彻底抹掉不推荐在共享分支做才需要git rebase --onto或git filter-repo这类改写历史的手段。5. 进阶命令用好这些才算真正会 Git5.1 stash临时挂起工作现场突然要切到别的分支看一个 bug但你当前分支改了一半不想提交。这时候git stash就是救命稻草git stash # 默认暂存已跟踪文件的修改 git stash -u # 连未跟踪的新文件一起暂存 git stash list # 查看暂存列表 git stash pop # 恢复最顶上的一份暂存 git stash drop stash{1} # 删除某一份暂存我习惯在每次stash之前先用git status检查一下确认哪些文件会被带进去避免把调试日志也暂存了。另外stash有-m参数可以加备注比如git stash push -m 注册页样式未完成多份暂存时非常有用。踩过的大坑在git stash pop时如果跟当前工作区冲突Git 会保留修改但可能有冲突标记需要手动解一次。别慌这是保护机制不是出错。5.2 reflog后悔药的仓库reflog是 Git 的“操作日志”记录了 HEAD 指针的每一次移动。哪怕你reset到了一个旧提交或者 rebase 失败重来只要 reflog 里还能找到那个提交指针就能找回“丢失”的提交。git reflog它会列出类似HEAD{0}、HEAD{1}的记录对应每次操作的新的 commit id。想回到某个状态就git reset --hard HEAD{2}但要小心reset --hard会丢弃工作区里的改动。在此之前最好先确认是否有未提交的修改可以git status检查后决定是否先 stash。我自己真实遇到过一次 rebase 操作把功能分支的一个提交给弄丢了团队里没人能记得那个提交的 hash。当时就是靠git reflog找到的然后用git cherry-pick把它捡回来。可以说 reflog 是最后的防线但确实是最可靠的。5.3 cherry-pick把指定提交复制到其他分支不需要整条分支合并只想把某一次提交的改动拿到当前分支用git checkout main git cherry-pick abc1234这个命令在修复线上 bug 时很常用你在main上开发了一个修复测试通过后需要把同一个修复同步到正在维护的release-2.x分支此时直接挑拣那个提交过去而不是把整个 main 合并过去。如果 cherry-pick 过程中遇到冲突同样是手动解决后git cherry-pick --continue想放弃就--abort。5.4 bisect二分定位引入 bug 的提交有一个很难排查的问题功能在一个月前是好的现在坏了。不知道是哪一次提交引入的。git bisect就是为这种场景设计的。原理很简单在坏版本标记 bad在好版本标记 good然后用二分查找帮助定位第一次出现坏行为的提交。git bisect start git bisect bad # 当前版本是坏的 git bisect good v2.1.0 # 假定 v2.1.0 是好的接下来 Git 会切到一个中间提交你运行测试后告诉它是好还是坏git bisect good # 或 git bisect bad反复几次最终会定位到那个罪魁祸首提交。对于长期维护的大型仓库这个命令对排查性能回退和功能异常都非常高效。5.5 worktree一个仓库检出多个工作目录很多人在同时改两个分支时被迫频繁 stash 或 clone 两份仓库。git worktree可以让你在本地一个仓库里为另一个分支单独创建一个工作目录git worktree add ../project-feature feature/login这样你可以在一个目录里用 main 分支改 bug在另一个目录里用 feature/login 分支写新功能互不干扰。切换分支时也不用随身携带“未完成的工作”。用完删除git worktree remove ../project-feature这个功能对前端或者后端这种需要多分支并行开发的场景帮助非常大。5.6 sparse-checkout只要仓库的一部分如果你的仓库很大比如包含了很多子文件夹而你只需要其中几个目录稀疏检出能大幅节省磁盘和拉取时间git sparse-checkout init --cone git sparse-checkout set src/config src/utils设置后拉取只会下载这些目录下的文件。这个功能尤其适合在超大仓库或者 monorepo 里做定向开发。注意稀疏检出不会改变提交历史只是控制工作区的文件可见性。5.7 子模块的正确打开方式子模块是很多团队的心头痛。能用好它的前提是理解子模块不只是“一个子仓库”它是父仓库某个提交时点上的一个版本引用。常用命令git submodule add https://example.com/path/to/repo.git vendor/some-lib git submodule update --init --recursive git submodule status需要注意的是升级子模块后父仓库也会产生一个“指向新版本”的提交这个提交要单独提交推送。如果你只是修改了子模块内部的文件父仓库里显示的也是变动状态需要先在子模块里提交推送再到父仓库里提交引用更新。顺序反了会导致别人拉下来后子模块处于“分离 HEAD”状态。5.8 仓库维护gc、maintenance 与 fsck大型仓库用久了会出现很多冗余对象性能下降。Git 自带的垃圾回收虽然会自动触发但我们可以显式手动执行git maintenance start # 启用后台维护 git gc --auto # 自动回收不可达对象 git fsck --no-dangling # 检查仓库对象完整性git maintenance是 2.30 之后引入的命令官方推荐用它来做定期优化。另一个容易被忽略的git fsck检查是否有关联损坏的对象在备份仓库前做一次能避免把坏对象备份上去。6. 高频问题排查速查表下面这些是我这几年被问得最多的问题整理成一张表直接照做就可以。症状命令说明提交信息写错了git commit --amend -m 新信息只在本地提交使用远端已共享别改add 多了文件想移除git rm --cached 文件从暂存区移除但保留工作区文件想彻底撤销一个提交并回到它的上一版git reset --hard HEAD~1会丢工作区改动慎用想丢弃某个文件的本地修改git restore 文件从 HEAD 恢复未提交内容会丢想找回误删的分支git reflog找 hash 后git branch 分支名 hash分支误删也能恢复推送被拒绝git pull --rebase再git push保持线性历史避免无效 merge 提交冲突解决到一半想放弃git merge --abort或git rebase --abort回到操作前状态不知道某行代码谁改的git blame 文件 -L 行号显示提交、作者、时间想合并多个本地提交git reset --soft HEAD~3后重新git commit软重置只移动 HEAD不丢改动工作区有改动且想切分支git stash再切别忘了git stash pop有未跟踪文件用-u这张表不是万能药但覆盖了日常和救急两大场景。如果某条命令的实际效果和你想象的差距很大先跑git status再跑git diff确认你当前处于哪个状态。绝大多数误操作都是因为搞混了工作区、暂存区、本地仓库和远端仓库这四个层面。7. 我最后想分享的几个小细节回过头看我这些年用 Git 的经验最大的改变不是从“会背命令”变成“会查命令”而是学会了在动手之前先思考当前操作处于 Git 的哪个层面。工作区的修改可以被stash保存暂存区的内容可以被reset撤销本地提交可以被rebase重整远端提交只能被revert或带保护的push --force-with-lease修正。这四层分清楚了大部分命令你都能推测出用途。另外如果你在团队里经常做代码评审试着要求每一个提交只解决一个问题、每条提交信息能独立被读明白、每个人在合入功能分支前自己先跑一遍git log看清楚将要合入的内容。这些习惯比任何一条高级命令都更能减少事故。我自己从踩过reset --hard丢代码、push --force覆盖队友工作的教训里走出来的经验告诉我Git 不怕操作多就怕你不知道自己正在改写什么、影响谁。每一次敲回车之前花三秒钟在脑子里过一下这句你的 Git 水平会立刻提高一个段位。