Git 常用命令速查表 — 50 条命令 + 实战示例
这份 Git 命令速查 把开发者日常 90% 场景要用到的 Git 命令按工作流分成 6 大类：配置与初始化、日常工作流（add / commit / push）、分支管理、撤销与回滚（git reset / git revert）、远程仓库、高级与排错（git rebase / git reflog）。每条命令都配了可直接复制的实战代码段和场景说明，文末还整理了 5 个最常被问到的 Git FAQ。无论你是刚学 版本控制 的新手，还是想系统复习 Git 工作流 的资深开发者，都能在这里 3 分钟查到答案。
1. 配置与初始化
第一次安装 Git 后第一件事就是配置用户信息——每一次 commit 都会带上这两个字段。配置分 --global（全局，存 ~/.gitconfig）和当前仓库（不加 --global，存 .git/config），建议把姓名邮箱设为 global，单个项目可单独覆盖。这是 Git 教程 永远绕不开的 5 条命令，也是 版本控制 入门第一步。
1.1 设置用户姓名和邮箱
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main加 --global 表示对当前用户所有仓库生效；不加则只对当前仓库生效（覆盖全局）。init.defaultBranch main 让 git init 默认分支名从老的 master 变成 main，和 GitHub 保持一致。
1.2 初始化与克隆
git init # 把当前目录变成 Git 仓库
git init my-project # 新建并初始化 my-project 目录
git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git # SSH 协议
git clone --depth 1 <url> # 浅克隆（只拉最近 1 次提交，省时间）git clone 会自动添加一个名为 origin 的远程仓库别名，并把远程 main 分支检出到本地。
1.3 设置常用别名（强烈推荐）
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'
git config --global alias.lg "log --oneline --graph --decorate -20"设置后 git co 等价于 git checkout、git st 等价于 git status，日积月累能省下大量输入。详见 FAQ。
1.4 Windows 行尾符问题（必看）
# macOS / Linux 推荐
git config --global core.autocrlf input
# Windows 推荐
git config --global core.autocrlf true
# 已污染仓库一次性修复
git rm --cached -r .
git reset --hardWindows 默认 CRLF、Linux/macOS 默认 LF，跨平台协作会触发整文件 "修改"。core.autocrlf 控制 Git 是否在 checkout / commit 时自动转换行尾符。
1.5 配置 SSH Key 推送到 GitHub
ssh-keygen -t ed25519 -C "you@example.com" # 生成密钥
cat ~/.ssh/id_ed25519.pub # 复制公钥到 GitHub Settings → SSH and GPG keys
ssh -T git@github.com # 测试连接，输出 "Hi xxx!" 即成功配好 SSH 之后所有 git push / git pull 都不用再输密码，比 HTTPS 协议更省事。
2. 日常工作流（核心）
这是 Git 工作流 的核心循环：改代码 → git add 暂存 → git commit 提交 → git push 推上去。一条提交从「工作区」到「本地仓库」到「远程仓库」要经过 3 个区：Working Directory、Staging Area（Index）、Repository。初学者最常搞混的也是这 3 个区，先记住下面这张图就够用 80% 的 Git 命令 场景。
git add git commit
工作区 ───────────▶ 暂存区 ────────▶ 本地仓库
▲ │ │
│ │ │
└──── git checkout ───┘ │
└───────────── git reset ─────────────────┘
│
│ git push
▼
远程仓库2.1 查看状态与变更
git status # 查看哪些文件被修改 / 暂存 / 未跟踪
git status -s # 简洁输出 ?? / M / A / D 等
git diff # 工作区 vs 暂存区（未 add 的修改）
git diff --staged # 暂存区 vs 最新 commit（已 add 未 commit）
git diff HEAD # 工作区 vs 最新 commit（所有未提交修改）
git log --oneline --graph -20 # 漂亮的提交历史（带分支图）
git log --stat # 每个 commit 改了哪些文件
git log -p file.txt # 某个文件的修改历史
git blame file.txt # 逐行显示谁在哪个 commit 改的2.2 暂存与提交
git add file.txt # 暂存单个文件
git add src/ # 暂存整个目录
git add . # 暂存所有变更（含新增）
git add -p # 交互式暂存（hunk 级别，适合大改）
git commit -m "feat: add login page" # 提交并写信息
git commit -am "fix: typo" # 跳过 add，直接提交已跟踪文件的修改
git commit --amend # 把这次提交合并到上一次（改信息 / 补文件）推荐 commit message 格式：<type>: <subject>，type 常用 feat / fix / docs / refactor / test / chore。配合 git commit -m 一行能写清楚动机，半年后回看 git log 不会一脸懵。
2.3 暂存工作区（git stash 救命场景）
git stash # 把当前未提交修改"打包"放到一边
git stash push -m "WIP: login" # 加注释，方便后面认领
git stash list # 查看所有 stash
git stash pop # 恢复最近一次 stash 并删除记录
git stash apply stash@{2} # 恢复指定 stash 但不删除
git stash drop stash@{0} # 删除某条 stash
git stash clear # 清空所有 stash经典场景：正在 feature/login 分支改到一半，线上 main 出了 bug 要紧急修复——先 git stash → git checkout main → 修完 → git checkout feature/login → git stash pop。
2.4 同步远程
git pull # = git fetch + git merge，等价于"拉取并合并"
git pull --rebase # = git fetch + git rebase，干净的线性历史
git push # 推送到默认远程 + 默认分支
git push origin feature/login # 推送到指定分支
git push -u origin main # -u 关联上游，以后直接 git push / git pull 即可2.5 fetch vs pull vs merge vs rebase
git fetch origin # 只下载远程最新提交，不动本地分支
git fetch --all --prune # 拉取所有远程，prune 删除已不存在的远程分支引用
git merge origin/main # 把 origin/main 合并到当前分支
git rebase origin/main # 把当前分支"重新播放"到 origin/main 之上git fetch 只更新远程跟踪分支，不改你本地代码；git pull = fetch + merge。多人协作同一分支时更推荐 git pull --rebase，避免不必要的 merge commit。
2.6 实战：完整 commit 提交流程
# 1. 拉取最新
git checkout main && git pull --rebase
# 2. 新建功能分支
git checkout -b feature/login
# 3. 改代码…
# 4. 看变更
git status
git diff
# 5. 暂存 + 提交
git add src/login.ts
git commit -m "feat(login): add email + password form"
# 6. 推送并建 PR
git push -u origin feature/login3. 分支管理
Git 分支管理 是 Git 命令 里性价比最高的一组——轻量、廉价、鼓励频繁创建。业界主流的 Git 工作流（Git Flow、GitHub Flow、Trunk-Based）本质上都是分支策略的不同取舍。下面 8 条命令覆盖 95% 的分支场景：创建、查看、切换、删除、合并。
3.1 查看分支
git branch # 列出本地分支（* 标当前）
git branch -a # 本地 + 远程分支
git branch -vv # 顺便显示上游跟踪分支和最新 commit
git branch --merged # 已合并到当前分支的分支（可安全删除）
git branch --no-merged # 未合并的（删之前要小心）3.2 创建与切换
git branch feature/login # 创建分支（不切换）
git checkout feature/login # 切换分支
git checkout -b feature/login # 创建并切换（最常用）
git checkout -b feature/login origin/main # 基于远程 main 创建新分支
git checkout - # 切回上一个分支（省去翻历史）
git switch feature/login # Git 2.23+ 新命令，语义更清晰
git switch -c feature/login # 等价于 checkout -bgit checkout 身兼多职（切换 / 恢复文件 / 检出远程），容易记混。Git 2.23+ 引入了 git switch（只管分支）和 git restore（只管文件），新项目推荐用。
3.3 删除与重命名
git branch -d feature/login # 安全删除（已合并才删得掉）
git branch -D feature/login # 强制删除（未合并也删，慎用）
git branch -m new-name # 当前分支改名
git branch -m old new # 把 old 改名为 new3.4 合并分支
git merge feature/login # 把 feature/login 合并到当前分支
git merge --no-ff feature/login # 禁用 fast-forward，保留分支轨迹
git merge --squash feature/login # 把整条分支压成一个 commit
git merge --abort # 合并冲突后放弃，回到合并前状态--no-ff 在 Git 分支管理 场景下很有用：即使能快进合并也强制产生一个 merge commit，git log --graph 能清晰看到"这条 feature 是哪天合进来的"。
3.5 实战：Feature Branch Workflow
# 1. 从 main 拉新分支
git checkout main && git pull
git checkout -b feature/cart
# 2. 多个 commit 推进
git add . && git commit -m "feat(cart): add item list"
git add . && git commit -m "feat(cart): add checkout button"
# 3. 保持与 main 同步（关键：未 push 前随便 rebase）
git fetch origin
git rebase origin/main
# 解决冲突后：git add . && git rebase --continue
# 4. 合回 main（GitHub 上提 PR 更推荐，这里演示命令行）
git checkout main
git merge --no-ff feature/cart
git push origin main
git branch -d feature/cart4. 撤销与回滚（必看）
这是 Git 命令 里最危险、也最被频繁搜索的一块。撤销的本质是「把 HEAD 指针、分支引用、暂存区、工作区中的某一个或几个回退到某个状态」。用错参数可能直接把未 push 的代码扔进黑洞——所以这一节请仔细看 三种 git reset 模式 的区别。
4.1 丢弃工作区修改（最安全）
git checkout -- file.txt # 丢弃 file.txt 的工作区修改（旧写法）
git restore file.txt # Git 2.23+ 推荐写法
git restore . # 丢弃所有工作区修改
git restore --staged file.txt # 把已暂存的文件撤回到工作区（不丢修改）⚠️ 警告：git checkout -- file 不可逆，文件修改会被永久丢弃。重要修改先 git stash。
4.2 取消暂存（不动工作区）
git reset HEAD file.txt # 取消暂存 file.txt（保留工作区修改）
git restore --staged file.txt # 同上，新写法
git reset # 取消所有暂存4.3 git reset 三种模式（核心）
git reset --soft HEAD~1 # 撤销 commit，修改保留在暂存区
git reset --mixed HEAD~1 # 默认模式：撤销 commit + 取消暂存，修改留工作区
git reset --hard HEAD~1 # 撤销 commit + 取消暂存 + 丢弃修改（不可逆！）| 模式 | commit | 暂存区 | 工作区 |
|---|---|---|---|
--soft | ✗ 撤销 | ✓ 保留 | ✓ 保留 |
--mixed（默认） | ✗ 撤销 | ✗ 撤销 | ✓ 保留 |
--hard | ✗ 撤销 | ✗ 撤销 | ✗ 撤销（危险） |
记忆口诀：soft 最软（什么都不动），hard 最硬（全部清空）。如果想找被 --hard 误删的 commit，见 reflog。
4.4 git revert：安全撤销已 push 的 commit
git revert <commit-hash> # 产生一个新的"反向" commit，保留历史
git revert -m 1 <merge-hash> # 撤销 merge commit，-m 1 保留主分支
git revert --no-commit <hash> # 撤销但不自动提交，留给你处理已 push 到公共分支的 commit 绝对不要用 git reset，否则会改写历史、坑队友。用 git revert 是 版本控制 协作的礼仪。
4.5 改写最后一次 commit
git commit --amend -m "new message" # 改 commit message
git add forgotten-file && git commit --amend --no-edit # 补文件
git commit --amend --no-edit # 只补文件不动 message--amend 本质是「丢弃当前 HEAD 的 commit，重新生成一个」。同样只对未 push 的 commit 安全。
4.6 实战：3 种回滚场景
# 场景 A：commit message 写错了，还没 push
git commit --amend -m "fix: correct message"
# 场景 B：commit 改错了文件，还想保留文件
git reset --soft HEAD~1
git restore --staged wrong-file
git commit -m "correct commit"
# 场景 C：已经 push 到 main，想撤销这次提交
git revert HEAD
git push origin main5. 远程仓库
本节把 Git 命令 中和"远端协作"相关的常用操作整理在一起：添加远程、查看远程、推送、删除远程分支、跟踪关系。这是 GitHub / GitLab / Gitee 等平台协作的必备命令。
5.1 添加与查看远程
git remote -v # 列出所有远程仓库（fetch + push URL）
git remote add origin git@github.com:user/repo.git # 添加远程
git remote add upstream git@github.com:upstream/repo.git # 给 fork 项目加上游
git remote set-url origin <new-url> # 改远程 URL（HTTPS 换 SSH 常用）
git remote remove origin # 删除远程
git remote rename origin my-origin # 重命名远程5.2 推送与跟踪
git push -u origin main # 首次推送 + 设置上游
git push # 之后直接 push 即可
git push origin --all # 推送所有本地分支
git push origin --tags # 推送所有 tag
git push origin --delete feature/old # 删除远程分支
git push origin :feature/old # 旧写法，等价于 --delete5.3 拉取与同步
git pull # = fetch + merge
git pull --rebase # = fetch + rebase（推荐）
git pull --rebase --autostash # 拉取前自动 stash，拉完自动 pop
git fetch --all # 拉取所有远程
git fetch --prune # 清理已删除的远程分支引用
git fetch origin feature/login:my-feature # 把远程分支拉到本地指定名字5.4 实战：Fork 项目同步上游
# 1. 一次性配置
git remote add upstream git@github.com:original/repo.git
# 2. 同步主分支
git fetch upstream
git checkout main
git merge upstream/main
git push origin main6. 高级与排错
这一节是 Git 命令速查 的"救命稻草"区：git reflog 救过无数被 --hard 误删的 commit、git rebase -i 能把 5 个 commit 整理成 1 个、git cherry-pick 可以把别人分支上的某次提交搬到自己的分支。
6.1 git reflog：救命命令
git reflog # 显示 HEAD 的所有历史移动记录
git reset --hard HEAD@{5} # 回到 reflog 里第 5 步的状态
git reflog expire --expire=now --all && git gc --prune=now --aggressive # 清理 reflog所有 reset / checkout / merge 都会在 reflog 留一条记录。哪怕 commit 被 reset --hard 删了，只要没过期（默认 90 天）都能从 reflog 找回来——这是 版本控制 最强大的"后悔药"。
6.2 git cherry-pick：搬单个 commit
git cherry-pick <commit-hash> # 把指定 commit 应用到当前分支
git cherry-pick <hash1> <hash2> # 一次性搬多个
git cherry-pick -x <hash> # 加上 (cherry picked from commit xxx) 标注
git cherry-pick --abort # 冲突后放弃
git cherry-pick --continue # 解决冲突后继续6.3 git rebase -i：交互式整理历史
git rebase -i HEAD~3 # 编辑最近 3 个 commit
# 弹出编辑器里把 pick 改成：
# pick = 保留
# reword = 改 message
# edit = 停下来改内容
# squash = 合并到上一个
# drop = 删掉
git rebase -i origin/main # 把自己分支 rebase 到 main 上黄金规则：只对未 push 到公共分支的提交做 git rebase。已 push 的 rebase 会让所有协作者的本地历史分叉。
6.4 git tag：版本号管理
git tag v1.0 # 轻量 tag
git tag -a v1.0 -m "Release 1.0" # 附注 tag（推荐，带作者、消息、GPG 签名）
git tag -a v1.1 <commit-hash> -m "1.1" # 给历史 commit 打 tag
git tag # 列出所有 tag
git tag -l "v1.*" # 模糊匹配
git show v1.0 # 查看 tag 详情
git push origin v1.0 # 推送单个 tag
git push origin --tags # 推送所有 tag
git tag -d v1.0 # 删除本地 tag
git push origin :refs/tags/v1.0 # 删除远程 tag6.5 .gitignore：忽略文件
# 项目根目录创建 .gitignore
node_modules/
dist/
.env
*.log
.DS_Store
.idea/
.vscode/
# 已经误提交的文件，从仓库移除但保留本地
git rm --cached file.txt
git rm -r --cached node_modules/
git commit -m "chore: update gitignore"
# 强制添加被忽略的文件
git add -f secret-config.json6.6 实战：解决 merge conflict
# 1. 触发冲突
git merge feature/login
# Auto-merging src/app.ts
# CONFLICT (content): Merge conflict in src/app.ts
# Automatic merge failed; fix conflicts and then commit.
# 2. 看冲突文件
git status
# both modified: src/app.ts
# 3. 打开文件，看到冲突标记：
# <<<<<<< HEAD
# console.log("main version");
# =======
# console.log("feature version");
# >>>>>>> feature/login
# 4. 手动编辑成最终版本，删掉 <<<<<<< / ======= / >>>>>>> 三行标记
# 5. 标记解决 + 完成合并
git add src/app.ts
git commit # merge 场景
git rebase --continue # rebase 场景
git merge --abort # 实在不想合，放弃回到合并前6.7 其它高频命令
git show <hash> # 看某个 commit 的修改内容
git shortlog -sn # 按作者统计 commit 数量
git clean -fd # 删除未跟踪的文件和目录（危险）
git fsck --lost-found # 找回悬空对象（终极救命）
git config --list --show-origin # 看所有配置 + 来源文件7. 常见问题 FAQ
Q1：git pull 和 git fetch + git merge 有什么区别？
git fetch 只把远程的提交下载到本地的远程跟踪分支（如 origin/main），不会动你的工作区和当前分支；git merge 才会把那些变更合到你当前分支。git pull = git fetch + git merge 一步完成。所以 git pull 更省事但更"黑盒"，遇到问题想精确控制时建议拆成 fetch + merge 两步。
Q2：git merge 和 git rebase 的区别？什么时候用哪个？
两者目的相同——把一条分支的变更合到另一条——但历史长得不一样：git merge 产生一个 merge commit，保留分叉记录（适合主分支、公共分支）；git rebase 把当前分支的 commit "重放"到目标分支之上，历史是干净的直线（适合本地 feature 分支、想保持主分支线性历史）。经验法则：未 push 的本地分支随便 rebase，已 push 的只 merge。
Q3：怎么找回被 git reset --hard 误删的 commit？
立刻跑 git reflog，找到被 reset 之前那个 commit 的 hash（例如 abc1234），然后 git reset --hard abc1234 即可。reflog 默认保留 90 天，几乎所有"误操作丢 commit"都能救回来。彻底没救的情况只有：reflog 也被 clear、对象被 git gc 回收。
Q4：怎么撤销已经 push 的 commit？
用 git revert <commit-hash>，它会产生一个"反向"的新 commit，把那次提交的修改撤销掉，然后正常 git push 即可。优点：不重写历史，队友的本地仓库不受影响。绝对不要在已 push 的公共分支上用 git reset --hard + force push，会让所有协作者的历史分叉。
Q5：SSH 和 HTTPS 哪个好？
短期看 HTTPS 简单（账号密码登录），适合刚入门。长期看 SSH 更省事（一次配密钥，之后 git push 免密），CI/CD 场景也几乎只能用 SSH。两者功能完全等价，按团队规范选即可。需要经常切换账号（如同时维护个人 + 工作账号）时，HTTPS + Personal Access Token 反而更灵活。
8. 推荐工具
看完这份 Git 速查，处理日常仓库事务用上面 50 条命令就够了；但开发者的工具箱远不止 Git。下面是 DevToolbox 上和 版本控制 / 文档协作高度相关的几个在线工具，纯前端处理、数据零上传，可以放心粘贴代码和文档。
更多工具见 DevToolbox 首页。祝你的 Git 工作流 一路顺风，commit message 永远格式正确、永远不带调试代码 :)