1. 为什么每个开发者都要吃透这套命令Git 不是什么新鲜东西但凡写过代码的人基本都用过但真正能把它用得行云流水的说实话不多。我见过太多同事每天就靠 IDE 那三个按钮活着一旦遇到冲突、误删、回退错版本整个人就懵了最后只能百度一条命令抄一条运气好救回来了运气不好直接重写代码。这套 Git 常用命令覆盖提交、查看日志、版本回退、文件撤销这几个最核心的场景就是把日常开发中最容易踩坑的那几个环节一次性讲透。这篇文章适合什么人看刚入行的前端后端实习生、从 SVN 转 Git 的老兵、以及用了一年 Git 但只会在 IDEA 里点点点的同学。看完整篇文章你不会成为一个 Git 底层原理专家但你会知道代码写完了该怎么提交最规范、出问题了怎么查历史、回退版本有哪些坑、误删文件怎么救回来。这些能力是每天都要用的。我始终觉得Git 这东西就像开车不需要你懂发动机原理但刹车、油门、方向盘这几个基本操作必须熟练到肌肉记忆。下面这套命令组合就是你在代码世界里的刹车、油门和方向盘。2. 动手前先搞定环境安装与首次配置2.1 不同系统的安装方式Windows 用户最简单去官网下载 Git for Windows一路 Next 就行。这里有一个值得注意的选项安装过程中会让你选默认编辑器建议直接选 Vim虽然上手有点门槛但当你需要处理合并提交信息时Vim 是最保险的选择——不依赖任何第三方 IDE。如果你实在不习惯 Vim选 Notepad 或者 VS Code 也可以但记得把调整 PATH 环境变量那一步选成Git from the command line and also from 3rd-party software避免后续命令行找不到 git 命令。macOS 用户如果装了 Homebrew一条brew install git就搞定了没装的话去官网下载 pkg 安装包即可。Linux 用户更不需要我多说apt install git或者yum install git看你发行版。装完以后在终端敲git --version能输出版本号就算成功。这里插一句很多人都会遇到的报错在 Windows 上装完 Git 后打开 PowerShell 输入 git提示无法将git项识别为 cmdlet、函数、脚本文件或可运行程序的名称。99% 的情况是环境变量没生效关掉终端重新开一个或者手动检查 PATH 里是否包含了 Git 的安装目录。别急着重装先重启终端试试。2.2 首次使用必做的三件事装好 Git 后第一件事是告诉它你是谁不然提交代码时会报Please tell me who you are的错误。命令行依次执行git config --global user.name 你的名字 git config --global user.email 你的邮箱这里我建议邮箱就填你 GitLab 或 GitHub 上注册的那个不然提交记录和个人主页对不上回头找「是谁改坏了这行代码」的时候会很痛苦。--global参数代表全局生效如果想对单个仓库用不同的身份去仓库目录下执行不带--global的同款命令即可。第二件事是配 SSH 免密。虽然 HTTPS 方式也能用但每次 push 都要输账号密码体验极差。生成密钥的方式很简单ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车默认生成到~/.ssh/id_rsa.pub。然后把公钥内容复制到代码托管平台的 SSH Keys 设置里。配置完以后执行ssh -T gitgithub.com测试连通性看到Hi xxx就说明配好了。这一步做完后续所有操作都能少输几十次密码。第三件事设置默认分支名。现在主流平台默认分支都叫main了但 Git 默认创建的还是master。执行一条命令统一口径git config --global init.defaultBranch main这纯属个人习惯问题但团队协作时统一分支命名能省去很多不必要的解释成本。3. 提交代码三剑客 add、commit、push3.1 提交的标准流程写完了代码要把它提交到仓库最标准的流程就是add到暂存区、commit打快照、push推到远程。很多新手不理解为什么要分三步感觉多此一举。我打个比方add就是把要寄的快递放进纸箱commit是封箱并贴上快递单号push是把快递交给快递员发出。你完全可以先打包好几箱最后一起发出去。实际操作中最常用的是git add .把所有改动都加进暂存区。但这里我要提醒一句git add .虽然方便也容易把不该提交的文件提交上去比如本地配置文件、自动生成的目录。所以更推荐的做法是结合.gitignore文件把不需要版本管理的路径提前排除掉。.gitignore的写法很简单每行一个规则比如# 依赖目录 node_modules/ dist/ build/ # 环境配置 .env *.local # 日志和临时文件 *.log .DS_Store有了它git add .就不会误伤无辜了。提交的瞬间用git status确认一下当前状态已经养成了我个人的肌肉记忆每次 commit 之前不看一眼心里不踏实。提交命令本身是git commit -m 提交说明。如果要提交的文件比较多git add可以省略掉直接用git commit -am 提交说明注意-a参数只能提交已跟踪文件的修改新文件它是不管的。所以习惯上用全流程更稳妥。3.2 提交信息怎么写才算专业git commit -m里的描述信息写得好不好直接决定三个月后你自己能不能看懂这段历史。我见过有人写fix bug、update、111这种敷衍了事的等到排查线上问题时恨不得穿越回去掐死当时的自己。比较通用的规范是 Conventional Commits格式如下type(scope): subjecttype表示提交类型常用值有type含义示例feat新功能feat(user): 新增用户注册接口fix修复 bugfix(login): 修复登录超时问题docs文档变更docs(readme): 更新部署说明refactor重构不改变功能refactor(order): 重构订单状态机style格式调整style(css): 统一按钮间距test测试相关test(cart): 补充购物车结算用例chore构建或辅助工具chore: 升级 webpack 到 5.0scope是影响范围比如模块名、组件名可以省略。subject用简洁的祈使句描述这次改动做了什么。团队成员如果都能按这个规范来提交后面用git log --oneline浏览历史时整个项目的演进脉络会清清楚楚自动生成 changelog 也直接可复用。如果你的团队已经有自己的一套规范那就按团队的来统一比什么都重要。3.3 commit 提交到一半想反悔怎么办有时候提交完了才想起来漏了一个文件或者 message 写错了。这时候别慌Git 提供了修改提交的能力。如果只是想补充漏掉的文件且本次还未 push 到远程可以这样操作git add 漏掉的文件 git commit --amend --no-edit--amend会把新暂存的内容合并进上一次提交--no-edit表示沿用上一次的提交信息不需要重新编辑。如果连提交信息也要改去掉--no-edit就行会打开编辑器让你重新写。这里有个致命的注意事项--amend会改写提交的 hash 值所以只能修改还没有 push 到远程的提交。如果已经推送过了再 amend 然后强推会导致别人的本地仓库出现分叉团队协作中这叫篡改历史通常是不被允许的。一句话总结本地随便改远程要谨慎。3.4 push 到远程的常见问题git push的基本用法是git push origin 分支名。第一次推送新分支时Git 会提示你使用--set-upstream建立追踪关系git push -u origin feature/login-u参数的意思是设置上游分支后续在这个分支上直接敲git push就能推送到对应远程分支省去多余参数。很多人用 IDEA 或 VS Code 推送失败报错信息五花八门最折磨人的是git push -u origin main 一直提交不上去。我归纳一下常见的几个原因网络不通或代理配置错误Git 访问不到远程仓库。分支名不对本地分支叫 master远程仓库的分支叫 main。SSH key 没配好提示Permission denied (publickey)。本地代码和远程有冲突远程有人推送了新代码需要先 pull 合并。排查顺序建议是先git remote -v看远程地址对不对再ssh -T gitgithub.com测 SSH 通不通再看分支名最后看有没有冲突提示。直接 push 不上去就换 HTTPS 方式再试有时候能救急。4. 查看日志读懂项目的前世今生4.1 git log 基本用法提交做得规范了日志看起来就是一种享受。不加任何参数的git log会把所有提交的完整信息列出来信息量太大反而不利于快速浏览。我日常工作最常用的几个参数组合# 简洁的一行模式 git log --oneline # 显示最近 5 条提交 git log -5 # 带图形化展示分支合并关系 git log --graph --oneline --all # 查看某个文件的修改历史 git log --oneline -- 文件名--oneline把每次提交压缩成一行只显示短 hash 和提交信息刷历史时最常用。--graph配合--all可以看所有分支的分叉和合并关系排查分支问题时特别好用。--all会包含所有分支的提交不只是当前分支。如果想知道某次提交具体改了什么内容用git show commit-hash它会展示这次提交的完整 diff包括哪些文件变了、增删了多少行。只看某个文件的变更在后面加文件路径就行。4.2 查找特定的提交记录项目跑了一段时间提交可能有几百上千条纯靠肉眼翻不现实。Git 提供了多种搜索方式。按提交信息搜索git log --grep登录还能用--author指定作者、--since和--until限定时间范围、--grep搜索提交信息。组合起来效果惊人git log --oneline --author张三 --since2024-01-01 --until2024-06-30 --grep修复这句命令能查到张三在 2024 年上半年所有包含修复字样的提交。排查功能回归问题比如这个功能是谁在什么时候改坏的通常就是这么定位的。4.3 让 git log 输出更定制化如果你觉得默认的 log 格式不够友好可以用--pretty自定义输出格式。比如只显示 hash、作者、日期和提交信息git log --prettyformat:%h | %an | %ad | %s --dateshort%h是短 hash%an是作者名%ad是日期%s是提交主题。--dateshort把日期格式化成 YYYY-MM-DD。这个格式我用了很久配合--oneline交替使用基本满足所有看日志的场景。如果觉得每次打这么长一串太累可以直接在 Git 配置里设置别名git config --global alias.lg log --oneline --graph --all --decorate以后敲git lg就能看到一棵完整的分支树效率翻倍。类似的还可以给git status设置git st给git checkout设置git co。别名这个东西用上了就回不去。5. 版本回退时间旅行者的后悔药5.1 reset 三种模式的区别版本回退是 Git 里最强大也最危险的操作玩明白它是区分老手和新手的分水岭。核心命令是git reset它有三个模式差别在于恢复到指定版本后工作区、暂存区、版本库三个区域的状态不同。先理解三个区域工作区是你电脑上能看到的文件暂存区是add之后的中间地带版本库是commit之后的历史快照。git reset的三个模式分别对应不同的处理方式模式工作区暂存区适用场景--soft不变不变只想撤销 commit保留 add 的内容--mixed默认不变清空撤销 commit 和 add保留工作区修改--hard彻底还原清空完全回到某个历史版本丢弃所有改动实际使用中我 90% 的场景是用--soft和--mixed。比如刚才提交了一条内容有问题的 commit但不舍得丢掉代码改动就执行git reset --soft HEAD~1HEAD~1表示回到当前提交的前一个提交也就是撤销最新的一次 commit。--soft模式保留了暂存区的内容git status会看到文件处于 staged 状态直接修改后重新 commit 就行。--hard是最后的手段因为它会丢弃工作区里所有未保存的修改。执行前务必确认没有未提交的代码或者做好备份。这个命令一出任何想恢复的文件都会被强行覆盖没有回头路。5.2 回退后如何同步到远程本地回退到历史版本后如果这个分支已经推送到远程直接git push会报错因为本地分支比远程分支落后了。这时候需要强制推送git push --force-with-lease origin 分支名这里我特意用的是--force-with-lease而不是--force。区别在于--force-with-lease会先检查远程分支有没有被别人更新过只有远程分支还停留在你上次拉取的位置时才会强推相当于加了一层保险。如果其他人已经在远程提交了代码这个命令会拒绝执行避免覆盖别人的工作。踩过坑的人都知道裸的--force在某些团队里几乎等于事故制造器。强推以后其他人拉取代码时可能遇到分支分叉处理方式下面第 7 节再说。这里强调的是回退远程版本是一个高风险操作能走 revert 就优先 revert。5.3 回退错了怎么办git reset --hard回退后不小心把要的代码也丢掉了能不能找回答案是分情况。如果你回退前记住了原来的提交 hash可以在 reflog 里找到它。git reflog记录了所有 HEAD 移动的历史哪怕被 reset 掉的提交也能在里面找到git reflog输出里会有类似e3a5f2c HEAD{0}: reset: moving to HEAD~3的记录。找到你要回去的那个 hash再执行一次git reset --hard 原来的hash就能把丢失的状态恢复过来。只要 reflog 记录还在通常 30 天内都查得到。这也是为什么遇到误操作先别慌多看看 reflog 再决定。5.4 如果只是想撤销某一次提交git revertgit reset是直接从历史中抹掉提交git revert则是创建一个新提交反向执行那次提交的改动。两者的区别你可以理解为reset 是穿越回去篡改历史revert 是以史为鉴地补一个新动作。git revert commit-hash执行后会生成一条新的 commit内容是撤销目标 commit 的改动但历史记录里保留了完整的时间线。这对于已推送的公共分支非常友好不会导致其他人本地仓库分叉。revert 不是万能药如果那笔提交已经牵涉到别人后续的改动可能会产生冲突需要手动处理。但总体来说在多人协作的场景中revert 比 reset 安全得多。6. 文件撤销工作区、暂存区、版本库的三层后悔药6.1 工作区文件改坏了怎么恢复这是日常开发中发生频率最高的场景改了几行代码发现方向不对想回到修改前的状态。如果文件还没有add最直接的就是用git checkoutgit checkout -- 文件名注意这行命令中间有个--它的作用是告诉 Git 后面的参数是文件路径而不是分支名。不加--的话如果文件名恰好和分支名相同Git 会迷惑。恢复多个文件可以列多个路径或者用git checkout -- .恢复整个工作区。用git restore是更现代的写法git restore 文件名restore是 Git 2.23 之后引入的命令语义比checkout清晰很多日常操作我推荐优先用restore。git checkout的历史包袱太重一个命令身兼数职新手容易搞混。6.2 误 add 到暂存区的文件怎么撤回代码已经git add了突然发现有文件不该加进来怎么把它从暂存区挪出去但保留工作区的修改用git resetgit reset HEAD 文件名这条命令把文件从暂存区退回到工作区但不会动文件内容。对于已经add的目录用git reset HEAD .可以把所有暂存内容一次性退回去。在旧版 Git 中也写作git rm --cached但注意rm --cached和reset HEAD的行为有细微差别前者是彻底移除跟踪后者只是移出暂存区。日常场景用reset HEAD就够了。不想记两条命令的话git restore --staged 文件名也是个好选择语义直观把暂存区的状态恢复掉。6.3 误删了文件怎么办rm 文件名手滑删除了一个还没提交的文件心里凉了半截。别慌如果这个文件最近一次提交过用 checkout 或 restore 能直接从版本库赎回来git checkout -- 被删的文件名或者git restore 被删的文件名如果删除动作已经 stage 了比如git add -A把删除操作也暂存了需要先处理暂存区再恢复git reset HEAD 被删的文件名 git checkout -- 被删的文件名两步搞定。真正的完全删除很难只要文件进过版本库都能从历史里捞出来。这也是我一直跟团队强调的多提交勤提交写的代码都是宝贝别让它们处于裸奔状态。6.4 撤销 pull 操作的特殊场景有一种场景很折磨人执行了git pull结果远程更新拉下来和本地冲突或者自动合并把本地文件弄乱了而本地有一些还没 commit 的修改被牵连了。git pull操作想撤销但不能影响未 commit 的文件怎么做首先要冷静git pull的本质是fetch merge。如果 merge 产生冲突或者结果不理想可以先用git merge --abort中止当前的合并操作让仓库回到 pull 之前的状态。这个命令只影响合并过程不会动你未 commit 的工作区文件所以安全。git merge --abort如果你是想要整体回退到 pull 之前的提交那得先查一下之前的 HEAD 指向哪里。用git reflog找到 pull 之前的那条记录然后git reset --mixed pull之前的hash注意这里用--mixed模式而不是--hard这样工作区的修改会保留下来只是把提交指针和暂存区状态退回去。如果你连本地未提交的修改都想保留又想彻底回到之前的状态记住千万别用--hard血的教训。7. 高频报错与实战排坑实录7.1 新手最容易踩的五个坑开发过程中踩坑不可怕可怕的是同一个坑踩十次。我这里整理几个高频问题希望能帮你们少走弯路。坑一commit 提交到了错误的分支。在 feature 分支上开发到一半发现切错分支了提交信息出现在了 main 分支上。处理方式先记录当前提交的 hashgit reset --soft HEAD~1撤销提交然后git stash暂存改动切到正确分支后git stash pop恢复。不要直接cherry-pick来回倒腾容易乱。坑二误执行--hard导致代码丢失。最快的解法是git reflog找回原来的 hash再git reset --hard回去。reflog 是本地操作日志不受 push 影响安全系数很高。坑三提交规范不统一导致历史混乱。这个只能靠团队约定来治。推荐在项目根目录加一个COMMIT_CONVENTION.md或者用 commitlint 工具做卡点不规范的提交直接拒绝。工具强制比自觉约束靠谱得多。坑四在错误的分支上执行了数据破坏性命令。比如在 main 分支上git reset --hard回退了一堆提交事后发现应该操作的是 feature 分支。做法是立刻在 reflog 里找到丢失的提交 hash然后 reset 回去再用正确的方式重来一遍。坑五pull 时产生大量的 merge commit。这通常是因为本地提交和远程提交分叉导致的。多人协作时推荐用git pull --rebase代替git pull把本地提交重放到远程最新提交之上历史记录保持线性干净不少。7.2 查看日志时的杂症处理查看日志遇到输出乱码多半是中文显示问题。执行git config --global core.quotepath false可以解决文件名中文转义的问题。如果提交信息里的中文显示成?或者乱码检查终端编码是否为 UTF-8Windows 下建议把 Git Bash 的编码调成 UTF-8或者设置git config --global i18n.commitEncoding utf-8。还有一种情况是git log半天没响应可能是提交历史太庞大用--oneline配合数量限制git log --oneline -20只显示最近 20 条速度就上来了。7.3 一个完整的救援案例复盘我拿之前带团队时遇到的一个真实场景来复盘。同事小刘在开发分支上干了两周提交了一堆 commit其中混入了几个调试用的垃圾提交恰好又把另一个同事正在改的文件给覆盖了导致线上发布失败。他当时想直接reset --hard回到两周前但这样会把这两周所有的代码劳动都蒸发掉其他同事后续在他这个分支上的提交也会变成孤儿提交。我们的处理顺序是先用git reflog确认他最后一次正常提交的 hash。用git checkout -b rescue开一条救援分支指向那个 hash把代码先保护起来。回到原开发分支用git revert一个个撤销有问题的提交而不是 reset。冲突部分手动合入重新测试后推送。整个过程没有强推任何远程分支其他人的本地仓库也没有出现分叉。事后总结就一句话当分支已经共享给其他人能用 revert 解决的就别用 reset。这应该是 Git 协作里最贵的一课。8. 把这套命令沉淀为一套工作流最后再分享一个我个人的习惯。每次入职新公司或接手新项目我第一件事就是把.gitignore配好、.gitconfig的别名设好、提交规范跟团队成员对齐。这三个动作看起来不产生代码但决定了一个仓库长期的可维护性。日常工作流我基本固定成写完代码git status检查 →git add精确添加 →git commit -m feat(模块): 具体说明→git pull --rebase同步最新 →git push推送。遇到问题先在git log --oneline -10和git reflog里找线索不盲目动手。说得再直白一点Git 命令不需要全背下来但上面这二十多条一定要练到闭眼能敲。它们覆盖了日常开发 80% 的场景剩下的 20%碰到再学完全来得及。把这些操作变成肌肉记忆你的编码幸福感会提升一大截。
1. 为什么每个开发者都要吃透这套命令Git 不是什么新鲜东西但凡写过代码的人基本都用过但真正能把它用得行云流水的说实话不多。我见过太多同事每天就靠 IDE 那三个按钮活着一旦遇到冲突、误删、回退错版本整个人就懵了最后只能百度一条命令抄一条运气好救回来了运气不好直接重写代码。这套 Git 常用命令覆盖提交、查看日志、版本回退、文件撤销这几个最核心的场景就是把日常开发中最容易踩坑的那几个环节一次性讲透。这篇文章适合什么人看刚入行的前端后端实习生、从 SVN 转 Git 的老兵、以及用了一年 Git 但只会在 IDEA 里点点点的同学。看完整篇文章你不会成为一个 Git 底层原理专家但你会知道代码写完了该怎么提交最规范、出问题了怎么查历史、回退版本有哪些坑、误删文件怎么救回来。这些能力是每天都要用的。我始终觉得Git 这东西就像开车不需要你懂发动机原理但刹车、油门、方向盘这几个基本操作必须熟练到肌肉记忆。下面这套命令组合就是你在代码世界里的刹车、油门和方向盘。2. 动手前先搞定环境安装与首次配置2.1 不同系统的安装方式Windows 用户最简单去官网下载 Git for Windows一路 Next 就行。这里有一个值得注意的选项安装过程中会让你选默认编辑器建议直接选 Vim虽然上手有点门槛但当你需要处理合并提交信息时Vim 是最保险的选择——不依赖任何第三方 IDE。如果你实在不习惯 Vim选 Notepad 或者 VS Code 也可以但记得把调整 PATH 环境变量那一步选成Git from the command line and also from 3rd-party software避免后续命令行找不到 git 命令。macOS 用户如果装了 Homebrew一条brew install git就搞定了没装的话去官网下载 pkg 安装包即可。Linux 用户更不需要我多说apt install git或者yum install git看你发行版。装完以后在终端敲git --version能输出版本号就算成功。这里插一句很多人都会遇到的报错在 Windows 上装完 Git 后打开 PowerShell 输入 git提示无法将git项识别为 cmdlet、函数、脚本文件或可运行程序的名称。99% 的情况是环境变量没生效关掉终端重新开一个或者手动检查 PATH 里是否包含了 Git 的安装目录。别急着重装先重启终端试试。2.2 首次使用必做的三件事装好 Git 后第一件事是告诉它你是谁不然提交代码时会报Please tell me who you are的错误。命令行依次执行git config --global user.name 你的名字 git config --global user.email 你的邮箱这里我建议邮箱就填你 GitLab 或 GitHub 上注册的那个不然提交记录和个人主页对不上回头找「是谁改坏了这行代码」的时候会很痛苦。--global参数代表全局生效如果想对单个仓库用不同的身份去仓库目录下执行不带--global的同款命令即可。第二件事是配 SSH 免密。虽然 HTTPS 方式也能用但每次 push 都要输账号密码体验极差。生成密钥的方式很简单ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车默认生成到~/.ssh/id_rsa.pub。然后把公钥内容复制到代码托管平台的 SSH Keys 设置里。配置完以后执行ssh -T gitgithub.com测试连通性看到Hi xxx就说明配好了。这一步做完后续所有操作都能少输几十次密码。第三件事设置默认分支名。现在主流平台默认分支都叫main了但 Git 默认创建的还是master。执行一条命令统一口径git config --global init.defaultBranch main这纯属个人习惯问题但团队协作时统一分支命名能省去很多不必要的解释成本。3. 提交代码三剑客 add、commit、push3.1 提交的标准流程写完了代码要把它提交到仓库最标准的流程就是add到暂存区、commit打快照、push推到远程。很多新手不理解为什么要分三步感觉多此一举。我打个比方add就是把要寄的快递放进纸箱commit是封箱并贴上快递单号push是把快递交给快递员发出。你完全可以先打包好几箱最后一起发出去。实际操作中最常用的是git add .把所有改动都加进暂存区。但这里我要提醒一句git add .虽然方便也容易把不该提交的文件提交上去比如本地配置文件、自动生成的目录。所以更推荐的做法是结合.gitignore文件把不需要版本管理的路径提前排除掉。.gitignore的写法很简单每行一个规则比如# 依赖目录 node_modules/ dist/ build/ # 环境配置 .env *.local # 日志和临时文件 *.log .DS_Store有了它git add .就不会误伤无辜了。提交的瞬间用git status确认一下当前状态已经养成了我个人的肌肉记忆每次 commit 之前不看一眼心里不踏实。提交命令本身是git commit -m 提交说明。如果要提交的文件比较多git add可以省略掉直接用git commit -am 提交说明注意-a参数只能提交已跟踪文件的修改新文件它是不管的。所以习惯上用全流程更稳妥。3.2 提交信息怎么写才算专业git commit -m里的描述信息写得好不好直接决定三个月后你自己能不能看懂这段历史。我见过有人写fix bug、update、111这种敷衍了事的等到排查线上问题时恨不得穿越回去掐死当时的自己。比较通用的规范是 Conventional Commits格式如下type(scope): subjecttype表示提交类型常用值有type含义示例feat新功能feat(user): 新增用户注册接口fix修复 bugfix(login): 修复登录超时问题docs文档变更docs(readme): 更新部署说明refactor重构不改变功能refactor(order): 重构订单状态机style格式调整style(css): 统一按钮间距test测试相关test(cart): 补充购物车结算用例chore构建或辅助工具chore: 升级 webpack 到 5.0scope是影响范围比如模块名、组件名可以省略。subject用简洁的祈使句描述这次改动做了什么。团队成员如果都能按这个规范来提交后面用git log --oneline浏览历史时整个项目的演进脉络会清清楚楚自动生成 changelog 也直接可复用。如果你的团队已经有自己的一套规范那就按团队的来统一比什么都重要。3.3 commit 提交到一半想反悔怎么办有时候提交完了才想起来漏了一个文件或者 message 写错了。这时候别慌Git 提供了修改提交的能力。如果只是想补充漏掉的文件且本次还未 push 到远程可以这样操作git add 漏掉的文件 git commit --amend --no-edit--amend会把新暂存的内容合并进上一次提交--no-edit表示沿用上一次的提交信息不需要重新编辑。如果连提交信息也要改去掉--no-edit就行会打开编辑器让你重新写。这里有个致命的注意事项--amend会改写提交的 hash 值所以只能修改还没有 push 到远程的提交。如果已经推送过了再 amend 然后强推会导致别人的本地仓库出现分叉团队协作中这叫篡改历史通常是不被允许的。一句话总结本地随便改远程要谨慎。3.4 push 到远程的常见问题git push的基本用法是git push origin 分支名。第一次推送新分支时Git 会提示你使用--set-upstream建立追踪关系git push -u origin feature/login-u参数的意思是设置上游分支后续在这个分支上直接敲git push就能推送到对应远程分支省去多余参数。很多人用 IDEA 或 VS Code 推送失败报错信息五花八门最折磨人的是git push -u origin main 一直提交不上去。我归纳一下常见的几个原因网络不通或代理配置错误Git 访问不到远程仓库。分支名不对本地分支叫 master远程仓库的分支叫 main。SSH key 没配好提示Permission denied (publickey)。本地代码和远程有冲突远程有人推送了新代码需要先 pull 合并。排查顺序建议是先git remote -v看远程地址对不对再ssh -T gitgithub.com测 SSH 通不通再看分支名最后看有没有冲突提示。直接 push 不上去就换 HTTPS 方式再试有时候能救急。4. 查看日志读懂项目的前世今生4.1 git log 基本用法提交做得规范了日志看起来就是一种享受。不加任何参数的git log会把所有提交的完整信息列出来信息量太大反而不利于快速浏览。我日常工作最常用的几个参数组合# 简洁的一行模式 git log --oneline # 显示最近 5 条提交 git log -5 # 带图形化展示分支合并关系 git log --graph --oneline --all # 查看某个文件的修改历史 git log --oneline -- 文件名--oneline把每次提交压缩成一行只显示短 hash 和提交信息刷历史时最常用。--graph配合--all可以看所有分支的分叉和合并关系排查分支问题时特别好用。--all会包含所有分支的提交不只是当前分支。如果想知道某次提交具体改了什么内容用git show commit-hash它会展示这次提交的完整 diff包括哪些文件变了、增删了多少行。只看某个文件的变更在后面加文件路径就行。4.2 查找特定的提交记录项目跑了一段时间提交可能有几百上千条纯靠肉眼翻不现实。Git 提供了多种搜索方式。按提交信息搜索git log --grep登录还能用--author指定作者、--since和--until限定时间范围、--grep搜索提交信息。组合起来效果惊人git log --oneline --author张三 --since2024-01-01 --until2024-06-30 --grep修复这句命令能查到张三在 2024 年上半年所有包含修复字样的提交。排查功能回归问题比如这个功能是谁在什么时候改坏的通常就是这么定位的。4.3 让 git log 输出更定制化如果你觉得默认的 log 格式不够友好可以用--pretty自定义输出格式。比如只显示 hash、作者、日期和提交信息git log --prettyformat:%h | %an | %ad | %s --dateshort%h是短 hash%an是作者名%ad是日期%s是提交主题。--dateshort把日期格式化成 YYYY-MM-DD。这个格式我用了很久配合--oneline交替使用基本满足所有看日志的场景。如果觉得每次打这么长一串太累可以直接在 Git 配置里设置别名git config --global alias.lg log --oneline --graph --all --decorate以后敲git lg就能看到一棵完整的分支树效率翻倍。类似的还可以给git status设置git st给git checkout设置git co。别名这个东西用上了就回不去。5. 版本回退时间旅行者的后悔药5.1 reset 三种模式的区别版本回退是 Git 里最强大也最危险的操作玩明白它是区分老手和新手的分水岭。核心命令是git reset它有三个模式差别在于恢复到指定版本后工作区、暂存区、版本库三个区域的状态不同。先理解三个区域工作区是你电脑上能看到的文件暂存区是add之后的中间地带版本库是commit之后的历史快照。git reset的三个模式分别对应不同的处理方式模式工作区暂存区适用场景--soft不变不变只想撤销 commit保留 add 的内容--mixed默认不变清空撤销 commit 和 add保留工作区修改--hard彻底还原清空完全回到某个历史版本丢弃所有改动实际使用中我 90% 的场景是用--soft和--mixed。比如刚才提交了一条内容有问题的 commit但不舍得丢掉代码改动就执行git reset --soft HEAD~1HEAD~1表示回到当前提交的前一个提交也就是撤销最新的一次 commit。--soft模式保留了暂存区的内容git status会看到文件处于 staged 状态直接修改后重新 commit 就行。--hard是最后的手段因为它会丢弃工作区里所有未保存的修改。执行前务必确认没有未提交的代码或者做好备份。这个命令一出任何想恢复的文件都会被强行覆盖没有回头路。5.2 回退后如何同步到远程本地回退到历史版本后如果这个分支已经推送到远程直接git push会报错因为本地分支比远程分支落后了。这时候需要强制推送git push --force-with-lease origin 分支名这里我特意用的是--force-with-lease而不是--force。区别在于--force-with-lease会先检查远程分支有没有被别人更新过只有远程分支还停留在你上次拉取的位置时才会强推相当于加了一层保险。如果其他人已经在远程提交了代码这个命令会拒绝执行避免覆盖别人的工作。踩过坑的人都知道裸的--force在某些团队里几乎等于事故制造器。强推以后其他人拉取代码时可能遇到分支分叉处理方式下面第 7 节再说。这里强调的是回退远程版本是一个高风险操作能走 revert 就优先 revert。5.3 回退错了怎么办git reset --hard回退后不小心把要的代码也丢掉了能不能找回答案是分情况。如果你回退前记住了原来的提交 hash可以在 reflog 里找到它。git reflog记录了所有 HEAD 移动的历史哪怕被 reset 掉的提交也能在里面找到git reflog输出里会有类似e3a5f2c HEAD{0}: reset: moving to HEAD~3的记录。找到你要回去的那个 hash再执行一次git reset --hard 原来的hash就能把丢失的状态恢复过来。只要 reflog 记录还在通常 30 天内都查得到。这也是为什么遇到误操作先别慌多看看 reflog 再决定。5.4 如果只是想撤销某一次提交git revertgit reset是直接从历史中抹掉提交git revert则是创建一个新提交反向执行那次提交的改动。两者的区别你可以理解为reset 是穿越回去篡改历史revert 是以史为鉴地补一个新动作。git revert commit-hash执行后会生成一条新的 commit内容是撤销目标 commit 的改动但历史记录里保留了完整的时间线。这对于已推送的公共分支非常友好不会导致其他人本地仓库分叉。revert 不是万能药如果那笔提交已经牵涉到别人后续的改动可能会产生冲突需要手动处理。但总体来说在多人协作的场景中revert 比 reset 安全得多。6. 文件撤销工作区、暂存区、版本库的三层后悔药6.1 工作区文件改坏了怎么恢复这是日常开发中发生频率最高的场景改了几行代码发现方向不对想回到修改前的状态。如果文件还没有add最直接的就是用git checkoutgit checkout -- 文件名注意这行命令中间有个--它的作用是告诉 Git 后面的参数是文件路径而不是分支名。不加--的话如果文件名恰好和分支名相同Git 会迷惑。恢复多个文件可以列多个路径或者用git checkout -- .恢复整个工作区。用git restore是更现代的写法git restore 文件名restore是 Git 2.23 之后引入的命令语义比checkout清晰很多日常操作我推荐优先用restore。git checkout的历史包袱太重一个命令身兼数职新手容易搞混。6.2 误 add 到暂存区的文件怎么撤回代码已经git add了突然发现有文件不该加进来怎么把它从暂存区挪出去但保留工作区的修改用git resetgit reset HEAD 文件名这条命令把文件从暂存区退回到工作区但不会动文件内容。对于已经add的目录用git reset HEAD .可以把所有暂存内容一次性退回去。在旧版 Git 中也写作git rm --cached但注意rm --cached和reset HEAD的行为有细微差别前者是彻底移除跟踪后者只是移出暂存区。日常场景用reset HEAD就够了。不想记两条命令的话git restore --staged 文件名也是个好选择语义直观把暂存区的状态恢复掉。6.3 误删了文件怎么办rm 文件名手滑删除了一个还没提交的文件心里凉了半截。别慌如果这个文件最近一次提交过用 checkout 或 restore 能直接从版本库赎回来git checkout -- 被删的文件名或者git restore 被删的文件名如果删除动作已经 stage 了比如git add -A把删除操作也暂存了需要先处理暂存区再恢复git reset HEAD 被删的文件名 git checkout -- 被删的文件名两步搞定。真正的完全删除很难只要文件进过版本库都能从历史里捞出来。这也是我一直跟团队强调的多提交勤提交写的代码都是宝贝别让它们处于裸奔状态。6.4 撤销 pull 操作的特殊场景有一种场景很折磨人执行了git pull结果远程更新拉下来和本地冲突或者自动合并把本地文件弄乱了而本地有一些还没 commit 的修改被牵连了。git pull操作想撤销但不能影响未 commit 的文件怎么做首先要冷静git pull的本质是fetch merge。如果 merge 产生冲突或者结果不理想可以先用git merge --abort中止当前的合并操作让仓库回到 pull 之前的状态。这个命令只影响合并过程不会动你未 commit 的工作区文件所以安全。git merge --abort如果你是想要整体回退到 pull 之前的提交那得先查一下之前的 HEAD 指向哪里。用git reflog找到 pull 之前的那条记录然后git reset --mixed pull之前的hash注意这里用--mixed模式而不是--hard这样工作区的修改会保留下来只是把提交指针和暂存区状态退回去。如果你连本地未提交的修改都想保留又想彻底回到之前的状态记住千万别用--hard血的教训。7. 高频报错与实战排坑实录7.1 新手最容易踩的五个坑开发过程中踩坑不可怕可怕的是同一个坑踩十次。我这里整理几个高频问题希望能帮你们少走弯路。坑一commit 提交到了错误的分支。在 feature 分支上开发到一半发现切错分支了提交信息出现在了 main 分支上。处理方式先记录当前提交的 hashgit reset --soft HEAD~1撤销提交然后git stash暂存改动切到正确分支后git stash pop恢复。不要直接cherry-pick来回倒腾容易乱。坑二误执行--hard导致代码丢失。最快的解法是git reflog找回原来的 hash再git reset --hard回去。reflog 是本地操作日志不受 push 影响安全系数很高。坑三提交规范不统一导致历史混乱。这个只能靠团队约定来治。推荐在项目根目录加一个COMMIT_CONVENTION.md或者用 commitlint 工具做卡点不规范的提交直接拒绝。工具强制比自觉约束靠谱得多。坑四在错误的分支上执行了数据破坏性命令。比如在 main 分支上git reset --hard回退了一堆提交事后发现应该操作的是 feature 分支。做法是立刻在 reflog 里找到丢失的提交 hash然后 reset 回去再用正确的方式重来一遍。坑五pull 时产生大量的 merge commit。这通常是因为本地提交和远程提交分叉导致的。多人协作时推荐用git pull --rebase代替git pull把本地提交重放到远程最新提交之上历史记录保持线性干净不少。7.2 查看日志时的杂症处理查看日志遇到输出乱码多半是中文显示问题。执行git config --global core.quotepath false可以解决文件名中文转义的问题。如果提交信息里的中文显示成?或者乱码检查终端编码是否为 UTF-8Windows 下建议把 Git Bash 的编码调成 UTF-8或者设置git config --global i18n.commitEncoding utf-8。还有一种情况是git log半天没响应可能是提交历史太庞大用--oneline配合数量限制git log --oneline -20只显示最近 20 条速度就上来了。7.3 一个完整的救援案例复盘我拿之前带团队时遇到的一个真实场景来复盘。同事小刘在开发分支上干了两周提交了一堆 commit其中混入了几个调试用的垃圾提交恰好又把另一个同事正在改的文件给覆盖了导致线上发布失败。他当时想直接reset --hard回到两周前但这样会把这两周所有的代码劳动都蒸发掉其他同事后续在他这个分支上的提交也会变成孤儿提交。我们的处理顺序是先用git reflog确认他最后一次正常提交的 hash。用git checkout -b rescue开一条救援分支指向那个 hash把代码先保护起来。回到原开发分支用git revert一个个撤销有问题的提交而不是 reset。冲突部分手动合入重新测试后推送。整个过程没有强推任何远程分支其他人的本地仓库也没有出现分叉。事后总结就一句话当分支已经共享给其他人能用 revert 解决的就别用 reset。这应该是 Git 协作里最贵的一课。8. 把这套命令沉淀为一套工作流最后再分享一个我个人的习惯。每次入职新公司或接手新项目我第一件事就是把.gitignore配好、.gitconfig的别名设好、提交规范跟团队成员对齐。这三个动作看起来不产生代码但决定了一个仓库长期的可维护性。日常工作流我基本固定成写完代码git status检查 →git add精确添加 →git commit -m feat(模块): 具体说明→git pull --rebase同步最新 →git push推送。遇到问题先在git log --oneline -10和git reflog里找线索不盲目动手。说得再直白一点Git 命令不需要全背下来但上面这二十多条一定要练到闭眼能敲。它们覆盖了日常开发 80% 的场景剩下的 20%碰到再学完全来得及。把这些操作变成肌肉记忆你的编码幸福感会提升一大截。
