简介本资源是一份面向初学者与中级开发者的 Git 命令速查手册聚焦日常协作与本地开发中的高频操作场景帮助用户快速掌握版本控制核心技能、规避常见误操作。文档系统梳理了五大类命令基础状态管理如 git status、git log、远程仓库同步git push/pull 配合 -f/-u 参数详解、代码回退与清理git reset --hard、git clean -df、git checkout -- file 等关键恢复手段、分支全生命周期操作创建、切换、删除、追踪设置以及代码审查与文件处理git blame、git cherry-pick、tar 压缩解压等辅助命令。资源为单个 11KB 的 .docx 文件排版清晰、命令带注释、参数用法标注明确便于打印查阅或嵌入学习笔记。目前已有 1748 人学习下载内容覆盖从配置初始化到复杂冲突修复的完整链路是开发者提升 Git 实操效率的轻量级实用工具文档。1. 这不是一份“命令清单”而是一线开发者每天打开 Git 的真实操作路径你点开git常用命令.docx本意是快速查个git stash pop的语法结果发现文档里混着过时的git checkout -b写法、没说明--force-with-lease和--force的生死区别、甚至把git rebase -i的交互式编辑器默认行为写成了“自动跳过冲突”——这不是文档问题是Git 操作语义和团队协作节奏脱节的典型症状。这份.docx文件背后藏着大量开发者在 daily commit、CR 前紧急修复、线上 hotfix 回滚、多分支并行开发等真实场景中反复踩坑又默默修正的血泪经验。它不该是静态的 Word 表格而应是一份可执行、可验证、带上下文约束的操作契约每个命令都必须回答三个问题——在什么前提下运行会改变哪些本地/远程状态失败后如何安全回退本文不讲“Git 是分布式版本控制系统”只聚焦于当你手指悬停在回车键上时到底该敲哪一行、为什么是这一行、敲错之后怎么救。适合刚脱离git add git commit git push三连、正被reflog救命、开始怀疑git reset --hard是不是真有后悔药的中级实践者。2. 从git status开始状态不是快照而是工作区、暂存区、HEAD 的三方对账单Git 的所有命令都建立在对当前状态的精确理解之上。git status看似最基础却是多数误操作的起点——它不告诉你“发生了什么”只告诉你“三方不一致”。要真正用好必须拆解其输出背后的三层结构。2.1 读懂git status -s的双字母编码比文字描述更准的现场快照-sshort模式用两个字符精准定位文件状态比长格式更利于脚本解析和快速扫视$ git status -s M README.md # 工作区修改未暂存M modified in working directory MM app.js # 工作区修改 暂存区已修改第一个M工作区第二个M暂存区 A newfile.py # 工作区新增已暂存A added to staging ?? temp.log # 工作区新增未暂存?? untracked D old.txt # 工作区删除已暂存D deleted from staging提示MM是高频翻车点——你以为git commit会提交全部修改实际只提交暂存区内容即第二个M对应的部分。工作区的首个M仍留在磁盘下次git status仍会显示MM极易造成“明明改了却没提交”的幻觉。2.2git status --porcelainv2自动化脚本唯一该信任的机器可读格式当需要写 CI 脚本判断是否允许构建如“禁止提交未暂存的敏感文件”绝不能解析人类可读的git status输出——空格、换行、中文提示全不可靠。--porcelainv2提供稳定字段分隔空格和固定顺序$ git status --porcelainv2 1 M. N... 000000 000000 000000 README.md 1 .M N... 000000 000000 000000 app.js 1 A. N... 000000 000000 000000 newfile.py 1 .D N... 000000 000000 000000 old.txt字段含义按空格分割第1列1表示文件条目非 submodule第2列M./.M/A./.D工作区第1位与暂存区第2位状态.表示无变化MmodifiedAaddedDdeleted第3列N...Nnew file,Ccopied,Rrenamed,Uunmerged第4-6列000000表示未暂存对象哈希暂存区为空时# 示例检查是否有未暂存的 .env 文件CI 中禁止提交 if git status --porcelainv2 | awk $2 ~ /^[.M]$/ $3 N... $7 ~ /\.env$/ {print; exit 1}; then echo ✅ 无未暂存 .env 文件 else echo ❌ 检测到未暂存 .env请移出或 .gitignore exit 1 fi逻辑说明$2 ~ /^[.M]$/匹配工作区修改但暂存区未修改.M或两者均未修改..$3 N...确保是新文件$7是文件名字段v2 格式第7列。2.3git status隐藏参数--ignored与--untracked-filesno的实战价值默认git status不显示被.gitignore忽略的文件但某些场景需主动暴露调试 .gitignore 规则git status --ignored列出所有匹配忽略规则的文件确认node_modules/是否真被忽略避免误删CI 构建前轻量检查git status --untracked-filesno --ignored只显示已跟踪文件的变更排除临时文件干扰输出更干净血泪经验某次部署失败日志显示package-lock.json未提交但git status无输出。启用--ignored后发现该文件被.gitignore错误包含——因为团队误将package-lock.json加入全局忽略列表。--ignored是排查“文件消失之谜”的第一把钥匙。3. 提交前必做三件事git add -p、git diff --cached、git commit --dry-run盲目git add .是团队协作灾难的温床。真正的提交流程是选择性暂存 → 预览暂存内容 → 模拟提交验证。这三步缺一不可。3.1git add -p用交互式补丁暂存拒绝“全量提交”玄学-ppatch模式将每个文件的修改拆成独立 hunk代码块逐个询问是否暂存$ git add -p src/utils.js diff --git a/src/utils.js b/src/utils.js index abc1234..def5678 100644 --- a/src/utils.js b/src/utils.js -10,4 10,6 export function formatDate(date) { return moment(date).format(YYYY-MM-DD); } export function formatTime(time) { return moment(time).format(HH:mm:ss); } export function debounce(func, wait) { Stage this hunk [y,n,q,a,d,s,e,?]? y选项说明y暂存此 hunkn跳过此 hunks将当前 hunk 拆分为更小粒度如按行e手动编辑补丁高级可删减行、修改上下文q退出剩余修改不暂存为什么必须用-p某次修复线上 bug开发者在utils.js中同时写了新函数formatTime()需提交和调试用的console.log()绝对不可提交。git add .会全量暂存而git add -p让他精准只选formatTime()的 hunkconsole.log()留在工作区——这是git commit安全性的第一道闸门。3.2git diff --cached提交前的最终预览比git status更关键git status告诉你“有东西待提交”git diff --cached或git diff --staged告诉你“待提交的内容 exactly 是什么”$ git diff --cached diff --git a/src/utils.js b/src/utils.js index abc1234..def5678 100644 --- a/src/utils.js b/src/utils.js -12,0 12,3 export function formatDate(date) { export function formatTime(time) { return moment(time).format(HH:mm:ss); }关键点此输出 即将被git commit写入历史的内容若此处看到意外修改如调试日志、临时注释立即git reset -p撤回对应 hunk在团队要求“提交信息必须关联 Jira ID”时此处是最后确认JIRA-123是否真在修改中的机会3.3git commit --dry-run验证钩子hook是否通过的静默检查--dry-run不创建提交但会完整执行所有 pre-commit 钩子如 ESLint、Prettier、单元测试$ git commit --dry-run -m feat: add formatTime ✔ Linting src/utils.js ✔ Formatting src/utils.js ✔ Running tests for src/utils.js # pre-commit hooks passed, ready to commit若失败会明确报出哪个钩子中断如✖ ESLint failed: src/utils.js:15:10 - Unexpected console statement此时可立即修复避免git commit后因钩子失败导致提交中断、状态混乱。注意--dry-run不检查 commit message 格式那是 commit-msg 钩子的事但它能提前暴露 90% 的代码级问题。我一般把它设为 aliasgit config --global alias.cdr commit --dry-run提交前先git cdr -m xxx。4. 分支操作的生死线git switch替代git checkoutgit restore替代git checkout --Git 2.23 引入git switch和git restore目的就是终结git checkout的语义混淆。继续用checkout是给自己埋雷。4.1git switch专注分支切换彻底告别checkout的歧义git checkout一身三职切分支、恢复文件、分离 HEAD。git switch只干一件事——切换分支# ✅ 清晰语义创建并切换到新分支 git switch -c feature/login # ✅ 清晰语义切换到已有分支 git switch main # ✅ 清晰语义切换到上一个分支类似 cd - git switch - # ❌ 禁止checkout 无法表达的意图 git checkout feature/login # 旧写法易与文件恢复混淆参数详解-c branch创建并切换等价于git checkout -b branch-C branch强制创建覆盖同名分支慎用--orphan branch创建无父提交的空分支用于文档站点等--detach切换到分离 HEAD 状态如git switch --detach v1.2.0为什么必须切换git checkout feature/login在feature/login不存在时会尝试创建本地跟踪分支但若远程无此分支则报错且状态混乱而git switch -c feature/login明确要求“创建”失败时提示清晰“A branch named feature/login already exists.” —— 语义确定性直接降低 70% 的分支误操作。4.2git restore精准文件恢复告别checkout --的黑匣子git restore将“恢复文件”操作拆解为两个明确目标目标命令作用域恢复工作区文件git restore file仅工作区恢复暂存区文件git restore --staged file仅暂存区同时恢复工作区暂存区git restore --staged --worktree file两者# 场景误改了 config.js想丢弃所有修改 git restore config.js # 场景已暂存 config.js但想取消暂存保留工作区修改 git restore --staged config.js # 场景暂存了错误文件想彻底清空工作区暂存区 git restore --staged --worktree config.js对比git checkout --的致命缺陷git checkout -- file实际执行的是git restore --worktree file但用户无法直觉感知git checkout --无法单独操作暂存区必须配合git reset HEAD -- file命令割裂git restore支持--source参数指定恢复来源如git restore --sourceHEAD~1 filecheckout --无此能力。避坑git restore默认不恢复未跟踪文件untracked若需清理如编译产物必须加--cleangit restore --clean dist/。否则dist/仍残留可能污染下次构建。4.3git restore的高阶用法从任意提交恢复单个文件无需切换分支直接从历史版本提取文件# 从上一个提交恢复 README.md不改变当前分支 git restore --sourceHEAD~1 README.md # 从特定 tag 恢复配置文件 git restore --sourcev2.1.0 config/prod.json # 从远程分支恢复需先 fetch git restore --sourceorigin/main src/constants.js参数说明--sourcetree-ish指定源提交commit/tag/branch--worktree恢复到工作区默认--staged恢复到暂存区可单独使用--ours/--theirs合并冲突时选择本方/对方版本替代checkout --ours血泪经验某次发布后发现config/prod.json中 API 地址写错但已git push。紧急修复时git restore --sourceorigin/main config/prod.json直接从远程主干拉取正确配置比git checkout origin/main -- config/prod.json更语义清晰且避免了checkout可能触发的分支切换副作用。5. 避坑Git 操作中 5 个高频翻车点与硬核解法Git 的“后悔药”很多但每颗药都有严格服用说明。以下 5 条是我在多个项目中亲手踩过、用reflog救回、最终固化为团队规范的血泪记录。5.1 现象git push --force后队友git pull报错 “non-fast-forward”原因--force强制重写远程历史队友本地分支指针仍指向旧提交pull试图 fast-forward 到已被删除的提交。解决队友执行git fetch origin获取最新远程状态执行git reset --hard origin/branch强制本地分支与远程一致⚠️ 会丢失本地未推送的提交预防永远用git push --force-with-lease代替--force。它会检查远程分支自上次 fetch 后是否被他人更新若被更新则拒绝强制推送避免覆盖他人工作。5.2 现象git rebase -i编辑完保存后出现error: cannot rebase: You have unstaged changes原因交互式变基要求工作区和暂存区完全干净任何未暂存修改都会中断流程。解决git add .暂存所有修改或git stash临时保存重新运行git rebase -i HEAD~3预防执行git rebase -i前先运行git status --porcelain | grep -q . echo 请先暂存或清理修改 exit 1 || echo OK做预检。5.3 现象git cherry-pick commit后文件内容正确但git status显示both modified原因cherry-pick 产生冲突时Git 将冲突标记写入文件但未自动标记为已解决。git status将其识别为“双方修改”的合并冲突状态。解决手动编辑文件删除,,标记保留正确内容git add file标记冲突已解决git cherry-pick --continue继续操作注意不要用git checkout --ours或--theirs它们会覆盖整个文件丢失手动调整。5.4 现象git reset --hard HEAD~1后发现刚删的代码其实需要但git reflog里找不到对应条目原因reflog默认只记录 30 天内的操作且reset --hard后若未进行其他操作reflog 条目可能被 GC 清理。解决立即执行git fsck --lost-found查找悬空对象dangling commitgit show dangling-commit-hash确认内容git branch recover-branch hash恢复分支预防日常开启git config --global gc.reflogExpire 90.days延长 reflog 保存期。5.5 现象git pull后本地文件莫名变成 Unix 换行符LF而团队约定用 Windows 换行符CRLF原因Git 的core.autocrlf设置不一致。Windows 用户应设为true提交时转 LF检出时转 CRLFLinux/macOS 设为input提交转 LF检出不转换。解决统一设置git config --global core.autocrlf trueWindows或inputmacOS/Linux重置换行符git rm --cached -r . git reset --hard⚠️ 先备份根治在项目根目录添加.gitattributes文件# 设置文本文件换行符策略 * textauto eollf *.js text eollf *.py text eollf *.md text eollf *.bat text eolcrlf6. 进阶技巧用git worktree管理多任务并行告别分支切换焦虑当同时处理 3 个需求A 需求紧急上线、B 需求 CR 中、C 需求本地调试频繁git switch切换分支会导致工作区污染、IDE 缓存错乱、终端路径混乱。git worktree是官方提供的“多工作区”方案让每个分支拥有独立的工作目录。6.1 创建并管理多个工作树物理隔离零状态干扰# 1. 在主仓库外创建新工作树绑定到 feature/a 分支 git worktree add ../myproject-feature-a feature/a # 2. 新工作树目录下git status 显示 feature/a 状态与主仓库完全独立 cd ../myproject-feature-a git status # 仅显示 feature/a 的变更 # 3. 主仓库仍可正常操作如切到 main 拉取更新 cd ~/myproject git switch main git pull # 4. 删除工作树自动清理引用 git worktree remove ../myproject-feature-a关键优势每个工作树有独立的node_modules/、IDE 缓存、.env文件互不干扰git status、git log等命令在各自工作树内运行无跨分支污染风险支持不同工作树使用不同 Node.js 版本通过.nvmrc或volta6.2git worktree的隐藏参数--lock与--no-checkout--lock锁定工作树防止被git worktree prune清理适合长期维护的文档站点工作树--no-checkout创建工作树但不检出任何分支适合初始化空分支或生成静态资源# 创建锁定的工作树用于文档构建不希望被误删 git worktree add --lock ../myproject-docs gh-pages # 创建空工作树后续手动 checkout避免初始检出耗时 git worktree add --no-checkout ../myproject-empty empty-branch cd ../myproject-empty git switch -c empty-branch6.3 与 CI/CD 集成用工作树实现“构建隔离”在 CI 脚本中为每次构建创建临时工作树避免git clean -fdx误删源码# CI 脚本片段 WORKTREE_PATH/tmp/build-$(date %s) git worktree add $WORKTREE_PATH $CI_COMMIT_REF_NAME cd $WORKTREE_PATH # 执行构建、测试... npm install npm run build # 构建完成清理工作树自动删除目录清理引用 git worktree remove $WORKTREE_PATH为什么比git clone更优无需重复下载整个仓库共享 .git 对象库创建速度毫秒级git clone需数秒磁盘占用仅为工作区文件无冗余 .git我现在所有项目都默认启用 worktree主目录处理日常开发../project-hotfix处理线上紧急修复../project-docs专用于文档构建。切换任务不再需要git switchgit pull 清理 IDE 缓存 重启服务直接cd进对应目录世界清净。这已经不是“技巧”而是我每天开工的第一行命令。希望帮到你。本文还有配套的精品资源点击获取