1. 关于 Git 命令这件事先聊几句实在话作为一个每天跟代码打交道的开发者Git 大概是我用得最多的工具之一。很多人觉得 Git 命令又多又杂记不住、用不好甚至有人跟我说能跑就行能提交就行。但实际上把 Git 用明白和把 Git 用熟练差别非常大——前者只是会点按钮后者才是真的能掌控自己的代码。2026 年了Git 依然是绝大多数团队的协作基础。不管前端、后端、客户端还是运维方向只要写代码就绕不开这套版本管理工具。更不用说现在很多代码托管平台、自动化流水线、云端开发环境底层几乎都依赖 Git 协议。所以这篇东西不是讲Git 是什么而是把日常开发里真正用得上的命令全部过一遍讲清楚它们的作用、使用场景还有我个人踩过的坑。这套内容适合谁看说实话覆盖范围挺广的。你要是刚入行可以把这篇当作一本拥有索引的手册来读至少遇到问题知道去哪找答案你要是已经有几年经验也可以看看里面的参数细节和排查思路我相信总有几个命令是你不常用但关键时刻能救命的。我不打算讲那种概念完美、实际用不上的理论全部都是日常开发能用到的内容。我用的一直是命令行版的 Git官方版本没换过别的。虽然有很多 GUI 工具做得越来越顺手但命令行的优势仍然没法替代可脚本化、可自动化、出错可控、不依赖特定平台。而且那些 GUI 工具底层调用的还是这些命令你理解了命令行用界面也只是换个操作方式而已。从我个人经验来说UI 工具在某些场景下很方便比如查看图形化的提交记录、比对改动内容但要说精细操作最后还是要回到命令行。所以在往下读之前建议你先把终端打开确认一下 Git 版本。我的环境是主流 Linux 发行版Git 版本在 2.4x 系列日常命令在 2.20 以上的版本基本都兼容。如果你用的版本太老某些命令的参数可能会对不上这也是实际排查问题时要先想到的原因之一。2. 本地工作流每天都要碰的 Git 命令本地工作流是所有 Git 操作的基础。无论你最终要跟多少人协作代码的提交、对标、记录管理都是先从本地开始的。这一节我会把 init、add、commit、status、diff、log 这些最常见命令讲透每个命令的参数和适用场景都会展开。2.1 git init 与仓库初始化新项目开始时第一件事就是初始化 Git 仓库。git init 这个命令从字面上看很简单但它背后做了一些事情绝对值得你了解。执行之后Git 会创建一个隐藏的 .git 目录里面包含 objects、refs、logs、hooks 等子目录这些就是你项目全部的历史记录和配置所在。实际使用中我更喜欢在初始化前就想清楚几个问题。仓库是只放源码还是连配置文件一起放要不要在 init 之前先写好 .gitignore这决定了你第一次 add 的时候会不会把一堆没用的文件放进暂存区。很多新手容易忽略 .gitignore结果把 node_modules、target、venv 这种依赖目录或编译产物直接提交上去了后面再想起来排除历史记录里已经留下了大量无用文件仓库体积越来越大clone 也越来越慢。我自己初始化仓库的标准流程是这样的git init # 创建仓库 git branch -m main # 把默认分支改成 main看团队习惯 git config user.name 你的名字 git config user.email 你的邮箱有人说 git init 之后还要 git config --global user.name 设置全局身份这没错但同一个提交在不同机器上可能因为环境变量、局部配置产生差异。我的习惯是每个仓库都单独检查一遍 user.name 和 user.email避免把公司账号和私人账号混在一起提交。这个细节很多人不在意等代码提交上去发现邮箱错了再修复就要动历史记录麻烦得多。顺带一提git init 还有一个容易被忽视的用法git init --bare这种裸仓库不带工作区没有主要的源码副本只接收推送一般用在服务器端搭个中转仓库。我自己搭过几次内部代码服务器直接用 --bare 建裸仓库再配合 hook比装一套庞大的代码托管服务要轻量得多。如果你是纯客户端开发这个可能不常用但如果你负责搭建团队内部仓库这个参数你迟早要碰。2.2 git add、git status 与暂存区的工作逻辑git add 是把工作区改动放进暂存区这个阶段很多初学者不理解为什么要存在。最直观的说法是提交应该是一个可以描述完整逻辑的变更单元而不是一个个零散文件。你先用 git add 把想提交的文件挑出来再用 git commit 打包成一个逻辑上的提交这样后期查历史、做回退、做代码审查都能按单元来理解。不过在 2026 年我实际上已经很少用 git add . 或者 git add -A 这种笼统地把所有改动都加进去的方式了。原因很简单太容易把不该提交的东西混进去。比如你在调试时临时改了一个配置文件本来没打算提交结果 git add . 全加上了后面 commit 也没注意这个调试配置就进了历史。更推荐的做法是git add src/ 路径/到/具体文件 git add -p # 进入交互式暂存逐个大块选择是否暂存git add -p 是我强烈建议你用起来的技能。它会先把改动拆分成一个又一个大块hunk然后问你每个大块要不要加进来还允许你自己编辑和再拆分。我每次把某个功能的改动和顺手修的格式改了混在一起时都用这个命令把它们分开提交这样每个提交的历史就很干净。要拆提交它是神器。跟 add 常常搭配看的是 git status。坦白说很多人执行 git status 就是瞄一眼然后继续操作。但你如果仔细研究它的输出会发现它真的把当前仓库状态讲得明明白白哪些文件暂存了、哪些只是修改未暂存、哪些是未跟踪文件。加上 -s 短格式输出的信息也有用git status -s输出每一行前面有两个字符位置左边代表暂存区状态右边代表工作区状态。M 是修改A 是新增D 是删除?? 是未跟踪。熟练之后扫一眼整屏状态就知道仓库是什么情况不需要再反复 git diff 看细节。2.3 git commit 与提交信息的务实写法git commit 是形成一个提交点相当于帮你把某个阶段的代码状态拍照存档。这句话我说得简单但提交的时候有两个点一定要把握住。第一是提交信息。我见过不少提交信息写得乱七八糟的情况比如fix bug、update、或者干脆是aa。等过了三个月回来看提交记录完全不知道那个提交做了什么。我自己的做法是遵循规范的总结式写法第一行用一句话写清楚核心改动然后空一行再写详细说明。优先使用动词开头比如fix: 修复登录页面在移动端布局错乱的问题后面再补充这个问题的触发条件、影响范围、修复方式。这样时间久了拉日志出来看每条提交都是一份简短的变更说明。第二是提交内容。理论上一次提交应该只做一件事。但现实中经常出现的情况是改了一个功能顺手调了一下样式又改了几行无关紧要的代码。这时候我建议你多用 add -p 把它们拆开宁可多提交几次也不要让提交内容混成一锅粥。如果发现 commit 之后发现出现了没想到的问题Git 也给你准备了补救措施。最常见的是 --amend它可以把当前暂存区的改动和上一个提交合并生成一个新的提交。适用于上一个提交刚做完就发现一个笔误或者少加了一个文件这种场景。git commit --amend -m 新的提交信息要注意的是amend 的本质是替换提交所以如果你的提交已经被推送到远端并且其他人基于它做了改动那这不是一个好的选择。还没推出去的提交随便改已经推上去的不要轻易动。2.4 git diff 是看清改动的最佳工具只要涉及代码改动git diff 就是避不开的命令。它是比较工作区与暂存区、暂存区与最近一次提交、任意两个提交之间差异的核心工具。光知道 git diff 不加参数还不够下面的参数组合你得用得滚瓜烂熟git diff # 工作区与暂存区之间的差异 git diff --staged # 暂存区与 HEAD 之间的差异 git diff HEAD # 工作区与 HEAD 之间的差异 git diff 分支A 分支B # 两个分支之间的差异 git diff HEAD~2 HEAD # 过去两个提交与现在之间的差异不加参数时比较的是工作区和暂存区而不是工作区和上一次提交。这个细节是很多新手晕的地方。你改完文件之后执行 git diff能看到改动但如果你已经 git add 了再用 git diff 就看不到内容了因为改动已经进了暂存区这时候必须加 --staged 来看。diff 的输出默认是有颜色的绿色代表新增红色代表删除。如果你想看懂整块的话我建议抽时间了解一下统一 diff 格式的逻辑以 开头的那一行标了文件里从哪个行号开始、跨越多少行后面逐行列出上下文、新增和删除的行内容。排查问题时定位到具体 diff绝大多数情况下比猜代码要准。还有一个细节git diff 支持 --stat 参数只显示文件级别的增减统计。我在 commit 之前经常会执行git diff --stat扫一眼哪些文件变动了、变动规模大概多大心里有数再提交不容易出现把意外文件带进来的情况。2.5 git log 与提交历史的阅读方法git log 是查看提交历史的命令。默认输出每条提交的哈希值、作者、日期和提交信息但默认格式信息密度偏低实践里我更常用带参数的形式git log --oneline # 每条提交只显示一行含短哈希和信息 git log --graph # 显示分支、合并的图形走向 git log --author某开发者 git log --since2 weeks ago git log -p # 显示每个提交的具体 diff git log -5 # 只显示最近 5 条提交我平时用得最多的是 --oneline --graph --decorate 的组合拉出来的历史一眼就能看出分支从哪里分出来、哪些提交是合并进来的。当仓库里的提交数量多了以后这个命令就是梳理协作脉络的核心工具。历史记录就像项目的日志也是定位问题的工具。假设你的某台生产环境出问题了你知道大概在三天前有改动那就可以用 git log --since3 days ago --until1 day ago 配合 --all 来看所有分支在这段时间内有什么动作。再用 git bisect 做二分定位后面我会专门讲。3. 分支操作多线开发的指挥中枢分支是 Git 工作流里最重要的概念之一。你自己单独开发可能感觉不深一旦跟别人协作或者需要同时维护多个版本分支就是你的命根子。3.1 git branch 与分支的增删改查git branch 的常规用法我也整理一遍git branch # 查看本地分支* 号标记当前所在分支 git branch -a # 查看本地和远程分支 git branch 新分支名 # 创建分支 git branch -d 分支名 # 删除已合并的分支 git branch -D 分支名 # 强制删除未合并的分支 git branch -m 旧名 新名 # 重命名分支创建分支本身只是一个指针操作成本很低所以不要怕多建分支。真正要注意的是分支的命名规范和生命周期管理。团队里最好有一套大家都遵守的命名规则比如功能分支用 feature/xxx修复分支用 fix/xxx版本分支用 release/xxx。如果你一个人单干无所谓但协作开发时分支名混乱会导致合并完根本不知道该删哪个、保留哪个。删除分支时要特别小心 -D 和 -d 的区别。-d 在分支未合并时会拒绝删除保护你的工作-D 是强删不检查是否合并。我见过同事把还没合并的分支直接 -D 删掉结果功能白做了。所以除非你真的确定这个分支没用了否则别用 -D。3.2 git checkout、git switch 与分支切换切换分支是日常高频操作但这里其实有个重要的历史背景。早期的 Git 中 git checkout 承担了太多职责既能切换分支又能恢复工作区文件还跟 HEAD 的概念绑定得比较死。从某个版本开始Git 官方把切换分支的功能独立出来推荐使用 git switch而恢复文件用 git restore让职责更清晰。git checkout 分支名 # 传统切换方式 git checkout -b 新分支名 # 创建并切换 git switch 分支名 # 推荐的切换方式 git switch -c 新分支名 # 创建并切换-c 等同于 checkout 的 -b不论用哪个切换分支的核心风险点都在于工作区需要保持一致。Git 会在切换分支时尽量把当前未提交的改动带过去如果目标分支和当前分支对同一个文件有冲突Git 会拒绝切换并提示你先处理冲突或者用 stash 把当前工作存起来。这种时候别慌按提示操作先 stash 再切换到目标分支上再 pop 回来即可。3.3 git merge 与 git rebase两种集成方式的选择题分支创建出来就是为了最终合并回主干。git merge 和 git rebase 是两种完全不同的集成思路也是新手最容易困惑的选择题。merge 会生成一个新的合并提交保留每个分支的独立历史。打个比方就像两条河流汇合到一起两条河各自的历史清清楚楚。当你在主分支上执行 git merge 功能分支 时Git 会找这两个分支的共同祖先然后把功能分支上的新改动合并过来。如果改动互不冲突合并会自动完成有冲突则要手动解决。rebase 则是把当前分支上的提交重放到目标分支的最新位置相当于把你的支流裁剪下来移植到河流的主干上。它会让提交历史看起来是一条直线更整洁但代价是重写了提交历史。已经推送到远端的分支尤其涉及到多人协作的分支不要轻易 rebase否则会把队友的历史搞乱。关于 merge 和 rebase 的选择我的实际经验是分场景的在功能分支上按常规开发要跟上主分支最新进度时用 rebase 拉最新代码避免频繁产生多余的合并提交在共享分支上集成分支改动时用 merge保留真实的协作线如果提交历史乱成一团、想整理成线性历史再推远端用 rebase 配合交互式参数rebase 的交互式模式值得展开说一下git rebase -i HEAD~5执行之后会进入编辑器列出最近 5 个提交你可以对每个提交指定操作pick 是保留reword 是修改提交信息edit 是修改提交内容squash 是合并到上一个提交fixup 是合并且丢弃信息。我用它把临时提交清理干净是一个日常操作比如add temp code、fix typo这种提交在推远端之前全部 squash 成一条完整的功能提交历史就好看得多了。但请注意rebase -i 是危险操作操作前最好确认这些提交还没有被推送到远端。如果你已经 push 出去了再 rebase 本地提交远端历史和本地历史会分叉下次 push 就会被拒非得强制推送才能对上——而强制推送在共享分支上会带来灾难。3.4 解决冲突的正确姿势无论是 merge 还是 rebase冲突几乎不可能完全避免。所谓冲突就是两个分支在同一文件的同一区域做了不同修改Git 不知道该以谁为准。冲突出现时你打开文件会看到类似这样格式的内容 HEAD 当前分支的版本 要合并进来的版本 功能分支 到 之间是当前分支的内容 到 之间是另一分支的内容。你手工把该留的留下、该删的删掉然后保存文件再用 git add 标记为已解决最后执行 git merge --continue 或 git rebase --continue 完成流程。解决冲突是整个 Git 操作中最考验对业务代码熟悉度的环节机器帮不了你。你只有真正知道这段代码该保留什么逻辑才能做出正确选择。我唯一的建议是每次解决完冲突一定要重新跑一遍相关测试。合并本身就有可能引入逻辑矛盾何况是手动取舍的结果没有测试兜底后面出问题你都不知道什么时候引的。4. 远程协作跟中央仓库打交道到了团队协作阶段Git 的核心场景就从本地切换到了远方。这一节讲 clone、remote、fetch、pull、push 这些命令聊清楚它们之间的配合关系。4.1 git clone 与首次拉取代码git clone 是从远程仓库复制一份完整代码到本地的命令。我见过有人以为 clone 只拉最新代码其实不是——它是把整个历史、所有分支引用、全部对象都下载下来只是默认只给你 checkout 了当前分支的工作区。所以 clone 出来的仓库本地是可以直接切换分支、查历史的。clone 常用的几个参数git clone 地址 git clone --depth 1 地址 # 浅克隆只拉最新一次提交 git clone --branch 分支名 地址 # 克隆后切换到特定分支 git clone --recurse-submodules 地址 # 同时初始化子模块浅克隆 --depth 1 在应对大型仓库时很实用只拉最新提交节省时间与磁盘空间。但要注意它带来的限制因为没有完整历史之后一些操作比如基于旧提交查看、blame、bisect会受影响。我自己在 CI 构建环境里会大量使用浅克隆因为构建只需要最新代码本地开发则通常用完整克隆保证历史完整。clone 后第一件事我会确认 remote 配置对不对然后立刻建立自己的分支干活而不会直接在主分支上开发。原因很简单主分支应该只接受集成不该成为个人开发的战场。4.2 git remote 与远程仓库管理git remote 是管理远程仓库引用的命令。最常用的操作是 -v 参数查看所有远程地址git remote -v输出会显示远程仓库的名字和地址比如 origin 这个默认名字。为什么要知道这个因为很多时候你要确认克隆下来的仓库到底连的是哪个地址如果配错了之后的 push 可能会推到错误的地方。你需要掌握的 remote 操作git remote add 名称 地址 # 添加远程仓库 git remote remove 名称 # 移除远程仓库 git remote rename 旧名 新名 # 重命名 git remote set-url 名称 新地址 # 修改远程地址在 2026 年的实际开发里一个仓库带多个 remote 是很正常的事情。比如一开源项目你自己 fork 了一份然后把原仓库也加进来作为上游通常叫 upstream这样既能往自己的仓库推代码也能随时拉上游的新改动。这种工作流我强烈推荐特别是参与开源项目时它规范又容易操作。4.3 git fetch 与 git pull拉取更新的本质区别git fetch 和 git pull 的区别是很多人的认知盲区。简单说fetch 只从远程下载新数据到你的本地引用但不会自动合并到当前工作区pull 则是 fetch 之后自动做一次 merge 或 rebase。如果你只是想知道远程有哪些新提交而不想立刻影响当前工作区用 fetch 就好。fetch 是安全的它不会改动你本地的工作状态。pull 则可能因为自动合并产生冲突如果策略没配好可能直接让你本地工作区处于冲突状态。推荐的工作流是先 fetch看清楚远程分支和自己本地分支的差异再决定怎么合。范例git fetch origin git diff main origin/main # 查看本地 main 和远程 main 的差异 git status # 看本地和远程是否分叉pull 本身也推荐指定方式git pull origin main # 默认用 merge 策略 git pull --rebase origin main # 用 rebase 策略使用 --rebase 还是默认 merge要跟团队的协作习惯对齐。如果你所在团队强调线性历史就统一用 rebase如果无所谓那 merge 更稳妥。最怕的是团队里有人 rebase、有人 merge推送历史乱七八糟。4.4 git push 与推送背后的细节git push 是把本地提交推送到远程仓库的命令。最基础写法git push origin 分支名 git push -u origin 分支名 # 首次推送并设置上游跟踪-u 这个参数值得多说一句。它把本地分支跟远程分支建立关联之后你再敲 git push 不带任何参数时Git 就知道该推到哪里了。新分支第一次推送时我几乎一定会加 -u。push 被拒绝的情况是日常开发里最常见的挫折之一。原因通常只有一个远程分支上有你本地没有的提交。Git 默认拒绝非快进推送目的是防止覆盖别人的工作。解决办法同样是两条路一是先 pull或 fetch 后 merge/rebase把远端改动合到本地再 push二是用 --force 强制推送。但 --force 是危险操作只有在你明确知道自己要覆盖远端内容时才应该用。更精细的强制推送有个相对安全的变体git push --force-with-lease它的意思是检查远程分支在我上次 fetch 之后是否被别人改动过只有没被改过时才允许强制推送。这个参数比直接 --force 安全得多。我清理已经推送但想改写的提交历史时只用 --force-with-lease几乎不用裸的 --force这样即便远程有意外改动也会被拦下来提醒你。5. 撤销、回退与历史修复给错误按一下撤销键Git 之所以让人有安全感很大程度上是因为它具备强大的撤销机制。但撤销的方式非常多选错了可能把场景变得更加麻烦。这一节我把 reset、revert、cherry-pick、stash 讲透。5.1 git restore工作区和暂存区的后悔药如果你只是改了文件但还没提交想撤销改动最直接的是 git restore。这个命令是相对较新的版本引入的专门替代了 checkout 和 reset 在恢复文件方面的职责。git restore 文件名 # 把工作区的文件恢复到暂存区或 HEAD 的状态 git restore --staged 文件名 # 把暂存区的文件取消暂存内容保留--staged 那个场景很典型你 git add 了某个文件但仔细一想这个文件不应该进这次提交于是用 restore --staged 把它从暂存区拎出来文件改动仍然在工作区只是不再暂存。注意restore 不加文件路径会操作所有文件操作前确认一下不然容易把不该恢复的改动也冲掉。有一点必须反复强调restore 一旦执行工作区里未提交的改动就没有了。这个命令没有回收站机制误操作不可逆。所以执行前如果有一丝一毫的犹豫先把文件备份或者用 git stash 存起来。5.2 git reset移动 HEAD 与重置状态git reset 是本地历史操作的重武器。它的核心作用是移动 HEAD 指针并且按参数不同决定是否同时重置暂存区和工作区。git reset --soft HEAD~1 # 只移动 HEAD暂存区和工作区都不变 git reset --mixed HEAD~1 # 移动 HEAD重置暂存区但不重置工作区默认 git reset --hard HEAD~1 # 移动 HEAD同时重置暂存区和工作区这三个级别的理解直接决定你会不会用错场景--soft撤销 commit但保留所有改动在暂存区。适合你刚提交完就发现信息写错了、或者忘加了文件反正提交还没推出去撤销之后重新 add、再提交。--mixed撤销 commit且取消暂存改动回到工作区并保留内容。这是默认模式适合提交完成后发现分块不合理、想重新组织提交。--hard撤销 commit同时丢弃暂存区和工作区的所有改动。这个操作是不可逆的执行之前一定要想清楚。另外reset 也能回退到任意历史提交不只是相对位置git reset --hard 某个提交哈希这个命令一执行整个本地仓库状态直接回到那个提交时的样子。如果你有未提交的工作也会一并消失。所以我在 reset --hard 之前要么确认当前工作区干净要么先 stash。还需要一个提醒reset 动了本地历史跟你在别的机器上 push 出来的历史就会分叉。所以 reset 之后要推送几乎必然涉及 --force-with-lease而这个在共享分支上有很大风险。结论就是自己没过问题reset 随便用别人也在用的分支优先考虑 revert。5.3 git revert安全撤销已经提交的记录revert 跟 reset 的核心区别在于reset 是回退历史revert 是新增一个撤回提交。它不会删除原提交而是创建一个新提交内容恰好把某个旧提交的改动反过来。git revert 某个提交哈希 git revert HEAD # 撤销最近一次提交 git revert HEAD~2..HEAD # 撤销最近两个提交为什么要在共享分支上用 revert 而不是 reset因为 revert 不改变已有提交历史它在原历史之后追加一个反向提交其他人 pull 下来只会多一个提交不会出现历史分叉和强制推送的问题。revert 的典型场景是你合并了功能分支到主分支后来发现功能有严重 bug需要把整个合并撤回。你不用去 revert 功能分支上的每个提交只需要 revert 那个合并提交即可但需要指定主提交线git revert -m 1 合并提交哈希-m 1 表示保留哪一边的历史作为主线。这个参数刚接触时容易搞混我的理解方式是执行 revert 合并提交时让 Git 保留主分支的内容为基准把合并引入的改动反向撤销。多数情况下主线就是主分支所以 -m 1 指向被合并到的那一侧。5.4 git cherry-pick挑拣提交到当前分支cherry-pick 是一个复制提交命令它把某个提交产生的改动应用到当前分支上生成一个新提交。git cherry-pick 提交哈希这个命令的实用场景非常明确你在另一个分支上改了某个 bug而这个分支短时间合并不过来但当前分支又急着需要这个修复。那就 cherry-pick把这个修复单独拉过来。它不关心两个分支之间有多少差异只关心能不能把目标提交的变更应用到当前代码上如果发生冲突就按冲突解决流程处理即可。不过 cherry-pick 也有代价——它复制的是改动不是语义。被摘抄的那个提交可能依赖其他提交的代码在你当前分支并没有摘过来之后编译都不一定能通过。所以 cherry-pick 之后一定要运行测试别想当然地认为提交是好的就一定能直接落。5.5 git stash临时存档未提交的改动stash 是临时存起来的意思适用于你正在改代码但突然需要切换到另一个分支干别的活、又不想把改了一半的代码提交出去的场景。git stash # 把当前工作区以及暂存区的改动暂存恢复干净状态 git stash save 描述信息 # 暂存并写一点备注 git stash list # 查看暂存列表 git stash pop # 取出最近一次暂存并应用 git stash apply stash{2} # 应用指定暂存但不删除stash 列表可以存很多份就像衣柜里挂了很多件外套。pop 是取出来并脱掉挂着的apply 是取出来但还挂着。如果切换回分支后之前暂存的改动已经不需要了还可以git stash drop stash{0} # 删除指定暂存 git stash clear # 清空所有暂存我一般把 stash 当作短期的临时口袋不会在里面存放超过一天的东西。如果要长期保留一批改动宁可开一个分支把改动提交到那个分支上也比 stash 堆在列表里靠谱。毕竟 stash 列表里放太久没人管连当初为什么存都想不起来清理的时候还担心误删。6. 让 Git 更顺手配置、别名与工作流增强到了这一步基础命令的覆盖已经完成了。但坦白讲真正让人工作效率拉开差距的往往不是会不会那些命令而是会不会把工具调整成适合自己的形态。这一节讲几个能长期提升日常体验的 Git 技能。6.1 全局配置与常用选项Git 的配置层级从高到低分别是系统级、全局级、仓库级。同一个配置项仓库级优先级最高。用以下命令查看和修改git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global core.editor vim git config --global color.ui autocore.editor 会影响 git commit 打开编辑器编辑提交信息、git rebase -i 打开交互界面的行为。你要是平时用 VS Code把它配成 code --wait 也可以。不过注意交互式 rebase 是纯命令行文本界面我还是建议保留一个顺手的终端编辑器而不要把图形化编辑器作为 Git 的默认编辑器。另有一个配置我建议每个开发者都设置git config --global pull.rebase true这个配置的意思是把 git pull 的行为从默认 merge 变成 rebase拉取远程更新时不是产生一个合并节点而是把你的本地提交移植到远程最新提交之上保持历史线性。我之前提到团队要统一如果你的团队不排斥线性历史这个配置值得开。6.2 git alias把常用命令变成短命令alias 是 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.unstage reset HEAD -- git config --global alias.lg log --oneline --graph --decorate配置完之后git co 就是 git checkoutgit lg 就是漂亮的历史图。我自己的 alias 列表里除了上面这些还有git config --global alias.last log -1 HEAD --stat git config --global alias.ac !git add -A git commit -malias 对提升日常效率很有帮助但有一点我会提醒别把 alias 写成跟标准命令混淆的名字也别在一个团队里依赖自己独有的 alias 去指导别人操作。新同事看到你说敲一下 git co如果他没有这个 alias执行 git co 会报错你得解释清楚。所以 alias 是个人效率工具不是团队协作规范。6.3 利用 reflog 找回丢失的提交git reflog 是我眼中被严重低估的救命命令。它记录的是 HEAD 指针在本地仓库里每一次移动的日志。这意味着即便你用 reset --hard 回退到了一个旧提交只要 reflog 里还有记录它就能帮你找到丢弃前的位置。git reflog输出大概长这样每一行包含一个哈希、HEAD 的位置变化、以及当时操作的描述。如果你误删了分支或者 reset 掉了提交可以通过 reflog 找到原来提交的哈希然后 git cherry-pick 或者 git reset 回那个状态。有一次我误删了一个还没合并的功能分支刚开始真的吓一跳后来想到 reflog找到了分支最后指向的提交哈希重新用 git branch 恢复有惊无险。这个工具我真的建议所有 Git 使用者都了解一下它就是你操作错误的保险丝。不要嫌弃它的输出难看关键时刻能救命。6.4 子模块与工作树的管理遇到主体仓库依赖多个独立仓库的情况Git 提供子模块机制来管理这种关联。deep dive 的做法是用 git submodule它允许在一个仓库里引用另一个仓库的特定提交并在 clone 主仓库时按需拉取子模块内容。git submodule add 子模块地址 子模块路径 git submodule update --init --recursive子模块最常见的问题是我明明 clone 下来了子模块目录却是空的。这多数是因为 clone 时没有加 --recurse-submodules或者更新子模块时没有加 --init。它的学习曲线确实陡我自己的建议是子模块适合组合关系稳定、版本同步要求明确的场景如果你的依赖很频繁变动用包管理器往往比子模块更合适。工作树机制同样值得一提git worktree add 新路径 分支名它允许你从同一个仓库检出多个工作目录每个工作目录可以对应不同分支。这个命令最大的价值是你不用反复 stash、切换分支可以在不影响主工作区的前提下同时打开一个新目录开发另一个分支的代码。我自己在同时修两个独立 bug 时常用这个一个工作树对应一个 bug互不干扰。7. 日常问题排查与避坑记录写完前面的内容我忍不住想把自己实际踩过的坑、排查过的典型问题整理一份速查表。这些经验大部分是文档里不太容易看到的但往往就是这些细节决定了你的 Git 用起来顺不顺手。7.1 分支名与大小写问题在很多协作场景中分支名大小写引发的混乱很常见。Windows 和 macOS 的文件系统默认大小写不敏感Linux 则敏感这可能导致你在一个平台创建了 feature/Login 分支在另一个平台 checkout 的时候 Git 却匹配到了 feature/login。结果就是改动提交到了一个看起来一样但实际不同的分支上。我的处理办法是约定分支名一律小写中间用连字符或斜杠分段。加一条 pre-push 钩子检查分支名是否含大写字母也可以但更重要的是团队规范写清楚。7.2 .gitignore 失效为什么忽略规则没生效一个出现频率很高的困惑是明明在 .gitignore 里写了 ignore 规则文件却仍然出现在 git status 里。原因多半是这个文件已经被 Git 跟踪了——.gitignore 只对未跟踪的文件生效已跟踪文件的忽略规则不会起作用。解决问题的方法是先把文件从 Git 的跟踪中移除保留本地文件git rm --cached 文件名或路径然后重新 add、commit。这样之后 .gitignore 的规则才能真正拦住这个文件。如果 .gitignore 写了但还是没效果也可能是规则写得有问题。比如你写了 target/ 却没有开头的斜杠在某些场景下它可能匹配不到预期的目录。Git 的 ignore 规则一条条排下来后面的优先级低于前面的吗不是是最近匹配的规则生效。可以用 git check-ignore 来验证某个文件究竟被哪条规则匹配了git check-ignore -v 文件名这个命令会打印出匹配到该文件的 .gitignore 规则及行号排查效率高很多。7.3 误操作的恢复思路汇总我把几个高频误操作和恢复方式整理成了一张表建议你收藏起来对照着用场景推荐命令备注改了文件但还没 add想撤销改动git restore 文件名不可逆先确认工作别丢add 了但还没 commit想取消暂存git restore --staged 文件名内容保留安全commit 了但还没推远端想修信息git commit --amend不改变历史大体结构commit 了还没推远端想拆成多个提交git reset --mixed HEAD~1回到暂存前状态已经推远端想撤销这次提交git revert 提交哈希共享分支首选误删分支想找回git reflog 找到哈希后 git branch 恢复及时操作过期会被清理改到一半要切分支又不想提交git stash / git stash pop短期使用别长期堆积想彻底丢弃某次提交的所有改动git reset --hard 提交哈希极度危险操作前备份或确认这张表我贴在自己笔记里遇到紧急情况直接查不会因为紧张用错命令。7.4 git bisect二分定位问题的利器最后压轴的我想推荐 git bisect。这是一个容易被忽略但实际效率极高的排查工具。它通过每一步平分提交区间的方式帮你自动定位出哪个提交引入了某个问题。用法是这样告诉 Git 一个已知有问题的提交和一个已知正常的提交然后对每个中间提交做检测告诉 Git 这个提交是好还是坏。Git 会在多轮检测后收敛到一个引入问题的提交。git bisect start git bisect bad # 当前提交是有问题的 git bisect good 某个正常提交的哈希 git bisect good # 检测后如果提交正常就标 good git bisect bad # 如果提交有问题就标 bad git bisect reset # 结束二分回到最初分支假设你怀疑问题在最近 30 个提交里引入用 bisect 最多只要进行 5 次检测就能定位这是二分查找的效率。虽然每次检测可能要编译、运行程序但比起一个人漫无目的地翻提交历史效率提升是非常可观的。有一个关键技巧在 bisect 过程中要用一个尽量自动化的脚本来判断这个提交是好是坏。比如你有测试命令直接git bisect run 你的测试命令它会自动跑测试根据退出码来判断好坏等于全自动定位。我有一回排查性能回归用 git bisect run 一段压测脚本半小时就把引入问题的提交锁定了。而这个提交可能在 200 多个提交之前——手动查的话基本上是一整天的工作量。7.5 关于 Git 使用的最后几条经验说了这么多最后分享几条我在实际使用中总结的体会。第一条是远程分支上的历史能不动就不动。重塑历史之前多想想队友会不会被打乱。生活的经验是自己怎么折腾没人管动了别人的东西就要承担责任。Git 也一样本地提交随便整理推送到共享分支之后就要克制。第二条是提交之前先看一眼 diff。git diff --stat 加 git diff 的时间成本很小但可以帮你拦截误提交敏感信息、把调试代码带进去等常见问题。我见过有人在代码里留了数据库连接信息然后提交推上去的如果他养成先看 diff 的习惯这种事就很难发生。第三条是识别命令的不可逆性。我已经强调了多次git reset --hard、git restore 这种破坏性操作是不可逆的。在做这些操作之前花几秒钟想一想我是否真的需要放弃这些改动或者直接先 git stash、git branch 备份当前状态几秒钟的额外操作能避免很大的麻烦。第四条是关于学习不要背命令要理解命令背后的状态变化。Git 的本质是文件快照、引用、提交图之间的指针操作理解了这个模型你会发现命令的选择和参数数量根本不是靠背的而是逻辑推导的结果。Git 的复杂度从来不在于命令多而在于你脑子里能不能建立正确的心智模型。从 2026 年回看Git 的地位依然稳固。它不是最好用的版本管理工具但却是整个生态的基石。不管未来出现什么新的工具和协议掌握好 Git 命令的核心逻辑依然是一项不过期的能力。希望这篇梳理能帮你在日常开发中少踩几个坑多省一些时间。
