在团队开发里泡得久了你会发现一个现象很多人并不是不会 Git而是被一堆看似高级、实则低频的命令绕晕了真正每天高频使用、决定开发效率的往往是那二三十个基础命令。我见过不少同事clone、add、commit、push用得挺顺但一碰到分支合并冲突、提交信息写错、误删分支、大文件推送失败就会卡住半天。这篇指南不是 Git 官方文档的翻译也不是什么“XX 天精通 Git”的速成教程。我只把实际工作中真正用得上、且反复出现的 Git 操作拎出来从仓库初始化讲到大文件管理从日常提交讲到疑难杂症排查。每一节会说明命令的作用、背后的工作机制、典型使用场景以及我踩过的坑和总结出来的注意点。1. 仓库初始化与基础配置1.1 首次使用前的全局配置拿到一台新电脑装好 Git 之后第一件事不是急着建仓库而是先确认身份信息。Git 的每次提交都会记录作者姓名和邮箱如果没配置提交时会提示让你补全而且不同仓库之间还容易混淆身份。git config --global user.name Your Name git config --global user.email your_emailexample.com--global表示写入用户级配置文件~/.gitconfig对所有仓库生效。如果某个项目需要单独身份比如公司项目用公司邮箱个人项目用私人邮箱可以去掉--global在对应仓库里单独设置这样会写入仓库的.git/config文件优先级更高。除了身份信息我还会调整两个全局配置。# 让 git 命令输出带上颜色方便区分状态 git config --global color.ui true # 设置默认分支名为 main新仓库初始化时使用 git config --global init.defaultBranch main还有一个高频配置是换行符处理。Windows 和 Linux/macOS 的换行符不一致CRLF 与 LF如果不处理会出现“明明没改文件却显示一堆改动”的尴尬情况。建议按操作系统区分配置# Windows 用户提交时转成 LF检出时转成 CRLF git config --global core.autocrlf true # macOS/Linux 用户提交时转成 LF检出时保持 LF git config --global core.autocrlf input这个配置做完之后跨平台协作的换行符问题基本能被挡在门外。团队内部最好统一这个配置否则仍然可能在git diff里看到大量无意义的换行符差异。1.2 初始化仓库与克隆远程仓库本地从零开始的项目用git init初始化参与已有项目用git clone拉取远程仓库。两者的使用场景完全不同但都是最基础的第一步。# 在当前目录初始化仓库 git init # 克隆远程仓库到当前目录 git clone gitgithub.com:user/repo.git # 克隆时指定本地目录名 git clone gitgithub.com:user/repo.git my-project我推荐公司项目一律用 SSH 方式克隆而不是 HTTPS。原因很简单SSH 配置好密钥后每次push、pull都不需要输入账号密码而 HTTPS 虽然首次使用方便但后续频繁输入凭证会让人崩溃即使配置了 credential helper还是不如密钥来得干净。git init执行后最好立刻创建.gitignore文件。这个文件用来声明哪些目录和文件不需要被 Git 跟踪比如# 依赖目录 node_modules/ vendor/ # 编译产物 dist/ build/ *.class # 环境配置 .env *.local # IDE 配置 .idea/ .vscode/.gitignore的规则是逐行匹配的支持通配符。node_modules/表示忽略整个目录*.class表示忽略所有.class后缀文件。常见问题是文件已经被跟踪了再加入.gitignore就不生效。此时需要先把文件从 Git 索引中移除git rm -r --cached node_modules--cached表示只从索引暂存区移除不删除本地文件。这样之后提交一次node_modules就不再被跟踪了。1.3 关联远程仓库与查看配置如果是本地git init的项目之后需要关联远程仓库比如在 Gitee、GitHub 或公司内网 GitLab 上创建了空项目这时要手动建立关联git remote add origin gitgithub.com:user/repo.git # 查看当前关联的远程仓库 git remote -v # 修改远程仓库地址 git remote set-url origin gitgithub.com:user/new-repo.git远程仓库的名字origin是约定俗成的默认名代表“主远程仓库”。git remote -v会列出所有远程仓库的 fetch 和 push 地址可以用来确认关联是否正确。我遇到过一种情况项目的远程地址变更了仓库迁移但本地还指向旧地址这时候直接set-url改掉就行不用删了重新加。查看当前分支的跟踪关系可以用git branch -vv这个命令会列出所有本地分支并显示每个分支跟踪的远程分支以及领先/落后多少个提交。排查“为什么 push 不上去”或者“为什么 pull 不下来”的时候这个命令非常管用。2. 日常提交与代码同步2.1 工作区、暂存区、版本库的关系聊提交之前必须先厘清 Git 的三个区域工作区、暂存区Index、版本库HEAD。工作区是你电脑上能看到的文件目录所有修改最初都在这里。暂存区是一个中间状态用来存放你准备提交的改动。版本库存放的是已经提交的历史快照。日常操作路径是修改工作区文件 →git add把改动放入暂存区 →git commit把暂存区内容生成一个新提交 →git push推送到远程。理解这条链路很多命令就不会混淆了。# 查看当前仓库状态 git status # 将指定文件加入暂存区 git add src/main/java/UserController.java # 将所有改动加入暂存区谨慎使用 git add . # 将已跟踪文件的修改加入暂存区 git add -ugit status是使用频率最高的命令没有之一。它显示的信息包括当前分支、与远程分支的领先/落后情况、工作区改动了哪些文件、哪些文件已暂存、哪些文件未跟踪。建议每次提交前都跑一遍git status确认要提交的文件范围避免把不想提交的文件带进去。2.2 提交信息规范与 amend 用法暂存区的文件准备好之后就可以提交了git commit -m feat: 新增用户登录接口提交信息建议遵循 Conventional Commits 规范格式为type(scope): subject。常用的 type 有type含义feat新功能fix修复 bugdocs文档变更style代码格式调整不影响逻辑refactor重构不新增功能也不修 bugtest增加或修改测试chore构建过程或辅助工具的变动比如feat: 新增用户登录接口、fix: 修复订单金额计算精度问题。规范的提交信息不仅有助团队 Code Review还能配合工具自动生成 CHANGELOG。写完提交后发现信息写错了或者漏掉了一个文件没提交这时不需要重新 commit用--amend修改上一次提交# 修改上一次提交的信息 git commit --amend -m fix: 修复用户头像上传失败问题 # 补充文件到上一次提交且不修改提交信息 git add 漏掉的文件 git commit --amend --no-edit--amend的工作原理是用一个新的提交对象替换上一次提交而不是在历史中新增一条记录。所以提交的哈希值会改变。如果这个提交已经推送到远程且其他人也在使用千万不要 amend否则会跟远程历史产生分叉。2.3 拉取远程更新与推送本地提交提交到本地之后还需要跟远程同步。这里的两个命令是git fetch和git pull很多人分不清。# 拉取远程所有分支的最新提交但不合并到当前分支 git fetch origin # 拉取远程当前分支的最新提交并合并到本地 git pull origin main # 推送本地提交到远程 git push origin maingit fetch只是把远程的更新下载到本地更新本地仓库的远程跟踪分支如origin/main但不会改动你的工作区和当前分支。git pull等价于git fetchgit merge。我个人的习惯是在需要了解远程是否有更新、但还不想干扰当前工作的时候用git fetch确定要把远程更新合并到本地分支时用git pull --rebase。--rebase的作用是把你本地的提交变基到远程分支的最新提交之上形成线性历史避免产生一次无意义的 merge 提交。多人在同一分支协作时线性历史看起来会清爽很多。push 的时候如果遇到“远端有更新被拒绝”的报错说明本地不是基于远程最新提交开发的。此时应该git pull --rebase origin main git push origin mainrebase会把本地的提交“垫”到远程最新提交的后面如果中途有冲突Git 会停下来让你手动解决。解决方式在后面的冲突处理部分详细说。3. 分支管理与合并3.1 分支创建、切换与删除分支是 Git 最强大的功能之一它的本质是一个指向提交对象的指针。创建、切换、删除分支的日常命令如下# 基于当前分支创建新分支 git branch feature/user-login # 切换到指定分支 git checkout feature/user-login # 创建并切换简写 git checkout -b feature/user-login # 删除本地分支已合并 git branch -d feature/user-login # 删除本地分支强制未合并也能删 git branch -D feature/user-logingit checkout -b是使用频率最高的组合命令新建分支并立即切换效率很高。新版 Git 也提供了git switch命令语义更清晰# 切换分支 git switch feature/user-login # 创建并切换 git switch -c feature/user-login从 Git 2.23 开始官方把“切换分支”和“恢复文件”的职责从checkout中拆了出来switch专管分支切换restore专管文件恢复。如果团队用的 Git 版本较新建议优先使用switch和restore命令语义更明确也更容易记忆。删除分支时-d会检查分支是否已合并未合并会报错拒绝删除-D则是强制删除不管有没有合并。建议先确认分支内容不需要了再强制删除否则找回成本很高。3.2 合并分支merge 与 rebase 的选择把功能分支合并回主分支常用的方式有两种git merge和git rebase。merge的操作结果是生成一个新的“合并提交”保留两条分支的历史轨迹。优点是安全、可回溯缺点是有可能形成网状历史git log看起来很乱。多人在中大型项目上协作时merge 的历史里混着一堆Merge branch feature into main提交追踪问题会费劲些。rebase的操作结果是把分支上的提交逐个“重放”到目标分支的最新提交之上形成一条直线。优点是历史非常整洁缺点是你改写了提交顺序和哈希值如果分支已经被共享rebase 会造成冲突和混乱。我的实践建议是场景推荐方式个人功能分支合并到主分支且分支未共享rebase保持线性历史多人协作的分支合并merge --no-ff保留合并记录从主分支同步最新代码到功能分支rebase避免无用 merge 提交需要保留功能分支的完整开发过程merge合并的常见写法# 切换到目标分支合并功能分支 git checkout main git merge feature/user-login # 不使用快进合并强制生成合并提交 git merge --no-ff feature/user-login # 将当前分支变基到 main 的最新提交 git checkout feature/user-login git rebase main--no-ff的作用是即使分支可以快进即主分支没有新提交也强制生成一个合并提交。这样在历史上能明确看到“这里曾经是一个功能分支的合并点”对于版本回退和发布管理非常有用。3.3 解决冲突的完整流程无论 merge 还是 rebase只要两边改动到同一文件的同一区域就会产生冲突。冲突的表现是文件中出现这样的标记 HEAD 这是当前分支的内容 这是被合并分支的内容 feature/user-login解决冲突的标准流程如下第一步查看冲突文件列表git status第二步打开冲突文件手动修改。把、、标记及其中的旧内容删掉只保留你想要的内容。这里没有技巧可言必须人工判断取舍。第三步将解决完的文件加入暂存区git add 冲突文件第四步完成合并或变基# 如果是 merge git commit -m merge: 合并 feature/user-login # 如果是 rebase git rebase --continuerebase过程中如果觉得冲突太多解决不下去可以随时终止git rebase --abortmerge也可以用git merge --abort终止合并恢复到合并前的状态。这里有个细节rebase时冲突会以一个一个提交的形式出现解决完一个提交的冲突继续--continue可能又遇到下一个提交的冲突。因此 rebase 的冲突处理比 merge 更繁琐但好处是每个提交都会被完整保留。3.4 stash 暂存当前工作正在功能分支上开发时突然需要切换到其他分支修一个紧急 bug但手头的工作还没完成不想提交。这时候使用git stash# 暂存当前所有未提交的改动 git stash # 暂存时附带说明信息 git stash save 用户登录功能开发中 # 查看暂存列表 git stash list # 恢复最近一次暂存并删除该暂存记录 git stash pop # 恢复指定暂存但不删除记录 git stash apply stash{1}git stash本质是把工作区和暂存区的改动保存为一个独立的快照然后让工作区恢复到干净状态。stash list显示的是暂存栈每次 stash 都会压栈pop是从栈顶恢复。我踩过的坑是stash pop遇到冲突时代码不会自动合并而是把改动恢复到工作区并标记冲突状态。此时手动解决冲突即可但要注意 stash 记录不会自动清除需要手动git stash drop。所以如果 pop 时出现冲突建议先别急着删暂存等确认解决无误后再清理。4. 历史查看与版本回退4.1 提交历史与文件对比查看提交历史是每天都要做的事。最基础的命令是git log但默认输出太啰嗦我会配置别名来精简显示git log --oneline --graph --all--oneline用一行显示一个提交短哈希 提交信息--graph用 ASCII 图形展示分支结构--all显示所有分支。这个命令组合基本能满足 90% 的查看需求。更详细的查看方式# 查看最近的 5 条提交 git log -5 # 查看某个文件的提交历史 git log --oneline -- src/main/java/UserService.java # 查看某个作者最近两周的提交 git log --authorzhangsan --since2 weeks ago --oneline # 查看提交中改了哪些文件 git log --stat文件对比也是高频操作# 查看工作区某文件与暂存区的差异 git diff src/main/java/UserController.java # 查看暂存区与最新提交的差异 git diff --cached # 查看两个提交之间的差异 git diff commit1_hash commit2_hash # 查看当前分支与 main 分支的差异 git diff main需要注意git diff默认比较的是工作区与暂存区而不是工作区与版本库。如果你改了文件但没有git addgit diff能看到改动一旦git add之后git diff就看不到这部分改动了需要使用git diff --cached。4.2 回退操作reset、revert、checkout 的取舍代码写错了、提交错了、分支搞乱了都需要回退。Git 提供了三种回退方式很多人混着用导致出问题其实三种方式的适用场景完全不同。git reset是将当前分支的 HEAD 指针移动到一个历史提交同时可以选择是否重置暂存区和工作区# 软回退保留工作区和暂存区改动仅移动 HEAD最安全 git reset --soft HEAD~1 # 混合回退保留工作区改动重置暂存区默认行为 git reset --mixed HEAD~1 # 硬回退清空工作区和暂存区的所有改动危险 git reset --hard HEAD~1git reset --hard会丢掉所有未提交的改动而且基本无法找回执行之前务必确认。如果只是想撤销上一个提交但保留代码改动用--soft如果只是想取消暂存用--mixed或直接git restore --staged。git revert的作用是生成一个新的提交用来反向抵消某个历史提交的改动。它不会移动 HEAD 指针而是“追加”一个反向提交# 撤销指定提交的改动并生成一个新提交 git revert commit_hash # 撤销时自动生成提交信息 git revert --no-edit commit_hashrevert与reset最大的区别是reset改写历史reset 之后 push 会报错revert不改写历史、只追加提交。远程分支的代码需要回退时绝对不能用reset --hard然后push --force那样会影响所有协作者正确做法是git revert让所有人看到一次新的“撤销提交”。git checkout在回退场景中主要用于恢复文件的某个历史版本# 将工作区某个文件恢复到暂存区的状态 git checkout -- src/main/java/UserController.java # 将文件恢复到某个提交时的状态 git checkout commit_hash -- src/main/java/UserController.java不过新版 Git 更推荐用git restore来做文件恢复git restore src/main/java/UserController.javarestore的语义更明确——恢复文件不会像checkout那样跟切换分支混在一起。4.3 cherry-pick 挑选指定提交开发中经常遇到一种需求某个紧急修复提交在main分支上但功能分支也想同步这个修复又不想直接把整个 main 合并过来。这时候用git cherry-pick# 将指定提交应用到当前分支 git cherry-pick commit_hash # 应用多个提交 git cherry-pick commit1_hash commit2_hash # 应用某个范围内所有提交 git cherry-pick start_hash..end_hashcherry-pick的原理是把指定提交的改动以“补丁”的方式重新应用到当前分支并生成一个新提交。如果应用过程中有冲突解决方式与 merge 冲突类似解决后git add再git cherry-pick --continue不想应用了用git cherry-pick --abort。这招在维护多个发布分支时尤其好用。比如线上出问题修复提交在 dev 分支需要同步到 release 分支和 main 分支每个分支上cherry-pick一次既干净又不会把预计好的其他功能带过来。5. Git LFS 大文件管理5.1 什么时候需要用 LFS日常开发中二进制文件图片、音视频、设计稿、模型文件一旦超过几十 MB用普通 Git 管理就会让仓库迅速膨胀。Git 本身对文本文件的 diff 和压缩做得很好但对二进制文件毫无办法——每次修改都相当于保存一份完整的新文件历史一多仓库体积直接爆炸。Git LFSLarge File Storage的机制是把大文件内容替换为一个轻量的指针文件真正的文件内容存放到 LFS 服务器上。仓库里只保存指针克隆时按需拉取实际文件。需要说明的是Git LFS 需要服务端支持。GitHub、GitLab、Gitee 都支持 LFS但自建的 Git 服务器比如纯git --bare仓库需要额外部署 LFS 服务。如果只是本地自用不建议强行上 LFS。我见过最典型的场景是游戏开发项目的测试资源、移动端 App 的设计切图、算法团队的模型权重文件。这类文件单个体积大、改动频繁、团队又必须共享不用 LFS 的话git clone一次要下几个 GB而且每次推送都会卡半天。5.2 LFS 安装与配置流程Git LFS 是一个独立工具需要先安装。以 macOS 和 Ubuntu 为例# macOS使用 Homebrew brew install git-lfs # Ubuntu/Debian curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash sudo apt-get install git-lfs安装完成后在仓库里启用git lfs install # 指定大文件类型 git lfs track *.psd git lfs track *.zip git lfs track *.mp4 # 查看当前跟踪的文件类型 git lfs track # 提交配置 git add .gitattributes git commit -m chore: 配置 LFS 跟踪规则git lfs install会在用户级配置文件里注册 LFS 钩子每个仓库只需执行一次。git lfs track会修改仓库根目录下的.gitattributes文件这个文件记录了所有 LFS 跟踪规则必须提交到仓库里否则其他协作者克隆后不会应用相同的规则。5.3 LFS 日常使用与坑点配置完成之后日常的git add、git commit、git push、git pull命令完全不变LFS 在后台自动处理。但有几个坑我实际踩过值得单独说。第一个坑是git lfs clone卡住。旧版 LFS 的 clone 方式是先拉取指针文件再逐个下载 LFS 内容仓库文件一多就会密密麻麻输出下载进度看着像卡死。实际上 LFS 提供了并发机制可以这样优化git config --global lfs.concurrenttransfers 8 git config --global lfs.batchtransfers true第二个坑是 LFS 文件拉取失败。出现LFS: failed to fetch之类的错误一般是网络问题或服务端配置问题。排查方式# 查看 LFS 环境信息 git lfs env # 手动 download 指定文件定位是哪个对象失败 git lfs pull --include*.psd第三个坑是git lfs install之后之前已经推送到远程的大文件不会自动迁移到 LFS。需要迁移历史文件时用git lfs migrate但这个命令会改写历史操作前一定备份好仓库。# 将历史中的指定扩展名文件迁移到 LFS git lfs migrate import --include*.psd,*.zip --everythingmigrate会在所有分支和历史提交上重写内容需要所有协作者配合重新克隆仓库如果不是仓库体积已经大到无法忍受不建议轻易执行。6. 实际工作中的疑难杂症与排查6.1 常用命令速查表整理一份我在实际工作中高频使用的命令速查表方便对照查阅场景命令查看仓库状态git status查看提交历史git log --oneline --graph --all查看文件改动git diff/git diff --cached暂存改动git add 文件或目录提交改动git commit -m feat: ...修改上次提交git commit --amend --no-edit拉取远程更新git pull --rebase origin main推送本地提交git push origin main创建并切换分支git checkout -b 分支名切换分支git switch 分支名查看所有分支git branch -a删除分支git branch -d/D 分支名暂存工作区git stash恢复暂存git stash pop合并分支git merge 分支名变基git rebase 分支名撤销提交安全git revert 提交哈希回退本地提交git reset --soft/mixed/hard HEAD~n挑选提交git cherry-pick 提交哈希恢复文件git restore 文件路径取消暂存git restore --staged 文件路径这张表覆盖了日常开发的 80% 场景。剩下的 20% 属于低频但棘手的情况下面专门展开讲。6.2 SSH 认证失败的处理SSH 方式克隆或推送时报Permission denied (publickey)是新人最容易卡住的问题。排查步骤第一步确认本地是否存在密钥ls ~/.ssh/常见文件是id_rsa私钥和id_rsa.pub公钥。如果没有生成一对ssh-keygen -t rsa -b 4096 -C your_emailexample.com生成过程中一路回车即可也可以给私钥设置密码安全性更高但每次连接都要输入。第二步查看公钥内容把它添加到 Git 平台GitHub/Gitee/GitLab的 SSH Keys 设置中cat ~/.ssh/id_rsa.pub第三步验证是否配置成功ssh -T gitgithub.com如果返回Hi xxx! Youve successfully authenticated说明认证没问题。如果还是失败检查是否有多个密钥文件导致 Git 使用了错误的那一个。可以在~/.ssh/config里指定Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_company另一种情况是公司内网使用自签名证书这时需要关闭 Git 的 SSL 验证。但这样做有安全风险不建议全局关闭只对特定仓库关闭git config http.sslVerify false这个操作相当于告诉 Git“不要验证这个 HTTPS 地址的证书”仅限内网可信环境使用。6.3 分支合并冲突后的恢复指南分支合并冲突发生之后心态不要崩。冲突不是代码损坏只是 Git 需要你帮忙决定保留哪边的内容。首先明确冲突文件范围git status输出中会明确列出both modified: 文件名这就是冲突文件。然后用编辑器打开冲突文件搜索、、标记。这里有一个实用技巧如果冲突文件很多逐个打开效率太低可以借助命令行快速定位所有冲突位置grep -rn ^ 冲突目录/或者直接在编辑器里全局搜索IDE如 IntelliJ IDEA、VS Code会高亮显示冲突区域并提供“接受当前 / 接受传入 / 合并”的快捷操作。解决完所有冲突后git add . git commit -m merge: 合并 feature/user-login 分支如果是 rebase 过程中的冲突用git add后执行git rebase --continue。一个经验之谈如果在合并过程中发现冲突太过复杂而且自己对两边改动的理解不够透彻先别硬解。保存好当前状态退出合并git merge --abort然后仔细阅读双方分支的提交历史搞清楚改动意图后再重新合并。硬着头皮乱改冲突只会留下更麻烦的后果。6.4 Git 目录泄露的被动场景与应对最后提一个相对罕见但值得知道的场景你在某个项目目录里执行git status时发现仓库里有.git目录但本地根本没有初始化过这个仓库或者下载了一个别人打包的项目压缩包里包含了.git目录。git clone正常克隆的仓库自带.git目录这没问题。但如果项目是通过文件传输比如网盘、内网盘传播的.git目录会携带仓库的全部历史、分支、提交信息甚至可能包含敏感配置数据库密码、密钥、内部地址。这种情况下对方拿到压缩包就等同于拿到了你的完整代码历史和内部信息。处理思路是检查.git/config里的 remote 配置确认有没有可能泄露的敏感信息如果仓库已经不需要保留历史可以删除.git目录重新git init创建一个干净仓库。# 查看远程仓库地址 git remote -v # 删除整个 .git 目录 rm -rf .git # 重新初始化干净仓库 git init git add . git commit -m chore: 初始化干净仓库从管理角度看团队内部应避免以压缩包形式分发带.git目录的项目统一走 Git 仓库克隆。同时注意检查仓库中是否存在.env、config.php、application.yml等配置文件里硬编码的账号密码这类信息一旦进入 Git 历史即使后续删除也仍然会留在历史记录里。6.5 几个影响日常体验的细节习惯经验积累到最后我发现真正拉开效率差距的往往不是命令本身而是使用习惯。第一个习惯是配置别名。高频命令配成短别名能省不少时间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 --decorate配置之后git lg就能一条命令看到完整的分支历史图。第二个习惯是提交前先git diff。很多问题在提交前就能避免多提交了配置文件、改错了文件、或者带了调试代码。git diff检查一遍发现问题就撤回比提交完再补救成本低得多。第三个习惯是谨慎使用git add .和git push --force。git add .会把当前目录下所有改动都加入暂存区包括不该提交的临时文件、调试文件。建议使用git add 具体文件或git add -u只暂存已跟踪文件的修改。git push --force会改写远程历史只有在团队约定一致、且明确知道自己在做什么的情况下才用否则会影响所有协作者。第四个习惯是定期维护仓库。大项目跑久了.git目录可能积累很多无效对象。可以用git gcgc会清理松散对象、压缩历史让仓库体积减小。日常开发中建议周期性执行或者在克隆大仓库感觉卡顿时执行。但注意不要在多人同时操作的共享裸仓库上执行gc可能引发并发问题。第五个习惯是善用reflog。git reflog是 Git 的“后悔药”它记录了 HEAD 的所有移动历史。即使你reset --hard到一个错误提交、或者误删了分支只要reflog还在就能找到之前的提交哈希恢复回来git reflog # 恢复到某个记录点 git reset --hard HEAD{2}reflog保存在本地不会推送到远程。这意味着只要你的本地仓库还在绝大多数误操作都能找回。每次觉得自己搞砸了先去看一眼reflog往往能救回来。我个人在实际操作中最深的体会是Git 的学习曲线不在命令本身而在于建立心智模型——搞清楚每次操作到底动了工作区、暂存区、本地仓库还是远程仓库。只要这个模型清晰了遇到陌生问题也能靠git status和git log推导出大致方向。命令背不下来没关系把速查表存下来多踩几次坑自然就记住了。