Git 这块东西不少刚接触的人觉得命令多、记不住尤其是提交、回退、撤销这几个操作来回搞稍有不慎就把代码改乱了。但真正用熟之后会发现Git 的常用命令其实就那么十几条核心场景也无非是提交、看日志、回退、撤销这一套流程。这篇内容把这些高频命令按场景重新梳理一遍把每条命令在什么情况下用、执行后会发生什么、底层对应 Git 的哪个机制都讲清楚适合刚开始用 Git 的开发者也适合用了一阵子但命令还比较模糊的人快速查漏补缺。1. 内容整体设计与思路拆解1.1 核心场景拆解提交、日志、回退、撤销到底对应什么工作流在聊具体命令之前先把思维模型理清楚。Git 之所以让新手困惑是因为它有一套工作区——暂存区——本地仓库——远程仓库的分层概念大多数常用命令其实就是在这些区域之间搬运内容。提交commit把工作区的代码固化到本地仓库形成一个新的提交记录。类似给当前进度拍一张快照方便以后回溯。查看日志log查看这些快照的列表了解项目历史、每次提交改了什么、是哪个时间点的状态。这是定位问题的基础。版本回退reset/revert回到之前的某个快照或者放弃当前的改动。典型场景是改了代码觉得不行想退回上一版或某个稳定版本。文件撤销checkout/restore只针对单个或部分文件做还原把它恢复到某个版本的状态而不是整个项目整体跳转。把这四个场景串起来就是日常开发的完整闭环做功能 - 提交记录 - 出问题 - 看日志找位置 - 回退或撤销解决。剩下的命令如 branch、merge、remote 等都是在这个闭环之外的配套工具。所以我个人强烈建议新手学习 Git 不用面面俱到先把这四条主线上的命令吃透就能应付工作中绝大多数场景。这篇内容也围绕这四个方向来展开同时补充一些配套的配置和排查经验。1.2 从热搜词看 Git 实际使用中的高频需求平时从各种平台收集到的 Git 相关提问最集中的几个方向其实很能说明问题安装和配置相关Windows 装 Git、git 无法识别命令、配置文件在哪、怎么设置提交者信息。提交相关怎么提交代码、提交规范写什么、提交到远程仓库失败比如 push -u origin main 一直提交不上去。日志相关怎么看提交记录、怎么查看具体某次提交改了什么、服务器日志怎么看。回退和撤销相关怎么回退版本并重新提交、git pull 操作后如何撤销但不影响未 commit 的文件、误 add 了文件怎么撤销。这些高频问题恰好都落在我要讲的四个核心场景里。这篇内容会把这些问题融入对应章节不只是列命令还把操作后的结果讲清楚。例如git pull 撤销但不能影响未 commit 的文件这个问题核心在于区分本地工作区和暂存区的状态理解了分层机制后很自然就能明白该怎么处理。2. Git 安装与基础配置动手之前把环境搞定2.1 Git 安装的常见方式和版本选择虽然标题写的是常用命令大全但安装和配置是所有命令的前置条件。这一块其实没什么高深的就是几个注意点。Windows 用户比较省事的做法是下载安装包一路 Next 到底。需要注意安装过程中有两个选择点一是调整 PATH 环境变量时选 Git from the command line and also from 3rd-party software这样在 CMD、PowerShell 里都能直接用 git 命令二是行结束符转化建议选第一个Checkout Windows-style, commit Unix-style这会避免很多团队协作时 CRLF/LF 不一致导致的奇怪 diff。macOS 用户如果是新机器建议先装 Homebrew然后brew install git版本会比系统自带的旧版新很多。Linux 用户一般用系统包管理器比如 Ubuntu/Debian 下apt install gitCentOS/RHEL 下yum install git。装完之后有个验证操作很关键在终端里执行git --version如果能正常输出版本号说明安装成功。如果提示无法识别 git 项大概率是 PATH 配置问题Windows 用户检查一下是否在安装时勾选了加入 PATH 的选项如果装完之后才碰到把 Git 安装目录下的 cmd 文件夹加进系统环境变量即可。提示Mac 用户如果之前装过 Xcode系统里可能自带 git但版本很老。运行git --version输出的版本如果小于 2.20建议用 Homebrew 装新版老版本在处理一些新仓库的协议和配置时会出现奇怪问题。2.2 全局配置设置好你是谁和默认行为Git 提交记录里会显示提交者的用户名和邮箱这是通过全局配置完成的。第一次装完 Git 后一定要执行下面三条命令git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global push.default simpleuser.name 和 user.email 会写进每一次 commit 记录里团队协作时如果设置错代码提交记录上显示的名字就不对后续修正也比较麻烦。所以建议第一次使用就设置好。push.default 设置为 simple 是防止 push 时出现歧义。Git 2.0 之后默认就是 simple但很多老项目或老教程里还写着 matching这里显式设置一下更稳妥。查看已设置的配置项可以执行git config --list或单独查看某个配置如git config user.name。配置文件位置在用户主目录下的.gitconfig文件手动编辑也可以但推荐先用命令不容易写错格式。另外还有几个高频配置值得顺手设置# 提交时自动转换行尾 git config --global core.autocrlf true # 设置默认编辑器 git config --global core.editor vim # 开启颜色显示便于查看日志 git config --global color.ui true2.3 初始化仓库与连接远程仓库配置完成后就可以创建仓库了。本地已经有一个项目文件夹时在文件夹里执行git init这个命令会在当前目录生成一个隐藏的.git文件夹Git 的所有版本信息都存在这里。此时执行git status会看到当前目录下所有文件都是未跟踪untracked状态之后提交命令才能正常工作。如果需要连接远程仓库比如 GitHub、Gitee 或公司内部 GitLab执行git remote add origin 仓库地址查看远程仓库配置用git remote -v。远程库名称默认是 origin也可以自定义但没人会没事改名统一用 origin 就好。3. 提交代码把改动正式纳管3.1 git status每一次提交前的照妖镜提交代码前一定要先看状态这是我在各种场景下一遍遍强调的。git status会告诉你有哪些文件被修改过、哪些是新文件没被跟踪、当前处于哪个分支。比如执行结果会显示Changes not staged for commit: (use git add file... to update what will be committed) modified: src/main.js Untracked files: (use git add file... to include in what will be committed) README.md这个输出把工作区和暂存区的关系展示得很直观modified 表示已跟踪文件发生了改动但还没进入暂存区Untracked 表示 Git 从未跟踪过这个新文件。养成每次提交前先git status的习惯能避免很多误提、漏提的问题。注意git status显示的只是状态概览想看具体改了什么内容需要用git diff。两者配合使用一个告诉你有变化一个告诉你变化是什么。3.2 暂存区的概念与 git addGit 的提交不是直接把手头文件一股脑写进仓库中间隔着一层暂存区staging area。git add就是把文件改动从工作区放入暂存区之后再执行 commit 时打包进入仓库的是暂存区里的内容而不是工作区的全部内容。常用方式# 添加单个文件 git add src/main.js # 添加所有改动文件 git add . # 或 git add -A # 添加指定目录下所有改动 git add src/git add .和git add -A的区别在于处理文件删除的方式。简单说git add -A会跟踪所有改动包括删除更适合全局提交场景git add .在某些 Git 版本中行为略有差异。为避免混淆提交全部改动时我会直接用git add -A语义更明确。这个步骤很关键而且容易出现一个经典问题add 错了文件怎么办这个留到文件撤销章节详细讲。3.3 git commit提交信息的规范与常见参数暂存区的内容准备好后执行提交git commit -m 这里是提交说明-m直接在命令行里写提交信息不需要打开编辑器。如果忘了加-mGit 会打开默认编辑器让你输入提交信息很多人第一次用时会卡在 vim 界面不知道怎么退出所以建议还是习惯用-m参数。提交信息规范值得好好说一下。很多团队对提交信息有要求比较常见的是 Conventional Commits 风格格式大致如下feat(用户模块): 新增用户注册功能 fix(购物车): 修复数量不更新问题 docs(README): 更新环境变量说明 chore(deps): 升级依赖版本type 部分常见的有 feat新功能、fix修复、docs文档、style格式调整、refactor重构、test测试、chore构建或工具变动。scope 是可选的范围说明这次改动影响哪个模块。这样写的好处是生成的日志一眼就能看出每次提交的目的也方便后续自动化工具做版本记录。还有两个高频提交参数# 把暂存区内容合并进上一条提交适合改完忘带了几个文件的情况 git commit --amend # 跳过暂存步骤直接提交所有跟踪文件的改动不影响未跟踪新文件 git commit -am 提交说明--amend这个命令非常实用但也很危险。它会把当前暂存区内容合并进最近一条提交同时可以修改最近一条提交的说明。但要注意它本质是重写历史如果这条提交已经 push 到了远程且团队其他人已经拉取过此时再做 amend 会导致提交记录与远程不一致push 时会冲突。所以 amend 只推荐用在还没推送到远程的本机提交上。3.4 提交到远程仓库push 与经典失败场景本地提交完成后如果要与团队同步需要推送到远程# 首次推送并建立上游关联 git push -u origin main # 后续直接推送 git push-u的作用是设置 upstream上游分支执行一次后当前本地分支与远程 main 分支的关联就记住了以后不用再带参数直接git push即可。经常有人遇到git push -u origin main一直提交不上去的情况网上求助帖子也特别多。其实失败原因就那么几类网络问题无法访问远程仓库地址。内网环境需要检查代理设置。权限问题没有推送权限SSH key 未配置或失效。非 fast-forward远程分支比本地分支领先需要先git pull同步。分支名不对远程没有 main 分支而是 master。判断方法很简单先看git remote -v确认远程地址对不对再试git pull看是否需要先合并再看报错信息是认证失败还是分支落后。non-fast-forward 这类提示通常意味着你先git pull --rebase拉取一次合并即可解决。4. 查看日志理解每次提交的历史脉络4.1 git log 基础用法与输出解读提交是留下了但如果不知道怎么看提交历史版本管理和回溯就无从谈起。git log就是查看提交历史的命令它按照时间倒序列出所有提交格式类似commit 1e4b2d880f8a6c7d30e33a6df32c4a1e1e2f7c9a (HEAD - main) Author: zhangsan zhangsanexample.com Date: Tue Nov 21 10:30:45 2024 0800 新增用户注册功能每次提交输出一组信息commit 后面那串长字符串是提交的唯一 IDSHA-1 哈希值HEAD - main表示当前所在分支及位置Author 是提交者Date 是提交时间下面是提交信息。默认的git log输出内容很多提交多了以后一屏一屏翻看起来很累。实际工作中更推荐用简写模式git log --oneline这样每条提交只显示一行短提交 ID 和提交信息。信息密度高很多一屏能看几十条记录。git log --oneline -n 10-n参数控制显示条数只看最近 10 条提交。这个习惯非常好用进一个陌生项目先看一眼最近提交就知道这个项目最近在做什么、提交是否规范。4.2 图形化看分支--graph 与 --all 的搭配如果项目里分支比较多或者想了解提交历史的分支走向强烈建议用这个组合git log --oneline --graph --all--graph会用 ASCII 字符画出提交历史的分支走向--all显示所有分支不只是当前分支。用这个命令能看到类似下面的输出* 3f9a2d1 (feature/login) 新增登录页面 * 2b8c4e7 修复用户信息接口异常 * | * 5e7a1c8 (main) 更新首页文案 * |/ * 1e4b2d8 初始化项目这个输出能很直观地看出 main 分支和 feature 分支在哪里分叉、各自提交了什么。代码 Review 和排查问题时尤其有用。4.3 查看某次提交的具体改动git show 与 git diffgit log解决的是有哪些提交的问题但每次提交具体改了哪些内容需要另外两条命令配合。查看最新一条提交改了什么git show查看具体某次提交改了什么用提交 IDgit show 1e4b2d8这个命令的输出包含了这次提交的完整 diff哪些文件被修改、每个文件里具体增删了哪些行。新增的行前面是加号删除的行前面是减号。如果想比较两个提交之间的差异用git diff# 比较最近一条提交和上一条提交 git diff HEAD~1 HEAD # 比较两个指定提交 git diff a1b2c3d e4f5a6b # 只比较某个文件的差异 git diff HEAD~1 HEAD -- src/main.jsgit diff默认比较工作区和暂存区的内容差异。比如你改了一个文件但还没 add执行git diff会显示你的修改内容如果已经 add 了再执行git diff反而不显示任何内容因为此时工作区和暂存区已经一致。这又是一个容易混淆的点理解了分层机制就不会乱。4.4 日志查看的实用变体按作者、按时间、搜索提交有几个日志过滤方式很实用# 查看某个作者的提交 git log --authorzhangsan # 按时间过滤最近两周的提交 git log --since2.weeks # 按提交信息关键字搜索 git log --grep修复 # 查看某个文件的所有提交 git log -- src/main.js按文件查看提交历史这个功能特别实用。有时候一个文件被多个人频繁改动出问题时你想知道这个文件最近被谁动过、都改了些什么一条命令就能查清楚。实操心得结合git log --oneline -n 20和git show两个命令基本就能解决 90% 的查历史需求。前者快速定位提交后者深入查看内容改动不用记太多复杂参数。5. 版本回退回到历史中的任意时刻5.1 HEAD 指针与相对引用回退的基础概念版本回退的核心是理解 HEAD 的含义。HEAD 是一个指针指向当前分支的最新提交。你可以把它理解成你现在站在哪个位置。当执行提交后HEAD 会移动到最新的提交上。回退版本的本质就是移动 HEAD 指针让它指到历史中的某个提交。相对引用是回退时常用的简写HEAD表示当前提交HEAD~1或HEAD^表示上一个提交HEAD~2表示上两个提交查看当前 HEAD 指向的位置git log --oneline -1 # 或直接 git rev-parse HEAD5.2 reset 的三种模式--soft、--mixed、--hardgit reset是版本回退的主力命令但它有三种模式区别在于回退时如何处理暂存区和工作区。这是 Git 命令里最容易搞混的点之一也是网上提问率最高的地方。假设当前状态提交历史是 A - B - CHEAD 指向 C。现在想回到 B。命令格式git reset --soft HEAD~1 # 回到 B但保留 C 的改动在暂存区 git reset --mixed HEAD~1 # 回到 B但保留 C 的改动在工作区默认模式 git reset --hard HEAD~1 # 回到 B彻底丢弃 C 的所有改动三种模式的核心区别如下表模式HEAD 指向暂存区内容工作区内容适用场景--soft回退到 B保留 C 的改动保留 C 的改动只想撤销 commit保留所有改动重新提交--mixed默认回退到 B清空保留 C 的改动撤销 commit 和 add保留改动重新整理--hard回退到 B清空丢弃 C 的改动彻底放弃改动回到干净状态注意 reset 默认不接参数时是--mixed即只回退 HEAD 和暂存区工作区文件内容不会动。这也是为什么很多教程里说 reset 不会丢改动 的前提是别用--hard模式。实际工作场景中最常见的需求是我刚提交的这版代码有问题想撤销这次提交但代码改动还想保留因为问题不大。这种情况用git reset --soft HEAD~1执行后提交记录回到提交前的状态所有改动还留在暂存区可以直接修改后重新提交。如果只是想撤销 commit 但重新权衡哪些文件应该提交用默认的 mixed 模式所有改动回到工作区重新 add 即可。5.3 回退之后怎么提交到远程强制推送与风险提示本地回退之后如果这个提交已经 push 到远程仓库了需要强推才能让远程也回退git push --force或者更安全的写法git push --force-with-lease--force-with-lease相比--force更安全它会检查远程分支是否还是你本地记录的那个位置如果期间团队其他人推了新提交它会拒绝推送避免把别人的提交覆盖掉。这也是我强烈推荐的方式。不过这里要特别提醒强制推送会改写远程仓库的历史影响所有同事。如果是在团队公共分支上操作请务必先和团队确认沟通。一般来说遵循一个原则你自己创建的功能分支还没和别人协同开发可以放心 force pushmain 这种共享分支尽量别用 force而是用下面要讲的 revert。5.4 git revert不删历史只做反向提交与 reset 不同还有一种回退方式叫 revert。它的做法不是把 HEAD 移回过去而是创建一个反向提交——把目标提交的改动全部撤销形成一个新的提交记录。# 撤销某次提交并生成新的提交 git revert 1e4b2d8 # 撤销但不自动生成提交先看效果 git revert -n 1e4b2d8这么做的最大好处是保留完整的历史轨迹不改写已有提交记录。在多人的公共分支上用 revert 比 reset 安全得多因为不需要强制推送。两者的取舍很明确对比维度git resetgit revert历史记录会删除/改写历史保留历史新增反向提交对远程影响需要强推正常推送适用场景本地未推送的提交已推送到公共分支的提交协作安全低高实操心得我自己内部有个判断标准——提交还没推送到远程随便 reset推送了但只有自己在用分支可以考虑 reset 加强推推到了公共分支一律 revert。宁可多一条提交记录也不能给别人制造棘手的合并冲突。6. 文件撤销只针对特定文件的后悔药6.1 撤销工作区改动git checkout 与 git restore版本回退针对的是整个项目的提交记录但日常工作中更常见的场景是某个文件改了几行发现改错了想还原。这时候不需要动提交记录只需要调整文件内容。还没 add 的改动即改动只存在于工作区可以执行git checkout -- src/main.js或新版命令git restore src/main.js两者效果一样都是把工作区中指定文件恢复到暂存区或 HEAD 的状态。区别在于git restore是 Git 2.23 引入的新命令语义更明确更推荐。一定要特别注意这个操作会直接丢弃工作区的改动且无法恢复。执行前确认文件里没有你要保留的代码最好先用git diff src/main.js看看改了什么再决定。如果整个目录都想还原git restore .同样会丢失本目录下所有未提交的工作区改动慎用。6.2 撤销暂存区内容add 错了怎么办如果执行了git add改动进入了暂存区但还没 commit此时想撤销有两种需求需求一保留工作区改动只是不暂存了git restore --staged src/main.js或老命令git reset HEAD src/main.js执行后文件会回到已修改但未暂存状态工作区内容不变。这也是解决我 add 错了文件的标准方式。需求二连工作区内容都还原掉git restore --staged --worktree src/main.js这个命令把暂存区和工作区同时重置文件完全回到 HEAD 的状态相当于撤销暂存 撤销工作区修改一步到位。使用前要确认不需要保留任何改动。6.3 版本回退后找回来reflog 终极后悔药前面说了git reset --hard会丢弃改动。如果误操作了真的找不回来吗其实还有一个隐藏的安全网git reflog。reflog 记录了 HEAD 指针的所有移动轨迹包括 reset、checkout、commit 等操作。即使 reset --hard 回了旧提交reflog 里依然能找到刚才 HEAD 的位置。git reflog输出类似1e4b2d8 (HEAD - main) HEAD{0}: commit: 新增用户注册功能 2b8c4e7 HEAD{1}: commit: 修复登录接口 5e7a1c8 HEAD{2}: commit: 初始化项目假设执行了git reset --hard 5e7a1c8想撤回 1e4b2d8 的提交但后悔了此时用 reflog 找到 1e4b2d8 所在的行执行git reset --hard 1e4b2d8就能恢复回去。这个命令相当于 Git 的时光机档案只要不 gc垃圾回收清空就能找回大部分误操作丢失的提交。注意reflog 不是万能的它记录的是本地仓库的 HEAD 移动历史如果操作后执行了git gc且提交长时间未被引用有可能会被清理掉。但它绝对是 reset 误操作后的第一救命稻草。我个人每次搞砸之后第一反应就是开 reflog 查位置。6.4 git pull 之后想撤销又不影响未 commit 的文件这是实践中一个很容易踩坑的场景。执行git pull把远程最新代码拉下来后发现合并结果不满意想撤销但本地还有一堆没提交的改动要保留。首先明确一点git pull本质是git fetch加git merge。如果本地有未提交的改动git pull可能直接失败提示 Your local changes would be overwritten也可能因为合并冲突把工作区弄乱。如果只是想撤销 pull 导致的合并同时保留本地未 commit 的改动可以用# 查看 pull 前的 HEAD 位置 git reflog # 回退到合并前的状态保留工作区改动 git reset --mixed HEAD{1}这里用--mixed而不是--hard这样本地未提交的改动都能留在工作区而合并引入的提交被撤销。这也是 reflog 在真实场景中的典型用法。如果 pull 之后只想抛弃远程更新、回到拉取前的本地状态git reset --hard HEAD{1}但注意--hard会连同工作区未 commit 的改动一起丢掉。所以在操作之前一定要确认好哪些改动需要保留必要时先把文件复制一份或者用git stash暂存起来。6.5 临时保存与恢复stash 的巧用讲到撤销顺带提一个非常实用的配套命令stash。当你在一个分支上改到一半突然需要切换到其他分支修复 bug但又不想提交当前的半成品这时用 stash 把工作区改动临时保存起来git stash list # 查看暂存列表 git stash push -m 临时保存说明 # 保存并清理工作区 git stash pop # 恢复最近一次暂存的内容 git stash apply stash{0} # 恢复指定暂存但不清除列表这个命令和撤销的关系在于它是一个安全的临时保存工具。在打算执行可能破坏工作区的操作比如 reset --hard、pull 合并冲突之前先把已有改动git stash保存起来操作完再stash pop恢复能在一定程度上避免回退时误丢改动的问题。7. 常见 Git 问题排查与实用技巧速查7.1 高频报错与对应解法收集一下实际工作中见过的最常见 Git 报错和对应处理方式报错信息原因处理方式unable to access... Could not resolve host网络不通或代理问题检查网络配置 proxy 或取消 proxyPermission denied (publickey)SSH 密钥未配置或失效重新生成 SSH key 并添加到远程仓库Non-fast-forward远程有本地没有的提交先git pull --rebase再 pushYou have not concluded your merge合并冲突未解决解决冲突后提交或执行git merge --abortYour local changes would be overwrittenpull/checkout 会覆盖工作区改动stash 或 commit 工作区改动后再操作pathspec did not match any files文件路径写错或该路径无此内容核对路径用git status查看实际文件位置这些报错信息看起来很吓人但本质上都是 Git 在保护你的数据提示操作会导致某些状态不一致。读懂信息比背命令有用得多。7.2 一个完整的事故处理流程演示用一个真实发生的场景串联整套命令。假设你接到一个任务要求在 main 分支上修复一个 bug。完成代码后执行了git add -A git commit -m fix: 修复缓存穿透问题提交后发现代码在本地测试时反而出现了更严重的问题。此时需求是撤销这次提交但保留改动分析原因。执行git log --oneline -3 git reset --soft HEAD~1此时提交被撤销所有改动留在暂存区。分析后发现是某一行的逻辑写错了想先修改一下于是git restore --staged src/bugfile.js # 把该文件撤出暂存区修改文件后git add src/bugfile.js git commit -m fix: 修复缓存穿透问题调整失效时间判断但如果修完之后决定这版方案整体放弃改回原来的代码逻辑。此时改动还在工作区直接git restore . # 丢弃所有未提交的工作区改动如果已经提交了多次发现都错了干脆回到提交前的状态git reflog # 找到目标提交 git reset --hard 目标提交ID这套流程覆盖了提交、看日志、回退、撤销四大主题实际操作中随时可能在不同步骤间切换。7.3 日常使用建议与防坑经验最后分享几个实际使用中总结的习惯第一个是提交前先git statusgit diff双确认。status 看有没有不该提交的文件比如本地配置文件、临时文件diff 看改动内容是否符合预期。这个习惯能拦下 90% 的误提交。第二个是给提交信息起名时遵循统一规范。团队没有硬性规定的话feat/fix/docs 这个前缀体系绝对够用关键是保持一致性。日志好不好看、日后搜索是否方便全看这一步。第三个是不要轻易在公共分支上 force push。出错之后解决问题可以但要考虑团队成员的心理阴影面积。revert 多生成一条提交记录代价远低于别人 pull 下来发现历史被改写的混乱。第四个是理解命令的底层机制不要死记硬背。Git 的分层模型工作区-暂存区-本地仓库-远程仓库搞明白后你会发现自己能推导出 80% 的命令。比如想撤销暂存区就找操作暂存区的命令想撤销提交记录就找操作 HEAD 的命令。思路通了命令自然记住了。以上这些内容基本覆盖了日常开发中 Git 的高频使用场景。最后再分享一个小技巧如果对某个命令的后果不确定可以先用git help 命令查看帮助文档或者在测试仓库里先演练一遍。搭建一个本地临时仓库的成本很低用真实项目练手出错的风险却很高。多操作几次多踩几个坑Git 这套命令体系慢慢就内化成肌肉记忆了。