Git 是我每天敲得最多的几个命令之一。说实话Git 命令本身不难背难的是你遇到具体场景时不知道用哪一条想撤销又不想丢代码、分支合坏了、提交信息写错了、stash 了一堆临时改动却忘了怎么恢复……这些事几乎每个开发者都撞见过。这份速查手册按“安装配置、日常闭环、撤销回滚、分支合并、工程化进阶、问题排查”六个维度整理覆盖从新手到老手都能直接用的高频命令附上参数含义和我在实际项目里踩过的坑建议直接收藏当操作手册翻。1. 先把Git装好配好安装、验证与免密配置很多命令敲不下去不是不会敲是环境和身份没搞定。第一步把 Git 装好、身份配好、免密做好后面所有操作才能顺起来。1.1 安装与版本验证不同系统的安装方式不同但装完之后验证方法是一致的。Windows推荐从 Git 官网下载安装包或用 winget 直接装winget install --id Git.Git -e --source winget。安装时建议勾选“将 Git 添加到 PATH”这样在 CMD 和 PowerShell 里都能直接调用。macOS用 Homebrew 最省事brew install git。没有 Homebrew 就直接下载安装包注意 macOS 会校验签名。LinuxDebian/Ubuntusudo apt install git。CentOS/RHEL 系列用sudo yum install git。装完先验证版本git --version git -C /path/to/repo status第二句里的-C是被低估的参数不用先cd进仓库目录直接指定仓库路径执行命令写脚本的时候特别好用。提示装完 Git 之后第一件事不是建仓库而是确认命令在终端里能直接识别。Windows 上如果提示“git 不是内部或外部命令”大概率是安装时没勾选 PATH重装一次勾上即可。1.2 全局身份配置每次提交都离不开它Git 每次提交都会记录 author 信息这个信息来自user.name和user.email配置。没配的话commit 的时候 Git 会用主机名猜一个提交历史里就会出现一堆乱七八糟的作者名。git config --global user.name 你的名字 git config --global user.email youexample.com git config --global init.defaultBranch main第三行把默认分支名从 master 改成 main这是近几年社区的共识做法新建仓库时自动用 main省得后面再改。查看当前全局配置git config --list --global如果想单独给某个仓库设置不同的身份比如公司项目用公司邮箱、个人项目用私人邮箱进到仓库目录里去掉--global执行同样的命令即可。也可以设置条件配置按目录自动切换git config --global includeIf.gitdir:~/work/.path ~/.gitconfig-work这种方式适合一个人同时维护多套身份的场景配一次之后就不用每次手动切了。1.3 免密配置告别每次输入账号密码每次 push 都输密码非常影响心情而且密码还可能过期。免密通常有两种方式。HTTPS 场景下Windows 用 Git Credential ManagermacOS 用 keychainLinux 可以启用 credential cachegit config --global credential.helper store # 明文存盘适合个人电脑 git config --global credential.helper cache --timeout3600 # 缓存一小时适合临时用store 模式会把凭据写到~/.git-credentials明文存储多人共用电脑时别这么干。cache 模式只缓存一段时间到期重新输入更安全。SSH 场景下更推荐用密钥对。生成并添加公钥到代码托管平台后clone地址选 SSH 形式push 就不用密码ssh-keygen -t ed25519 -C youexample.com cat ~/.ssh/id_ed25519.pub把公钥内容粘贴到代码托管平台的 SSH Keys 设置里然后测试连接ssh -T gitgithub.com注意SSH 密钥的私钥文件~/.ssh/id_ed25519一定要保护好不要传到任何公共仓库或聊天工具里。泄露私钥等于把仓库写权限交给别人了。2. 日常高频命令从克隆到推送的完整闭环本地开发最常用的就是一个闭环拿代码、改代码、提交、推送、拉取更新。这部分命令是每天敲得最多的必须形成肌肉记忆。2.1 初始化与克隆拿到新项目要么 clone 已有仓库要么从零 initgit clone 仓库地址 git init 目录名clone 的时候有几个实用选项git clone --depth 1 地址浅克隆只拉取最新一次提交大仓库能省大量时间和磁盘。git clone --branch 分支名 地址直接切到指定分支。git clone --recurse-submodules 地址仓库带子模块时用一次全拉下来。init 之后通常会看到提示 “Initialized empty Git repository”然后需要自己添加远程地址git remote add origin 仓库地址 git remote -vremote -v用来确认远程地址是否正确尤其是检查拼写和协议类型。日常排查的时候我最先看的往往就是这一句输出。2.2 提交链路add、commit、status、diff本地改完代码第一件事是看状态git status这个命令的输出要会读Untracked files表示新文件还没被 Git 跟踪Changes not staged for commit表示文件被修改过但还没加入暂存区Changes to be committed表示已经git add过、等待提交。很多新手搞不清这里的状态其实记住一句话暂存区是提交前的“购物车”add 是把商品放进去commit 才是结算。加文件git add 文件名 # 加指定文件 git add . # 加当前目录所有改动慎用容易把临时文件一起加进去 git add -p # 交互式分段暂存只把大改动的一部分加入提交git add -p是我特别推荐的命令。你改了一个文件里的两处功能想分两次提交用这个命令就能逐块确认保持提交历史的颗粒度清晰。提交git commit -m feat: 增加用户登录接口提交前想看看到底改了啥用 diffgit diff # 工作区 vs 暂存区的差异 git diff --staged # 暂存区 vs 上次提交的差异2.3 分支管理并行开发的基础分支是 Git 最核心的武器。常用命令git branch # 查看本地分支 git branch -a # 查看本地和远程全部分支 git branch 新分支名 # 创建分支 git checkout -b 新分支名 # 创建并切换旧写法 git switch -c 新分支名 # 创建并切换新版推荐写法 git switch 分支名 # 切换分支 git branch -d 分支名 # 删除已合并的分支新旧命令并存的现状确实容易让人困惑我的建议是切换和创建统一用switch丢弃工作区改动统一用restore语义更清晰。checkout是老伙计你迟早会用到但新项目里尽量用语义更明确的命令。分支命名建议直接带上用途比如feature/payment、fix/login-bug一看就知道这个分支在干嘛。多人协作时分支名就是沟通的一部分起得清楚能省很多问话。2.4 远程协作push、pull 与 fetch代码提交到本地后要推送到远程git push origin 分支名 git push -u origin 分支名 # 第一次推送时加 -u把本地分支与远程分支关联起来加了-u之后后续直接git push就行不用再写远程名和分支名。如果是第一次推送新分支不加-u会提示你“当前分支没有跟踪信息”按提示加上即可。拉取远程更新git pull origin 分支名 git fetch originpull等于fetchmerge先取回远程提交再和本地合并。fetch只是把远程提交取到本地不会动你正在工作的分支。需要确认远程改了什么、要不要合时先git fetch再手动git merge origin/main更稳。提示执行git pull之前先确认本地工作区是干净的git status没问题。如果本地还有未提交的改动pull 引发的合并冲突会和你的本地改动搅在一起处理起来非常被动。IDE 或一些图形工具调用 Git 时偶尔会看到这样的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks status拆开看就明白了-c是临时指定配置项diff.mnemonicprefixfalse让差异比较使用标准前缀而不是符号前缀core.quotepathfalse让中文文件名正常显示而不是转成八进制--no-optional-locks则禁止 Git 在执行命令时获取可选锁避免和其他操作冲突。平时手敲不需要加这些但看懂它们能帮你判断 IDE 到底在你背后做了什么。3. 撤销与回滚历史操作的后悔药怎么吃撤销是 Git 进阶的分水岭。新手怕撤销因为不知道会不会把代码弄丢老手敢撤销因为知道每一层都有对应的“后悔药”。3.1 三种状态的撤销工作区、暂存区、已提交按改动所在的位置撤销姿势完全不同。工作区有改动、还没 add 时想丢弃改动git restore 文件名 # 丢弃工作区改动 git restore . # 丢弃当前目录下所有未暂存改动已经 add 进暂存区了想撤销暂存但保留工作区改动git restore --staged 文件名已经 commit 了想回退到之前的某个版本用 reset。reset 有三种模式很多人背不住我用一张表记它模式移动 HEAD重置暂存区重置工作区使用场景--soft是否否提交信息写错了想重新提交--mixed是是否想把已提交的改动拆成多个提交--hard是是是彻底丢弃某次提交之后的全部改动git reset --soft HEAD~1 # 撤销最近一次提交但保留改动到暂存区 git reset --mixed HEAD~1 # 撤销最近一次提交保留改动到工作区默认 git reset --hard HEAD~1 # 撤销最近一次提交连改动一起删除HEAD~1表示上一个提交HEAD~2表示上两个提交也可以用提交哈希值直接指定目标版本。3.2 补救提交信息amend 与交互式 rebase提交完发现 commit message 写错了或者漏了一个文件可以用git commit --amend -m 修正后的提交信息amend 会把上一次提交替换成新的提交适合“上一次提交还没推送到远程”的时候用。如果已经 push 到远程并且别人已拉取过amend 会改写提交哈希导致别人的分支出现分叉这时候别用 amend老老实实新增一个提交。如果想重排历史、合并多个提交用交互式 rebasegit rebase -i HEAD~3执行后会弹出编辑器列出最近三次提交每个提交前面有pick关键字。把pick改成squash缩写s就可以把多个提交压成一个。rewordr可以只改提交信息。改完保存退出Git 会按你的指令重放提交。注意rebase 是改写历史只对尚未推送的提交使用。已经推送到公共远程分支的提交千万不要 rebase否则同事会恨你。3.3 历史查看log 的高级姿势git log是最常用的历史命令但很多人只会裸敲。推荐几个组合git log --oneline --graph --decorate --all git log --oneline --author你的名字 --since2024-01-01 git log --oneline --grepfeat git show commit哈希 # 查看某次提交的完整改动 git blame 文件名 # 逐行查看每个文件行的最后修改者是谁--graph会画出分支图--all显示所有分支--decorate标注分支和标签。排查问题时我习惯先git log --oneline --graph看整体走向再git show看具体提交。git blame在追查“这行代码是谁加的、为什么加”的时候非常有用Code Review 和 Bug 定位都靠它。3.4 stash 临时保存改到一半要切分支手头改了一半还没写完不能提交但需要马上切换分支处理紧急事情。git stash就是为这个场景生的git stash push -m 微信支付功能开发中 git stash list # 查看 stash 列表 git stash pop # 恢复最近一次 stash 并删除它 git stash apply # 恢复但保留 stash git stash drop stash{0} # 删除指定 stashstash 栈是后进先出pop恢复的是最近一次push的。如果多个 stash 并存记得先git stash list确认编号再apply stash{2}避免恢复错版本。经验stash 的备注信息一定写清楚-m 支付模块比默认的 “WIP on main” 直观太多。我见过同事 stash 了四五条最后全凭猜恢复错了又是一顿合并冲突。4. 分支合并与冲突解决协作实战中最容易翻车的环节分支合并是 Git 日常里最精彩的环节。新手看到冲突提示就慌其实冲突的本质就是“你和别人改到了同一块地方”解决思路是清晰的按步骤来就行。4.1 Merge 与 Rebase两种合并思路怎么选合并分支可以git merge也可以git rebase。两者都能把另一个分支的改动合进来但产生的历史结构完全不同。git merge 分支名 # 生成一个合并提交保留分支分叉 git rebase 分支名 # 把当前分支的提交“挪”到目标分支上方历史是一条直线我个人的默认策略是公共分支、共享分支上的合入操作用 merge不改写已有历史。个人功能分支想要同步主分支的新改动用 rebase保持功能分支的历史干净整洁。维度mergerebase历史形状有分叉和合并点线性像一条直线是否改写提交不改写改写当前分支提交的哈希安全性安全适合公共分支有风险禁止改写已推送的提交解决冲突体验合并时解决一次每个提交重放时都可能冲突4.2 冲突解决完整流程假设你在feature/payment上开发执行git merge main终端提示CONFLICT (content): Merge conflict in src/OrderService.java Automatic merge failed; fix conflicts and then commit the result.冲突文件里会出现这样的标记 HEAD 当前分支的代码 被合并分支的代码 main解决步骤用编辑器打开冲突文件和之间就是冲突区域。手动整理成最终想保留的代码删除三组标记。逐个文件处理完后git add标记为已解决。执行git commit完成合并提交。git status # 列出所有冲突文件 git add 冲突文件 git commit -m merge: 合并 main 到 feature/payment如果合到一半发现冲突太多、后悔了想放弃这次合并git merge --abort这个命令会把仓库恢复到合并前的状态非常安全放心用。提示解决冲突时改完后跑一遍测试再提交。冲突解决的错是最隐蔽的两边代码在语法上合并成功了但逻辑上可能互相矛盾。我见过最贵的 Bug 就是冲突解决时删掉了边界判断上线才炸。4.3 常用扩展cherry-pick、tag 与 reflog有些场景不常用但一用就能救命。只想把另一个分支的某一次提交拿过来git cherry-pick commit哈希比如线上分支有个热修提交feature 分支也想带上不用整个 mergecherry-pick精准拿一次提交就行。打版本标签git tag v1.2.0 git tag -a v1.2.0 -m 发布1.2.0版本 # 带附加信息的标签 git push origin v1.2.0 # 标签默认不随 push 上传要单独推最后是终极大杀器git reflog。只要本地仓库没被删除几乎所有误操作都能用 reflog 救回来git reflog这个命令会列出 HEAD 指针的所有历史移动记录包括 reset、rebase、checkout 等操作。哪怕你git reset --hard把提交弄丢了也能从 reflog 里找到之前的 HEAD 位置然后git reset --hard 哈希恢复。git reflog # 找到丢失前的位置比如 abc1234 git reset --hard abc1234我建议所有开发者把 reflog 记到脑子里Git 不是销毁式工具reflog 是你最后的后悔药。5. 工程化进阶提交规范、子模块与仓库维护单打独斗时命令够用就行但一旦进入团队协作约定和规范比命令行技巧更重要。这部分的重点是让 Git 在多人场景下不乱套。5.1 提交信息规范让历史变成可读文档提交信息写得好不好直接决定几个月后你查历史时是爽还是骂娘。推荐业界通用的 Conventional Commits 规范。格式是type(scope): subject类型前缀是核心feat新功能fix修复 Bugdocs文档变更style代码格式调整不影响逻辑refactor重构不新增功能也不修 Bugperf性能优化test测试相关build构建系统或依赖变更ciCI 配置变更chore杂项比如工具配置改动revert回滚某次提交示例feat(auth): 增加手机号登录接口 fix(order): 修复未支付订单被重复取消的问题 docs(readme): 补充本地开发环境搭建说明这套规范的价值在于按类型扫git log --grep^feat就能生成功能清单按^fix能定位线上变更配合工具还能自动生成 CHANGELOG。团队里统一这套格式历史记录就成了项目文档的一部分。5.2 子模块与 LFS 的适用场景项目里需要同时引用另一个仓库的代码可以用子模块git submodule add 仓库地址 目录 git submodule update --init --recursive # 克隆后初始化子模块子模块是把另一个 repo 的某个提交作为目录嵌入当前仓库适合“多仓库联动但各自独立版本”的场景。但子模块的坑也不少主仓库切换分支时子模块容易停留在旧版本新手经常忘了git submodule update。如果项目没那么复杂优先考虑包管理器如 npm、Maven、Go Modules来管理依赖会比子模块省心。大文件设计稿、数据集、二进制包别直接往仓库里塞。Git 对文本文件的差分能力一流对二进制大文件只会越存越大。推荐在仓库里直接塞大文件之前先想想是不是真的需要进版本控制。真需要的话可以考虑 Git LFSgit lfs install git lfs track *.psd git add .gitattributes git commit -m chore: 用 LFS 跟踪设计文件5.3 仓库维护清理、优化与安全检查仓库用了几年后.git目录可能膨胀到几百 MB。定期做清理git gc --prunenow # 清理冗余对象 git prune # 删除无引用的对象 git clean -f # 删除未跟踪的文件加 -d 可删未跟踪目录git clean威力很大git clean -fdx会连.gitignore里忽略的文件一起删执行前先git clean -n看预览确认要删哪些再动手。想彻底从历史中移除某个大文件或敏感信息用git filter-repo注意这是独立于 Git 的额外工具需要单独安装git filter-repo --path 大文件 --invert-paths git filter-repo --replace-text 替换规则文件这种操作会改写整个历史所有协作者都需要重新克隆只适合在团队确认后、仓库尚未有大量下游依赖时执行。6. 高频命令速查表与常见问题排查速查手册最后就该有一张能贴墙上的表。下面这个速查表按场景组织是我个人日常使用频率最高的命令集合。6.1 按场景整理的高频命令表场景命令说明初始化git init当前目录创建新仓库克隆git clone url克隆远端仓库查看状态git status查看工作区、暂存区状态暂存改动git add file加入暂存区提交git commit -m feat: xxx提交暂存区改动查看提交git log --oneline --graph图形化查看提交历史查看差异git diff工作区与暂存区对比创建分支git switch -c branch创建并切换分支切换分支git switch branch切换已有分支合并分支git merge branch合并指定分支到当前分支推送git push -u origin branch第一次推送并建立关联拉取git pull --rebase拉取远端并变基到当前分支撤销工作区git restore file丢弃未暂存改动撤销暂存git restore --staged file取消暂存回退提交git reset --hard HEAD~1回退到上一个提交慎用紧急保存git stash暂存当前未提交改动恢复暂存git stash pop恢复最近 stash标签git tag -a v1.0 -m msg打带注释的标签大杀器git reflog查看 HEAD 全部历史用于恢复丢失提交这张表只覆盖了高频命令但足够撑起一个日常开发从早到晚的工作流。6.2 典型问题与排查思路问题一git命令找不到Windows 上最常见的是 PATH 没配好。排查步骤先确认 Git 安装目录默认C:\Program Files\Git\cmd再把该目录加到系统 PATH。Mac/Linux 上检查是否装了 Git、是否正确引用了可执行文件路径。装好之后新开一个终端窗口再试。问题二提交里的中文显示成转义字符git config --global core.quotepath false设置之后git status和git log里的中文文件名就能正常显示不会变成八进制转义序列。问题三Linux 下提示 CRLF/LF 换行符警告这是 Windows 和 Linux 跨平台开发的经典问题。统一策略是git config --global core.autocrlf input # Linux/Mac git config --global core.autocrlf true # Windows原则是仓库内统一用 LFWindows 检出时转成 CRLF提交时转回 LF。团队应当在.gitattributes里固化这个规则而不是靠每个人自己配置。问题四误删分支后用git branch -d删错分支git reflog # 找到删除前的分支指向的提交哈希 git switch -c 恢复的分支名 哈希 # 重新创建分支并指向哈希分支在 reflog 里仍然保留记录只要操作时间距离现在不太远基本都能恢复。问题五提交信息写错了git commit --amend -m 正确的信息如果同时要补几个漏掉的文件先git add再git commit --amend --no-edit保留原信息只补充修改。问题六文件被 .gitignore 忽略了怎么确认git check-ignore -v 文件名这个命令会告诉你匹配的是哪条忽略规则。排查“为什么文件没被跟踪”非常有效比对着.gitignore猜规则快得多。问题七一个文件明明没改但git status显示改了多半是换行符或文件权限问题。先执行git diff看实际内容差异如果只改换行符用上面的core.autocrlf修复如果是权限变化检查filemode配置。6.3 我的几个使用习惯最后分享几个我个人的日常习惯也是踩了无数坑之后沉淀下来的。第一提交前先git diff --staged看一遍。很多时候能发现自己不小心把调试日志、临时文件一起 add 进去了。这个习惯比任何 Code Review 工具都前置能减少不少低级失误。第二git stash一定要写-m备注。我认识的大多数前端、后端小伙伴都有过 stash 了一堆却分不清哪个是哪个的经历。备注写清楚三秒定位不写就得凭感觉试错。第三遇到不熟悉的 Git 操作先在临时分支上试。比如git reset --hard、git rebase -i这类有破坏性的操作别直接在主分支上执行新建一个test/reset-playground分支随便试试完删掉不心疼。第四定期git fetch而不是每次都git pull。fetch只是把远程最新的提交拉到本地“视野”里不会动你的工作区。先看看别人改了什么再决定是merge还是rebase主动权在自己手里。盲目pull遇到冲突时手忙脚乱的概率非常高。第五也是最重要的一点别怕犯错Git 的容错能力很强。误删的提交有 reflog误改的文件有 restore误清的 stash 也有对应的恢复手段。越知道这些后退的本事往前走的时候就越敢下手。我见过太大一截时间都花在“不敢操作”上的开发者其实你完全没必要谨慎到寸步难行试错本身就是学 Git 最快的方式。