1. 别把 Git 只当“代码备份工具”用过去几年我面过不少人简历上写着“熟练使用 Git”结果一聊发现大部分人所谓的“会用”就是git add、git commit、git push三板斧遇到冲突就慌分支模型说不清更别提rebase、cherry-pick、reflog这些稍微进阶一点的操作。说实话这不怪大家因为多数教程只教“怎么把代码传上去”没教“怎么把版本管理这件事件做好”。Git 本质上不是备份工具而是一个分布式版本控制系统。它解决的最大问题不是“代码丢了怎么办”而是“多人协作时如何让每个人的改动有序地汇入主线同时还能追溯每一次变更的理由”。你提交的每一个 commit、写的每一条 message、切出去的每一个分支都在给团队其他成员传递信息。所以 Git 用得好不好直接决定你是一个“能配合队友的人”还是一个“每天都在制造冲突的人”。这篇小结我整理了从安装配置到日常高频命令再到那些年我踩过的坑和排查技巧。不管你是刚接触 Git 的新手还是已经用了两三年但总觉得差点意思的开发者这篇文章应该都能帮你把一些模糊的概念补扎实。我尽量用实际场景来讲而不是念命令手册。2. 安装和初始化配置一次配好后面不折腾2.1 各平台安装 Git 的几种方式Git 的安装在 Windows、macOS、Linux 上思路不太一样我分别说下我最常用的做法。Windows 用户直接去 Git 官网下载安装包一路点下一步就行。但有两个选项值得注意一是安装时选择 Git Bash 作为默认终端二是换行符转换那里选“Checkout as-is, commit as-is”这样能避免 Windows 和 Linux 之间因为 CRLF/LF 差异产生的大量虚假 diff。装完之后在命令行里敲git --version能看到版本号就说明装好了。macOS 用户系统自带一个很老的 Git建议直接brew install git装完是当前最新稳定版。需要 Xcode Command Line Tools 时系统会自动弹窗提示同意就行。Linux 用户Debian/Ubuntu 系用sudo apt install gitCentOS/RHEL 系用sudo yum install git。如果系统源里的版本太老可以加 Git 官方 PPA 或用源码编译安装但一般没必要。提示装完第一个动作不是建仓库而是配身份信息。Git 的每一个 commit 都会记录作者姓名和邮箱如果不配提交时会提示一堆红色错误而且后续代码评审根本不知道谁改的。2.2 必配的全局参数直接在终端执行这两条命令git config --global user.name 你的名字 git config --global user.email 你的邮箱名字建议用真实姓名或团队内统一的花名邮箱建议用公司邮箱或 GitHub 邮箱。这里有个小坑如果用了隐私保护邮箱GitHub 会生成一个类似xxxxxusers.noreply.github.com的地址你本地配置时要保持一致不然提交记录上的头像和账号对不上。接着推荐开启几个让日常操作更顺手的配置git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath false git config --global pull.rebase true git config --global rerere.enabled trueinit.defaultBranch main是把新建仓库的默认分支名设为main而不是旧版的master现在 GitHub 和 GitLab 新仓库默认也都是main保持一致能少踩很多坑。core.autocrlf input在 macOS/Linux 上能避免换行符被误转换。core.quotepath false非常关键它让中文文件名正常显示而不是变成一堆转义过的八进制编码。pull.rebase true让git pull默认用 rebase 方式合并远端更新后面我会详细讲为什么这么做。rerere的全称是 “reuse recorded resolution”开启后 Git 会记住你解决过的冲突方式下次同样的冲突自动帮你合并这个功能用久了真的会上瘾。2.3 配置 SSH 免密连接每次 push 都输密码会让人怀疑人生所以配 SSH key 几乎是必修课。检查是否已有 keyls -al ~/.ssh如果没看到id_rsa.pub或id_ed25519.pub先生成一个ssh-keygen -t ed25519 -C 你的邮箱一路回车会在~/.ssh下生成一对公私钥。然后把id_ed25519.pub的内容加到 GitHub/GitLab 的 SSH keys 里。最后验证ssh -T gitgithub.com看到Hi xxx! Youve successfully authenticated就说明通了。这里一个经验之谈如果公司 GitLab 和 GitHub 需要不同的 SSH key不要用同一个私钥而是去~/.ssh/config里按域名指定不同的 key 文件必要时还可以指定不同用户名。这个配置文件能解决很多“同一个电脑要连多个 Git 服务器”的问题。3. 日常高频命令把工作流跑顺再说其他3.1 每天必用的基本操作链路一个标准的单人开发推送流程其实只用五个命令git status git add . git commit -m feat: 完成用户登录模块的接口对接 git pull --rebase git pushgit status先看当前工作区状态确认哪些文件改了、哪些还没跟踪。git add把改动加入暂存区git commit把暂存区内容固化成一次提交。git pull --rebase在推送前先拉取远端更新如果有新提交把本地提交变基到远端最新提交之后。git push推送到远端。这条链路里我最想强调的是git pull --rebase。默认的git pull是 merge 方式它会产生一个多余的“Merge branch xxx of xxx”提交时间长了历史图里全是分叉和汇合特别难看。而 rebase 方式会让你的提交干净地排列在远端提交之后历史是一条直线回溯排查时体验完全不一样。很多人不敢用 rebase因为觉得它会“改写历史”。实际上你只 rebase 自己还没推送的本地提交是安全的。推送过的提交就不要再去 rebase 了那是给自己和队友找麻烦。3.2 分支操作创建、切换、删除与合并分支是 Git 最核心的优势之一用好了能极大提升协作效率。git branch feature-login # 创建分支 git checkout feature-login # 切换分支 git checkout -b feature-login # 创建并切换最常用 git branch -d feature-login # 删除分支已合并的 git branch -D feature-login # 强制删除未合并的合并分支有两种方式merge 和 rebase。我通常的做法是功能分支开发完、测试通过后切回主分支执行git merge feature-login。如果主分支没有新提交它会走 fast-forward 模式历史干净。如果主分支有更新就会产生一个合并提交这是合理的因为功能周期长、合并点本身就是一次有意义的记录。但如果你只是在修一个很小的 bug我倾向于用 rebase 把修复提交整理成一个干净的点让主分支历史更线性。什么时候用 merge、什么时候用 rebase没有绝对标准核心原则是团队约定优先别混用。一个项目里有的人 merge 有的人 rebase历史会乱成一团。3.3 撤销与回退真实世界的后悔药这是 Git 使用中信息量最大的一块。误操作不可怕可怕的是不知道怎么救回来。改错了还没 commitgit checkout -- 文件名可以丢弃工作区修改但这是不可恢复的执行前想清楚。更好的做法是用git stash把当前改动暂存起来之后git stash pop可以恢复相当于给你的修改买了个保险。commit 信息写错了git commit --amend可以修改最近一次提交的信息。注意这只适合还没推送的提交如果已经 push 了不要 amend那样会导致远端和本地历史不一致。commit 提交后发现漏了文件git add 漏掉的文件再git commit --amend --no-edit--no-edit表示不修改提交信息直接把漏掉的文件补进上一次提交里。commit 提交错了要回退分两种情况。git reset --soft HEAD~1 # 撤销 commit保留工作区改动 git reset --hard HEAD~1 # 撤销 commit丢弃工作区改动--soft适合“提交太早还想再改改”的场景。--hard适合“这次提交完全不要了”的场景但--hard有风险执行前最好用git log确认你要回到的版本号没有打错。已经推送了不小心 reset用git revert commit-id生成一个反向提交把错误提交的改动撤掉同时保留历史记录。revert 是安全的远程回退方式不会改写远端已有历史。注意git reset和git revert的核心区别在于reset 是“移动指针”适合本地回退revert 是“生成新提交抵消旧提交”适合远程回退。团队协作时尽量不要对已推送的提交做 reset否则队友 pull 的时候会撞上一堆诡异冲突。4. 我看过很多人把 .gitignore 写错4.1 .gitignore 的作用范围与匹配规则.gitignore是用来告诉 Git 哪些文件不应该被跟踪的。常见的是编译产物、依赖目录、本地配置、日志文件等。它的匹配规则比想象中简单# 忽略任意目录下的 node_modules node_modules/ # 忽略所有 .log 文件 *.log # 忽略 build 目录下的所有内容但保留该目录本身 build/ # 忽略 config 目录下的 local.js但不影响其他文件 config/local.js # 不忽略 config/prod.js前面有 ! 表示取反 !config/prod.js这里有个容易踩的坑如果一个文件已经被 Git 跟踪了那么你再在.gitignore里写它也没用。因为 Git 的跟踪状态是“已经纳入版本管理”.gitignore只对未跟踪文件生效。解决办法是git rm --cached 文件名--cached的意思是“从版本控制中移除但保留本地文件”执行完再 commit 一次这个文件就被“遗忘”了之后.gitignore里的规则才开始生效。4.2 常见该忽略和不该忽略的文件最常见的该忽略文件Node.js 项目的node_modules/、Java 项目的target/、Python 项目的__pycache__/、IDE 配置.idea/和.vscode/、日志文件*.log、环境变量.env。其中.env尤其重要里面通常有密钥和数据库密码一旦提交到远端仓库再撤回密钥就等于泄露了必须去服务商那边重新生成。不该忽略的典型例子是package-lock.json和yarn.lock。这两个文件锁定了所有依赖的精确版本号是团队环境一致的保障必须提交进去。我见过有团队一开始把 lock 文件加到.gitignore结果每个人装出来的依赖版本都不一样线上 bug 排查了半天才发现是依赖不一致。4.3 全局忽略规则与模板不同项目有各自的忽略需求但有些文件是无论什么项目都不该提交的比如.DS_StoremacOS 的文件夹元数据、Thumbs.dbWindows 缩略图缓存、.vscode/下的个人配置。这时可以配置一个全局.gitignoregit config --global core.excludesfile ~/.gitignore_global然后把通用规则写进~/.gitignore_global里以后所有项目都自动生效每个项目的.gitignore只需要管项目特有的文件。我见过不少开发者的做法是直接从 GitHub 的 gitignore 仓库拷贝模板这个习惯很好但要注意模板是面向通用场景的你还是要根据自己的项目结构再补充几条个性化的忽略规则比如“我这款应用有个特殊的资源目录里面的是构建产物不能被提交”这种只有自己清楚。5. 那些看起来像“黑魔法”的命令其实很有用5.1 git log 的一些高级用法git log不只是看历史列表用好它能极大提升排查效率。git log --oneline --graph --all --decorate这条命令以图形方式展示所有分支的提交历史每个提交只显示一行带上分支标签和 HEAD 位置。排查问题时我第一反应就是跑这条命令比看一堆密密麻麻的裸 log 直观得多。按作者和关键词过滤git log --author张三 git log --grepfix bug git log --since2024-01-01 --until2024-06-01看某个文件的完整修改历史git log -p -- 文件路径-p会把每次提交的具体改动内容也展示出来定位“这个文件是哪次提交改坏的”非常高效。5.2 git stash临时切换分支的救星场景你正在feature-a分支上写着代码突然线上有个紧急 bug 需要切到master分支修复。但当前改动还没写完直接切换分支会把半成品带过去或者因为冲突切不过去。这时候用 stashgit stash # 暂存当前工作区的改动 git checkout master # 切到 master 修复 bug git branch hotfix-xxx # 开个分支修 # ...修复完成、提交、合并... git checkout feature-a # 回到原来分支 git stash pop # 恢复暂存的改动stash本质是把工作区和暂存区的改动打包存到一个栈里pop时按后进先出的顺序恢复。它还支持git stash list查看所有暂存项git stash apply stash{1}恢复指定的暂存项。这里有个实用技巧如果暂存的改动和新分支的代码有冲突pop 的时候会像 merge 一样提示冲突。此时不要慌按冲突解决的流程处理即可stash 里的原始改动在你解决完冲突之前都还在可以放心动手。5.3 git cherry-pick精准搬运提交如果你只想把别的分支上的某一次提交拿过来而不是把整个分支合并过来用cherry-pick。git cherry-pick commit-id典型场景master分支提交了一个紧急修复release-2024分支也需要这个修复但不能直接把master全部合并到release里会带来一堆不想要的改动。这时候git cherry-pick那个修复提交的 commit-id 就行。需要注意cherry-pick会把提交“复制”到当前分支产生一个新的 commit-id。如果后续原提交被 amend 了或者你 pick 的提交和当前分支内容有冲突处理方式跟普通冲突一样。5.4 git reflog最后的救命稻草git reflog是本地的“操作日志”记录了所有 HEAD 指针的移动轨迹。哪怕你误操作git reset --hard丢了一个提交reflog里也能找到那个提交的 hash把它恢复回来。git reflog输出会显示类似HEAD{0}: reset: moving to HEAD~2的记录每一条代表一次 HEAD 移动。找到你想要恢复的提交 hash执行git reset --hard hash就能回到那个状态。reflog默认保留 90 天的记录所以“误删提交”在 Git 里基本不存在只要你没把.git目录删了几乎所有操作都可以撤销。经验心得我在带新人时经常说Git 的恢复能力比大多数人想象中强得多。滥用--hard确实有风险但只要你有reflog这个兜底绝大多数误操作都能救回来。真正危险的其实是你清空.git目录或者用git gc手动清理对象日常操作很难造成不可逆的灾难。6. 合代码时的冲突我一般这样处理6.1 冲突是怎么产生的冲突的本质是两个分支修改了同一段代码的相同位置。Git 擅长合并互不干扰的改动比如一个改了文件头一个改了文件尾但无法自动判断“同一行到底以谁的为准”于是只能把决定的权力交还给人。举个例子你和同事都在改config.js的port字段。你把 3000 改成 8080同事把 3000 改成 9090。合并时 Git 看到两个分支对同一行做了不同修改它就抛出一个冲突。这不是 Git 的缺陷而是它诚实地告诉你“我不知道你们俩谁对”。6.2 解决冲突的完整流程第一步执行合并或 rebase 命令后Git 会提示冲突文件。用git status查看哪些文件处于both modified状态。第二步打开冲突文件会看到类似这样的标记 HEAD const port 8080; const port 9090; feature-config HEAD到之间是当前分支的内容到 feature-config之间是另一个分支的内容。你需要手动决定保留哪个、删掉哪个或者改成一个两个都不一样的版本。在我看来最理想的情况是“这段代码既不是你的也不是他的而是两个人的需求合并后的最优解”。第三步解决完所有冲突标记后保存文件执行git add 冲突文件 git commit # merge 场景生成合并提交 # 或者 git rebase --continue # rebase 场景这里有一个新手容易犯的错直接删掉冲突标记里的一边内容就算完事了但两边代码可能都不是完整方案可能两边都要保留一部分。正确做法是读完两边的逻辑理解各自目的再写出兼容的新代码。6.3 减少冲突的几个好习惯冲突无法完全避免但可以大幅减少。第一小步提交频繁同步。一个功能分支不要憋两周不 push尽量拆成几个小提交每完成一个能编译能跑的小目标就推一次。你在本地改得越久和主线的偏差就越大合并时冲突概率越高。第二尽量用 rebase 更新分支。在功能分支上执行git fetch origin main再git rebase origin/main能让你的提交始终基于主线最新代码。虽然每次 rebase 可能遇到连续冲突但解决一次之后后续的都顺了比最后一次性合并时面对密密麻麻的冲突要轻松得多。第三统一格式化和 lint 规则。很多冲突不是因为逻辑不一致而是因为格式化工具把整行代码重排了导致 Git 认为“整个文件都改了”。用 ESLint、Prettier 等工具统一风格并在.editorconfig里固定缩进和换行符能从源头上消除一类假冲突。7. push 被拒绝和“鬼打墙”般的文件差异7.1 push 被拒绝的几种原因与应对git push失败是最常见的报错之一。最常见的提示是“! [rejected] main - main (non-fast-forward)”。原因很简单远端分支上有你本地还没有的提交而 Git 不允许你直接“覆盖”远端历史。解决办法是先拉取远端更新再把本地提交并上去。git fetch origin git rebase origin/main git push我用fetch rebase push这套组合比直接git pull --rebase更稳妥因为fetch只是把远端状态拉到本地不修改工作区你可以先看看git log origin/main确认远端到底多了哪些提交再决定怎么处理。如果你确定要用本地版本完全覆盖远端通常是刚初始化或测试分支可以强制推送git push -f origin main但强制推送会重写远端历史协同分支上绝对不要用。有几次我在个人项目上用了-f后面想找回旧提交也费了好大劲现在除非万不得已我都用git push --force-with-lease而不是裸的-f。--force-with-lease会检查远端是否有别人推送的新提交如果有就拒绝推送相当于“有条件的强推”安全得多。7.2 文件差异“异常”的排查思路遇到“我只改了一行但 Git 显示这个文件有几百行差异”的情况八成是换行符问题。Windows 下 Git 默认把 CRLF 转成 LF 写入仓库checkout 时再转回 CRLF但如果你之前的文件是以 CRLF 形式提交入库的后面换了.gitattributes或 autocrlf 配置Git 会认为整个文件都变了。解决办法是在仓库根目录加一个.gitattributes文件明确指定换行符规则* textauto *.sh text eollf *.bat text eolcrlf.gitattributes是比core.autocrlf更推荐的做法因为它是跟随仓库走的团队每个人拉下来规则一致不依赖个人本机配置。还有一种“鬼打墙”情况是明明删除了某个文件但git status里它还是显示为已修改重新git add后 commit 又提示“nothing to commit”。这多半是该文件既是符号链接又指向了不存在的目标或者文件权限位改了但内容没改。这时候用git config --global core.filemode false把文件权限变更从 diff 里忽略掉能省掉大量无意义的 diff。7.3 那些奇怪的“-c”前缀命令是什么最近热搜里有人问git -c diff.mnemonicPrefixfalse -c core.quotepathfalse --no-optional-locks是什么。我在本地也踩到过类似的命令这其实是从某些 IDE 或 CI 工具里复制出来的 Git 调用它不是普通用户日常手敲的命令而是工具内部为了让输出更稳定、报告更规范而附加的全局选项。拆开看-c diff.mnemonicPrefixfalse关闭 diff 输出中的字母前缀如a/、b/这类符号让 diff 输出的文件名更直白。-c core.quotepathfalse让中文和特殊字符的文件名正常显示不转义成八进制。这个我之前也提到过对中文用户特别实用。--no-optional-locks告诉 Git 这次操作不要创建或刷新一些可选锁文件避免在后台运行时干扰正在进行的其他 Git 操作。如果你在 GitHub Actions 之类的 CI 日志或某些脚本里看到这种命令说明工具的开发者希望 Git 输出更干净、行为更可控。它本身不是一条需要手动学习的“魔法命令”核心价值在于展示了 Git 强大的“命令行内配置”能力——所有git config能设置的项基本都能用-c keyvalue的形式附加在单条命令上不修改全局配置。这个用法在写脚本时尤其有用。比如你临时需要在一个老仓库里提交但不想改全局用户名git -c user.name临时工 -c user.emailtempexample.com commit -m 临时提交命令跑完不影响全局配置ansi非常便捷。8. 分支管理规范是团队协作的隐形契约8.1 推荐一套简单可落地的分支模型我看过很多团队的分支策略复杂的如 Git Flow有master、develop、release、hotfix、feature五种分支适合大型项目和严格发版流程。但对大多数中小团队来说这套模型偏重落地起来维护成本高。我更推荐基于主干开发的简化模型main主分支长期存在始终处于可发布状态。feature/*功能分支从main拉出开发完成合回main。bugfix/*修复分支从main拉出修完合回main。release/*可选从main拉出用于发布前的最后测试和版本号调整。这套模型的核心是功能分支生命周期短尽量 3 天以内合回主分支。功能分支不要直接碰main而是通过 Merge Request / Pull Request 来做利用平台的代码评审和 CI 检查再合入。我见过不少团队规则很松大家直接在main上拉新分支又直接往mainpush结果主分支经常处于不可编译状态一发版就手忙脚乱。8.2 合并策略merge、squash、rebase 选哪个大多数代码托管平台GitHub / GitLab在合入 MR/PR 时提供三种合并方式我在实际工作中根据场景不同会这样选合并方式历史形态适用场景Merge Commit保留所有中间提交历史完整功能周期长、希望保留每个开发节点的场景Squash and Merge所有提交压缩成一个提交功能分支提交很碎、希望主分支历史干净Rebase and Merge按时间顺序重放提交历史线性冲突少、追求直线历史的场景个人建议默认用 Squash and Merge。理由很简单功能分支上那些 “WIP”work in progress、“fix typo”、“update” 之类的提交对后来的读者没有意义一条功能一条提交反而清晰。但如果你在做开源项目维护者更倾向 merge commit 以保留每个贡献者的提交痕迹所以看项目文化和平台约定。8.3 Commit Message 的写法和规范commit message 不是给自己看的是给未来的自己和同事看的。我见过太多“update”、 “fix”、 “修改”这种毫无信息量的提交说明过两周回头查问题根本不知道这次提交改了什么。推荐用 Conventional Commits 风格type(scope): subject body常见 type 有feat新功能fix修 bugdocs文档变更style格式调整不影响代码逻辑refactor重构不改变功能test补充测试chore构建或辅助工具变动scope 是可选的模块名比如feat(login): 添加记住密码功能。subject 用祈使句简洁明了不超过 50 个字符。如果改动复杂还可以在提交信息里加 body 段落说明背景和影响但我在实践中发现绝大多数 commit 不需要 body一行 subject 就够了需要背景信息时写在 MR 描述里更合适。注意commit message 风格最忌讳一两个人觉得好就拍板要求全团队执行。强制规范之前最好先在团队里拉一次会议对齐版本、约定和工具链commitlint、husky 等让所有人都觉得“这是大家的约定”而不是“某个领导定的规矩”落地阻力会小很多。9. 那些让人抓狂的疑难杂症排查9.1 误删分支如何恢复场景你执行了git branch -D feature-login一瞬间分支“没了”。但别慌分支本质只是一个指向提交的指针你删除的只是指针被指向的提交对象依然在对象库里。用git reflog找到删除前分支指向的最后一个 commit hash然后git branch feature-login hash分支就回来了。所以我的习惯是在reflog里有记录的前提下禁用git gc --prunenow这种强制清理命令给所有误操作留退路。9.2 误提交了敏感信息怎么办这是最严重的事故之一。如果你把密钥、密码、云服务 token 提交到了远端仓库第一步不是git rm再提交因为 Git 历史里已经永久保留了旧版本任何能访问仓库的人都能翻出来。正确应对步骤立刻去对应服务商平台轮换密钥/密码让旧凭证失效。在本地历史里清除敏感信息推荐用git filter-repo而不是历史版本的filter-branch后者又慢又容易出问题。强制推送清理后的历史并告知所有协作者重新克隆。如果仓库是公开的还要考虑联系平台客服看是否能清除缓存和派生仓库的引用。预防同样重要提交前用git diff检查暂存内容或接入 pre-commit 钩子配合 gitleaks 这类工具扫描敏感信息把风险挡在 push 之前。我至今还留着一个教训那次误提交 .env 文件之后我上线了什么检查都先扫一遍再也不敢靠肉眼判断了。9.3 Git 卡在某个操作上或文件锁死Git 偶尔会报index.lock相关错误说明另一个 Git 进程还在跑或者上次操作意外中断导致锁文件残留。解决办法很简单删掉这个锁文件。rm .git/index.lock遇到Unable to create .../.git/index.lock时先确认没有其他 Git 进程在跑比如 IDE 自动操作再删除锁文件。我一般会用ps aux | grep git看一眼确认没有后台命令在跑再删避免误伤正在进行的正常操作。还有一种常见卡顿是git push突然没反应多半是网络代理问题。可以试试git config --global --unset http.proxy git config --global --unset https.proxy或者反过来如果你处于需要使用代理的网络环境就检查代理配置是否正确。遇到这种网络类的疑难杂症先GIT_CURL_VERBOSE1 git push跑一次把 curl 的输出打出来能直接看到它到底连到哪个地址、卡在哪一步比瞎猜快得多。9.4 常见问题速查表问题直接原因推荐操作git push被拒绝远端有新提交git fetchgit rebasegit push提交后想改 message提交未推送git commit --amend误 reset 丢失提交本地指针移动git reflog找回 hash 再git reset --hard中文文件名乱码quotepath 未关闭git config --global core.quotepath false大量假 diffCRLF/LF 换行不一致建.gitattributes统一规则误删分支指针删除但对象还在git refloggit branch hash敏感信息泄露已进历史轮换凭证 git filter-repo 强推.gitignore不生效文件已被跟踪git rm --cached后再提交密码总是要输没配 SSH key生成 key 并加到平台10. 最后再分享几条长期实践下来的心得10.1 把 Git 命令“背下来”不如“理解对象模型”学 Git 最大的一个坎是思维方式。很多人把 Git 命令当成咒语在背换个场景就不知道怎么组合了。但如果你理解了 Git 的三层对象模型——工作区、暂存区、本地仓库、远端仓库——绝大多数命令就都能自己推导出来。所谓“暂存区”本质是“下一次提交的候选内容”“提交”本质是“把暂存区的内容打包成一个不可变的历史快照”“分支”本质是“指向某个提交的可移动指针”“HEAD”本质是“当前分支指针的位置”。带着这套理解再回去看add、commit、checkout、reset、merge你会发现它们都不过是在这几层之间搬运和修改引用。10.2 养成“小步提交、频繁提交”的习惯从前有个阶段我也喜欢憋一个大功能再一次性提交觉得这样提交历史“干净”。直到某次我改了两天代码最后发现第二步的设计方向就有问题但因为没有中间提交点我根本退不回去只能靠git diff一片一片地手工还原别提多痛苦了。从那以后我改成“每完成一个可以编译、可以跑通的小目标就提交一次”虽然历史里多了很多提交但每次回退、排查都精准多了。这个习惯还有个额外好处code review 时分而治之评审人可以按提交顺序理解你的实现思路而不是只看一个巨大的 diff 去猜。10.3 能用命令行就不点 IDE 按钮我知道很多新手喜欢在 IDE 里点 “Commit”“Push”“Sync” 这些图形化按钮因为看起来直观。但 IDE 的 Git 集成往往屏蔽了很多细节比如冲突标记、rebase 过程中的状态变化你以为点了按钮就成功了实际中间发生了很多你完全看不到的操作。等你哪天遇到复杂冲突IDE 的图形界面反而会让你更困惑。不是说 IDE 的 Git 功能不能用而是建议你先用命令行把所有高频操作跑熟练理解每一步背后发生了什么再回到 IDE 里做操作。两者结合才是效率最高的状态如果你连命令行都熟练了你会发现 IDE 里的报错和提示也不再那么“神秘”了。10.4 让工具帮你守规范人都会忘工具不会。团队里想推行 commit message 规范、分支命名规范、合并前必须跑测试就把它交给工具链去卡。常见的搭配是husky加commitlint检查提交信息lint-staged在提交前只对暂存文件跑 lintGitLab CI / GitHub Actions 在 MR 上跑全量测试所有检查过了才允许合入。这套东西搭起来花不了多少时间但对“低成本维护健康的仓库”来说收益是长期的。我见过太多团队靠“口头约定”维护规范三个月后仓库还是一样乱。Git 这个工具用了这么多年我最大的感受是它的上限远比表面看到的那些命令高得多但也正因为如此很多人在用完三板斧之后就停止了探索。希望这篇小结能帮你跨过那根从“会用”到“用好”的线后面的路你可以自己走。
Git 实战指南：从分布式版本控制到分支管理与冲突解决
1. 别把 Git 只当“代码备份工具”用过去几年我面过不少人简历上写着“熟练使用 Git”结果一聊发现大部分人所谓的“会用”就是git add、git commit、git push三板斧遇到冲突就慌分支模型说不清更别提rebase、cherry-pick、reflog这些稍微进阶一点的操作。说实话这不怪大家因为多数教程只教“怎么把代码传上去”没教“怎么把版本管理这件事件做好”。Git 本质上不是备份工具而是一个分布式版本控制系统。它解决的最大问题不是“代码丢了怎么办”而是“多人协作时如何让每个人的改动有序地汇入主线同时还能追溯每一次变更的理由”。你提交的每一个 commit、写的每一条 message、切出去的每一个分支都在给团队其他成员传递信息。所以 Git 用得好不好直接决定你是一个“能配合队友的人”还是一个“每天都在制造冲突的人”。这篇小结我整理了从安装配置到日常高频命令再到那些年我踩过的坑和排查技巧。不管你是刚接触 Git 的新手还是已经用了两三年但总觉得差点意思的开发者这篇文章应该都能帮你把一些模糊的概念补扎实。我尽量用实际场景来讲而不是念命令手册。2. 安装和初始化配置一次配好后面不折腾2.1 各平台安装 Git 的几种方式Git 的安装在 Windows、macOS、Linux 上思路不太一样我分别说下我最常用的做法。Windows 用户直接去 Git 官网下载安装包一路点下一步就行。但有两个选项值得注意一是安装时选择 Git Bash 作为默认终端二是换行符转换那里选“Checkout as-is, commit as-is”这样能避免 Windows 和 Linux 之间因为 CRLF/LF 差异产生的大量虚假 diff。装完之后在命令行里敲git --version能看到版本号就说明装好了。macOS 用户系统自带一个很老的 Git建议直接brew install git装完是当前最新稳定版。需要 Xcode Command Line Tools 时系统会自动弹窗提示同意就行。Linux 用户Debian/Ubuntu 系用sudo apt install gitCentOS/RHEL 系用sudo yum install git。如果系统源里的版本太老可以加 Git 官方 PPA 或用源码编译安装但一般没必要。提示装完第一个动作不是建仓库而是配身份信息。Git 的每一个 commit 都会记录作者姓名和邮箱如果不配提交时会提示一堆红色错误而且后续代码评审根本不知道谁改的。2.2 必配的全局参数直接在终端执行这两条命令git config --global user.name 你的名字 git config --global user.email 你的邮箱名字建议用真实姓名或团队内统一的花名邮箱建议用公司邮箱或 GitHub 邮箱。这里有个小坑如果用了隐私保护邮箱GitHub 会生成一个类似xxxxxusers.noreply.github.com的地址你本地配置时要保持一致不然提交记录上的头像和账号对不上。接着推荐开启几个让日常操作更顺手的配置git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath false git config --global pull.rebase true git config --global rerere.enabled trueinit.defaultBranch main是把新建仓库的默认分支名设为main而不是旧版的master现在 GitHub 和 GitLab 新仓库默认也都是main保持一致能少踩很多坑。core.autocrlf input在 macOS/Linux 上能避免换行符被误转换。core.quotepath false非常关键它让中文文件名正常显示而不是变成一堆转义过的八进制编码。pull.rebase true让git pull默认用 rebase 方式合并远端更新后面我会详细讲为什么这么做。rerere的全称是 “reuse recorded resolution”开启后 Git 会记住你解决过的冲突方式下次同样的冲突自动帮你合并这个功能用久了真的会上瘾。2.3 配置 SSH 免密连接每次 push 都输密码会让人怀疑人生所以配 SSH key 几乎是必修课。检查是否已有 keyls -al ~/.ssh如果没看到id_rsa.pub或id_ed25519.pub先生成一个ssh-keygen -t ed25519 -C 你的邮箱一路回车会在~/.ssh下生成一对公私钥。然后把id_ed25519.pub的内容加到 GitHub/GitLab 的 SSH keys 里。最后验证ssh -T gitgithub.com看到Hi xxx! Youve successfully authenticated就说明通了。这里一个经验之谈如果公司 GitLab 和 GitHub 需要不同的 SSH key不要用同一个私钥而是去~/.ssh/config里按域名指定不同的 key 文件必要时还可以指定不同用户名。这个配置文件能解决很多“同一个电脑要连多个 Git 服务器”的问题。3. 日常高频命令把工作流跑顺再说其他3.1 每天必用的基本操作链路一个标准的单人开发推送流程其实只用五个命令git status git add . git commit -m feat: 完成用户登录模块的接口对接 git pull --rebase git pushgit status先看当前工作区状态确认哪些文件改了、哪些还没跟踪。git add把改动加入暂存区git commit把暂存区内容固化成一次提交。git pull --rebase在推送前先拉取远端更新如果有新提交把本地提交变基到远端最新提交之后。git push推送到远端。这条链路里我最想强调的是git pull --rebase。默认的git pull是 merge 方式它会产生一个多余的“Merge branch xxx of xxx”提交时间长了历史图里全是分叉和汇合特别难看。而 rebase 方式会让你的提交干净地排列在远端提交之后历史是一条直线回溯排查时体验完全不一样。很多人不敢用 rebase因为觉得它会“改写历史”。实际上你只 rebase 自己还没推送的本地提交是安全的。推送过的提交就不要再去 rebase 了那是给自己和队友找麻烦。3.2 分支操作创建、切换、删除与合并分支是 Git 最核心的优势之一用好了能极大提升协作效率。git branch feature-login # 创建分支 git checkout feature-login # 切换分支 git checkout -b feature-login # 创建并切换最常用 git branch -d feature-login # 删除分支已合并的 git branch -D feature-login # 强制删除未合并的合并分支有两种方式merge 和 rebase。我通常的做法是功能分支开发完、测试通过后切回主分支执行git merge feature-login。如果主分支没有新提交它会走 fast-forward 模式历史干净。如果主分支有更新就会产生一个合并提交这是合理的因为功能周期长、合并点本身就是一次有意义的记录。但如果你只是在修一个很小的 bug我倾向于用 rebase 把修复提交整理成一个干净的点让主分支历史更线性。什么时候用 merge、什么时候用 rebase没有绝对标准核心原则是团队约定优先别混用。一个项目里有的人 merge 有的人 rebase历史会乱成一团。3.3 撤销与回退真实世界的后悔药这是 Git 使用中信息量最大的一块。误操作不可怕可怕的是不知道怎么救回来。改错了还没 commitgit checkout -- 文件名可以丢弃工作区修改但这是不可恢复的执行前想清楚。更好的做法是用git stash把当前改动暂存起来之后git stash pop可以恢复相当于给你的修改买了个保险。commit 信息写错了git commit --amend可以修改最近一次提交的信息。注意这只适合还没推送的提交如果已经 push 了不要 amend那样会导致远端和本地历史不一致。commit 提交后发现漏了文件git add 漏掉的文件再git commit --amend --no-edit--no-edit表示不修改提交信息直接把漏掉的文件补进上一次提交里。commit 提交错了要回退分两种情况。git reset --soft HEAD~1 # 撤销 commit保留工作区改动 git reset --hard HEAD~1 # 撤销 commit丢弃工作区改动--soft适合“提交太早还想再改改”的场景。--hard适合“这次提交完全不要了”的场景但--hard有风险执行前最好用git log确认你要回到的版本号没有打错。已经推送了不小心 reset用git revert commit-id生成一个反向提交把错误提交的改动撤掉同时保留历史记录。revert 是安全的远程回退方式不会改写远端已有历史。注意git reset和git revert的核心区别在于reset 是“移动指针”适合本地回退revert 是“生成新提交抵消旧提交”适合远程回退。团队协作时尽量不要对已推送的提交做 reset否则队友 pull 的时候会撞上一堆诡异冲突。4. 我看过很多人把 .gitignore 写错4.1 .gitignore 的作用范围与匹配规则.gitignore是用来告诉 Git 哪些文件不应该被跟踪的。常见的是编译产物、依赖目录、本地配置、日志文件等。它的匹配规则比想象中简单# 忽略任意目录下的 node_modules node_modules/ # 忽略所有 .log 文件 *.log # 忽略 build 目录下的所有内容但保留该目录本身 build/ # 忽略 config 目录下的 local.js但不影响其他文件 config/local.js # 不忽略 config/prod.js前面有 ! 表示取反 !config/prod.js这里有个容易踩的坑如果一个文件已经被 Git 跟踪了那么你再在.gitignore里写它也没用。因为 Git 的跟踪状态是“已经纳入版本管理”.gitignore只对未跟踪文件生效。解决办法是git rm --cached 文件名--cached的意思是“从版本控制中移除但保留本地文件”执行完再 commit 一次这个文件就被“遗忘”了之后.gitignore里的规则才开始生效。4.2 常见该忽略和不该忽略的文件最常见的该忽略文件Node.js 项目的node_modules/、Java 项目的target/、Python 项目的__pycache__/、IDE 配置.idea/和.vscode/、日志文件*.log、环境变量.env。其中.env尤其重要里面通常有密钥和数据库密码一旦提交到远端仓库再撤回密钥就等于泄露了必须去服务商那边重新生成。不该忽略的典型例子是package-lock.json和yarn.lock。这两个文件锁定了所有依赖的精确版本号是团队环境一致的保障必须提交进去。我见过有团队一开始把 lock 文件加到.gitignore结果每个人装出来的依赖版本都不一样线上 bug 排查了半天才发现是依赖不一致。4.3 全局忽略规则与模板不同项目有各自的忽略需求但有些文件是无论什么项目都不该提交的比如.DS_StoremacOS 的文件夹元数据、Thumbs.dbWindows 缩略图缓存、.vscode/下的个人配置。这时可以配置一个全局.gitignoregit config --global core.excludesfile ~/.gitignore_global然后把通用规则写进~/.gitignore_global里以后所有项目都自动生效每个项目的.gitignore只需要管项目特有的文件。我见过不少开发者的做法是直接从 GitHub 的 gitignore 仓库拷贝模板这个习惯很好但要注意模板是面向通用场景的你还是要根据自己的项目结构再补充几条个性化的忽略规则比如“我这款应用有个特殊的资源目录里面的是构建产物不能被提交”这种只有自己清楚。5. 那些看起来像“黑魔法”的命令其实很有用5.1 git log 的一些高级用法git log不只是看历史列表用好它能极大提升排查效率。git log --oneline --graph --all --decorate这条命令以图形方式展示所有分支的提交历史每个提交只显示一行带上分支标签和 HEAD 位置。排查问题时我第一反应就是跑这条命令比看一堆密密麻麻的裸 log 直观得多。按作者和关键词过滤git log --author张三 git log --grepfix bug git log --since2024-01-01 --until2024-06-01看某个文件的完整修改历史git log -p -- 文件路径-p会把每次提交的具体改动内容也展示出来定位“这个文件是哪次提交改坏的”非常高效。5.2 git stash临时切换分支的救星场景你正在feature-a分支上写着代码突然线上有个紧急 bug 需要切到master分支修复。但当前改动还没写完直接切换分支会把半成品带过去或者因为冲突切不过去。这时候用 stashgit stash # 暂存当前工作区的改动 git checkout master # 切到 master 修复 bug git branch hotfix-xxx # 开个分支修 # ...修复完成、提交、合并... git checkout feature-a # 回到原来分支 git stash pop # 恢复暂存的改动stash本质是把工作区和暂存区的改动打包存到一个栈里pop时按后进先出的顺序恢复。它还支持git stash list查看所有暂存项git stash apply stash{1}恢复指定的暂存项。这里有个实用技巧如果暂存的改动和新分支的代码有冲突pop 的时候会像 merge 一样提示冲突。此时不要慌按冲突解决的流程处理即可stash 里的原始改动在你解决完冲突之前都还在可以放心动手。5.3 git cherry-pick精准搬运提交如果你只想把别的分支上的某一次提交拿过来而不是把整个分支合并过来用cherry-pick。git cherry-pick commit-id典型场景master分支提交了一个紧急修复release-2024分支也需要这个修复但不能直接把master全部合并到release里会带来一堆不想要的改动。这时候git cherry-pick那个修复提交的 commit-id 就行。需要注意cherry-pick会把提交“复制”到当前分支产生一个新的 commit-id。如果后续原提交被 amend 了或者你 pick 的提交和当前分支内容有冲突处理方式跟普通冲突一样。5.4 git reflog最后的救命稻草git reflog是本地的“操作日志”记录了所有 HEAD 指针的移动轨迹。哪怕你误操作git reset --hard丢了一个提交reflog里也能找到那个提交的 hash把它恢复回来。git reflog输出会显示类似HEAD{0}: reset: moving to HEAD~2的记录每一条代表一次 HEAD 移动。找到你想要恢复的提交 hash执行git reset --hard hash就能回到那个状态。reflog默认保留 90 天的记录所以“误删提交”在 Git 里基本不存在只要你没把.git目录删了几乎所有操作都可以撤销。经验心得我在带新人时经常说Git 的恢复能力比大多数人想象中强得多。滥用--hard确实有风险但只要你有reflog这个兜底绝大多数误操作都能救回来。真正危险的其实是你清空.git目录或者用git gc手动清理对象日常操作很难造成不可逆的灾难。6. 合代码时的冲突我一般这样处理6.1 冲突是怎么产生的冲突的本质是两个分支修改了同一段代码的相同位置。Git 擅长合并互不干扰的改动比如一个改了文件头一个改了文件尾但无法自动判断“同一行到底以谁的为准”于是只能把决定的权力交还给人。举个例子你和同事都在改config.js的port字段。你把 3000 改成 8080同事把 3000 改成 9090。合并时 Git 看到两个分支对同一行做了不同修改它就抛出一个冲突。这不是 Git 的缺陷而是它诚实地告诉你“我不知道你们俩谁对”。6.2 解决冲突的完整流程第一步执行合并或 rebase 命令后Git 会提示冲突文件。用git status查看哪些文件处于both modified状态。第二步打开冲突文件会看到类似这样的标记 HEAD const port 8080; const port 9090; feature-config HEAD到之间是当前分支的内容到 feature-config之间是另一个分支的内容。你需要手动决定保留哪个、删掉哪个或者改成一个两个都不一样的版本。在我看来最理想的情况是“这段代码既不是你的也不是他的而是两个人的需求合并后的最优解”。第三步解决完所有冲突标记后保存文件执行git add 冲突文件 git commit # merge 场景生成合并提交 # 或者 git rebase --continue # rebase 场景这里有一个新手容易犯的错直接删掉冲突标记里的一边内容就算完事了但两边代码可能都不是完整方案可能两边都要保留一部分。正确做法是读完两边的逻辑理解各自目的再写出兼容的新代码。6.3 减少冲突的几个好习惯冲突无法完全避免但可以大幅减少。第一小步提交频繁同步。一个功能分支不要憋两周不 push尽量拆成几个小提交每完成一个能编译能跑的小目标就推一次。你在本地改得越久和主线的偏差就越大合并时冲突概率越高。第二尽量用 rebase 更新分支。在功能分支上执行git fetch origin main再git rebase origin/main能让你的提交始终基于主线最新代码。虽然每次 rebase 可能遇到连续冲突但解决一次之后后续的都顺了比最后一次性合并时面对密密麻麻的冲突要轻松得多。第三统一格式化和 lint 规则。很多冲突不是因为逻辑不一致而是因为格式化工具把整行代码重排了导致 Git 认为“整个文件都改了”。用 ESLint、Prettier 等工具统一风格并在.editorconfig里固定缩进和换行符能从源头上消除一类假冲突。7. push 被拒绝和“鬼打墙”般的文件差异7.1 push 被拒绝的几种原因与应对git push失败是最常见的报错之一。最常见的提示是“! [rejected] main - main (non-fast-forward)”。原因很简单远端分支上有你本地还没有的提交而 Git 不允许你直接“覆盖”远端历史。解决办法是先拉取远端更新再把本地提交并上去。git fetch origin git rebase origin/main git push我用fetch rebase push这套组合比直接git pull --rebase更稳妥因为fetch只是把远端状态拉到本地不修改工作区你可以先看看git log origin/main确认远端到底多了哪些提交再决定怎么处理。如果你确定要用本地版本完全覆盖远端通常是刚初始化或测试分支可以强制推送git push -f origin main但强制推送会重写远端历史协同分支上绝对不要用。有几次我在个人项目上用了-f后面想找回旧提交也费了好大劲现在除非万不得已我都用git push --force-with-lease而不是裸的-f。--force-with-lease会检查远端是否有别人推送的新提交如果有就拒绝推送相当于“有条件的强推”安全得多。7.2 文件差异“异常”的排查思路遇到“我只改了一行但 Git 显示这个文件有几百行差异”的情况八成是换行符问题。Windows 下 Git 默认把 CRLF 转成 LF 写入仓库checkout 时再转回 CRLF但如果你之前的文件是以 CRLF 形式提交入库的后面换了.gitattributes或 autocrlf 配置Git 会认为整个文件都变了。解决办法是在仓库根目录加一个.gitattributes文件明确指定换行符规则* textauto *.sh text eollf *.bat text eolcrlf.gitattributes是比core.autocrlf更推荐的做法因为它是跟随仓库走的团队每个人拉下来规则一致不依赖个人本机配置。还有一种“鬼打墙”情况是明明删除了某个文件但git status里它还是显示为已修改重新git add后 commit 又提示“nothing to commit”。这多半是该文件既是符号链接又指向了不存在的目标或者文件权限位改了但内容没改。这时候用git config --global core.filemode false把文件权限变更从 diff 里忽略掉能省掉大量无意义的 diff。7.3 那些奇怪的“-c”前缀命令是什么最近热搜里有人问git -c diff.mnemonicPrefixfalse -c core.quotepathfalse --no-optional-locks是什么。我在本地也踩到过类似的命令这其实是从某些 IDE 或 CI 工具里复制出来的 Git 调用它不是普通用户日常手敲的命令而是工具内部为了让输出更稳定、报告更规范而附加的全局选项。拆开看-c diff.mnemonicPrefixfalse关闭 diff 输出中的字母前缀如a/、b/这类符号让 diff 输出的文件名更直白。-c core.quotepathfalse让中文和特殊字符的文件名正常显示不转义成八进制。这个我之前也提到过对中文用户特别实用。--no-optional-locks告诉 Git 这次操作不要创建或刷新一些可选锁文件避免在后台运行时干扰正在进行的其他 Git 操作。如果你在 GitHub Actions 之类的 CI 日志或某些脚本里看到这种命令说明工具的开发者希望 Git 输出更干净、行为更可控。它本身不是一条需要手动学习的“魔法命令”核心价值在于展示了 Git 强大的“命令行内配置”能力——所有git config能设置的项基本都能用-c keyvalue的形式附加在单条命令上不修改全局配置。这个用法在写脚本时尤其有用。比如你临时需要在一个老仓库里提交但不想改全局用户名git -c user.name临时工 -c user.emailtempexample.com commit -m 临时提交命令跑完不影响全局配置ansi非常便捷。8. 分支管理规范是团队协作的隐形契约8.1 推荐一套简单可落地的分支模型我看过很多团队的分支策略复杂的如 Git Flow有master、develop、release、hotfix、feature五种分支适合大型项目和严格发版流程。但对大多数中小团队来说这套模型偏重落地起来维护成本高。我更推荐基于主干开发的简化模型main主分支长期存在始终处于可发布状态。feature/*功能分支从main拉出开发完成合回main。bugfix/*修复分支从main拉出修完合回main。release/*可选从main拉出用于发布前的最后测试和版本号调整。这套模型的核心是功能分支生命周期短尽量 3 天以内合回主分支。功能分支不要直接碰main而是通过 Merge Request / Pull Request 来做利用平台的代码评审和 CI 检查再合入。我见过不少团队规则很松大家直接在main上拉新分支又直接往mainpush结果主分支经常处于不可编译状态一发版就手忙脚乱。8.2 合并策略merge、squash、rebase 选哪个大多数代码托管平台GitHub / GitLab在合入 MR/PR 时提供三种合并方式我在实际工作中根据场景不同会这样选合并方式历史形态适用场景Merge Commit保留所有中间提交历史完整功能周期长、希望保留每个开发节点的场景Squash and Merge所有提交压缩成一个提交功能分支提交很碎、希望主分支历史干净Rebase and Merge按时间顺序重放提交历史线性冲突少、追求直线历史的场景个人建议默认用 Squash and Merge。理由很简单功能分支上那些 “WIP”work in progress、“fix typo”、“update” 之类的提交对后来的读者没有意义一条功能一条提交反而清晰。但如果你在做开源项目维护者更倾向 merge commit 以保留每个贡献者的提交痕迹所以看项目文化和平台约定。8.3 Commit Message 的写法和规范commit message 不是给自己看的是给未来的自己和同事看的。我见过太多“update”、 “fix”、 “修改”这种毫无信息量的提交说明过两周回头查问题根本不知道这次提交改了什么。推荐用 Conventional Commits 风格type(scope): subject body常见 type 有feat新功能fix修 bugdocs文档变更style格式调整不影响代码逻辑refactor重构不改变功能test补充测试chore构建或辅助工具变动scope 是可选的模块名比如feat(login): 添加记住密码功能。subject 用祈使句简洁明了不超过 50 个字符。如果改动复杂还可以在提交信息里加 body 段落说明背景和影响但我在实践中发现绝大多数 commit 不需要 body一行 subject 就够了需要背景信息时写在 MR 描述里更合适。注意commit message 风格最忌讳一两个人觉得好就拍板要求全团队执行。强制规范之前最好先在团队里拉一次会议对齐版本、约定和工具链commitlint、husky 等让所有人都觉得“这是大家的约定”而不是“某个领导定的规矩”落地阻力会小很多。9. 那些让人抓狂的疑难杂症排查9.1 误删分支如何恢复场景你执行了git branch -D feature-login一瞬间分支“没了”。但别慌分支本质只是一个指向提交的指针你删除的只是指针被指向的提交对象依然在对象库里。用git reflog找到删除前分支指向的最后一个 commit hash然后git branch feature-login hash分支就回来了。所以我的习惯是在reflog里有记录的前提下禁用git gc --prunenow这种强制清理命令给所有误操作留退路。9.2 误提交了敏感信息怎么办这是最严重的事故之一。如果你把密钥、密码、云服务 token 提交到了远端仓库第一步不是git rm再提交因为 Git 历史里已经永久保留了旧版本任何能访问仓库的人都能翻出来。正确应对步骤立刻去对应服务商平台轮换密钥/密码让旧凭证失效。在本地历史里清除敏感信息推荐用git filter-repo而不是历史版本的filter-branch后者又慢又容易出问题。强制推送清理后的历史并告知所有协作者重新克隆。如果仓库是公开的还要考虑联系平台客服看是否能清除缓存和派生仓库的引用。预防同样重要提交前用git diff检查暂存内容或接入 pre-commit 钩子配合 gitleaks 这类工具扫描敏感信息把风险挡在 push 之前。我至今还留着一个教训那次误提交 .env 文件之后我上线了什么检查都先扫一遍再也不敢靠肉眼判断了。9.3 Git 卡在某个操作上或文件锁死Git 偶尔会报index.lock相关错误说明另一个 Git 进程还在跑或者上次操作意外中断导致锁文件残留。解决办法很简单删掉这个锁文件。rm .git/index.lock遇到Unable to create .../.git/index.lock时先确认没有其他 Git 进程在跑比如 IDE 自动操作再删除锁文件。我一般会用ps aux | grep git看一眼确认没有后台命令在跑再删避免误伤正在进行的正常操作。还有一种常见卡顿是git push突然没反应多半是网络代理问题。可以试试git config --global --unset http.proxy git config --global --unset https.proxy或者反过来如果你处于需要使用代理的网络环境就检查代理配置是否正确。遇到这种网络类的疑难杂症先GIT_CURL_VERBOSE1 git push跑一次把 curl 的输出打出来能直接看到它到底连到哪个地址、卡在哪一步比瞎猜快得多。9.4 常见问题速查表问题直接原因推荐操作git push被拒绝远端有新提交git fetchgit rebasegit push提交后想改 message提交未推送git commit --amend误 reset 丢失提交本地指针移动git reflog找回 hash 再git reset --hard中文文件名乱码quotepath 未关闭git config --global core.quotepath false大量假 diffCRLF/LF 换行不一致建.gitattributes统一规则误删分支指针删除但对象还在git refloggit branch hash敏感信息泄露已进历史轮换凭证 git filter-repo 强推.gitignore不生效文件已被跟踪git rm --cached后再提交密码总是要输没配 SSH key生成 key 并加到平台10. 最后再分享几条长期实践下来的心得10.1 把 Git 命令“背下来”不如“理解对象模型”学 Git 最大的一个坎是思维方式。很多人把 Git 命令当成咒语在背换个场景就不知道怎么组合了。但如果你理解了 Git 的三层对象模型——工作区、暂存区、本地仓库、远端仓库——绝大多数命令就都能自己推导出来。所谓“暂存区”本质是“下一次提交的候选内容”“提交”本质是“把暂存区的内容打包成一个不可变的历史快照”“分支”本质是“指向某个提交的可移动指针”“HEAD”本质是“当前分支指针的位置”。带着这套理解再回去看add、commit、checkout、reset、merge你会发现它们都不过是在这几层之间搬运和修改引用。10.2 养成“小步提交、频繁提交”的习惯从前有个阶段我也喜欢憋一个大功能再一次性提交觉得这样提交历史“干净”。直到某次我改了两天代码最后发现第二步的设计方向就有问题但因为没有中间提交点我根本退不回去只能靠git diff一片一片地手工还原别提多痛苦了。从那以后我改成“每完成一个可以编译、可以跑通的小目标就提交一次”虽然历史里多了很多提交但每次回退、排查都精准多了。这个习惯还有个额外好处code review 时分而治之评审人可以按提交顺序理解你的实现思路而不是只看一个巨大的 diff 去猜。10.3 能用命令行就不点 IDE 按钮我知道很多新手喜欢在 IDE 里点 “Commit”“Push”“Sync” 这些图形化按钮因为看起来直观。但 IDE 的 Git 集成往往屏蔽了很多细节比如冲突标记、rebase 过程中的状态变化你以为点了按钮就成功了实际中间发生了很多你完全看不到的操作。等你哪天遇到复杂冲突IDE 的图形界面反而会让你更困惑。不是说 IDE 的 Git 功能不能用而是建议你先用命令行把所有高频操作跑熟练理解每一步背后发生了什么再回到 IDE 里做操作。两者结合才是效率最高的状态如果你连命令行都熟练了你会发现 IDE 里的报错和提示也不再那么“神秘”了。10.4 让工具帮你守规范人都会忘工具不会。团队里想推行 commit message 规范、分支命名规范、合并前必须跑测试就把它交给工具链去卡。常见的搭配是husky加commitlint检查提交信息lint-staged在提交前只对暂存文件跑 lintGitLab CI / GitHub Actions 在 MR 上跑全量测试所有检查过了才允许合入。这套东西搭起来花不了多少时间但对“低成本维护健康的仓库”来说收益是长期的。我见过太多团队靠“口头约定”维护规范三个月后仓库还是一样乱。Git 这个工具用了这么多年我最大的感受是它的上限远比表面看到的那些命令高得多但也正因为如此很多人在用完三板斧之后就停止了探索。希望这篇小结能帮你跨过那根从“会用”到“用好”的线后面的路你可以自己走。
