Git 这东西很多人第一次接触是在被代码搞崩之后。改了几天的功能手一滑删错了文件CtrlZ 救不回来那种绝望感估计每个开发者都体会过。Git 就是来解决这个问题的——它把你的每一次修改都记录下来随时可以回到任意一个历史节点。这篇速查表是我从入门到熟练这几年一直在用的操作清单整理成比较系统的一版适合两类人刚接触 Git 的新手以及用了一阵子但总记不住命令、每次都要现查的老手。配合真实的命令输出和踩坑记录主打一个能直接照着敲。1. 开篇先搞懂 Git 到底在解决什么问题1.1 版本管理的核心痛点早期做项目最常见的版本管理就是手动复制文件夹项目_最终版、项目_最终版2、项目_真最终版、项目_打死也不改了。这种做法的致命问题有三个一是文件夹一多就分不清哪个才是最新的二是协同合作时两个人同时改同一份代码合并起来极其痛苦三是没有记录改坏了想找回三天前的版本只能靠运气。Git 的出现把这三件事变成了常态操作。它本质上是一个分布式版本控制系统每次提交都会对整个项目做一个快照并记录谁在什么时间改了什么内容。由于每个开发者本地都有一份完整的仓库即使没有网络也能正常提交、查历史、回退这在飞机上、断网时都能干活是集中式系统做不到的。还有一个很多人忽略的点Git 不只是一个备份工具它是一套协作协议。分支、合并、代码评审这些流程都是建立在 Git 的对象模型上的。所以学 Git 不能只背命令要理解它的三个核心区域工作区你正在编辑的文件、暂存区已标记要提交的内容、版本库已提交的历史记录。后续所有的操作本质上都是在这三个区域之间搬运内容。1.2 一张速查表应该怎么用我的建议是不要试图一次记完所有命令。Git 的命令有几百个日常真正高频使用的不到二十个。把这张表当成字典来用遇到问题先查对应场景找到命令后理解它干了什么再动手执行。用熟了之后这些命令自然会变成肌肉记忆。另外提醒一句网上很多教程把 Git 命令讲得特别玄乎其实没必要。Git 的设计哲学是操作不可怕可怕的是你不知道操作之后会发生什么。所以我在下面每个部分都会解释命令的执行结果而不是单纯丢命令。2. 环境准备装好工具配好身份2.1 安装与命令行环境不同系统的安装方式差异不小这里只给最直接的路径LinuxDebian/Ubuntu 系sudo apt install gitmacOSbrew install git或者直接装 Xcode Command Line Tools 也会附带 GitWindows去官网下载安装包一路 Next 就行装完之后在终端里跑git --version能输出版本号就说明成功了。我个人强烈建议用命令行而非图形工具原因很简单图形工具把操作包装掉了遇到问题你根本不知道它底层执行了什么排查起来两眼一抹黑。命令行虽然初看枯燥但输出信息非常明确学一遍之后收益是长期的。注意Windows 上建议直接使用 Git Bash它模拟了类 Unix 环境命令行为表现更接近主流场景避免很多路径和脚本兼容性的坑。2.2 用户信息与基础配置安装完第一件事配置你的身份。这一步很多人偷懒跳过结果提交记录里全是unknown协作时根本不知道谁改的。git config --global user.name 你的名字 git config --global user.email 你的邮箱用git config --global --list可以查看所有全局配置。除了身份信息还有几个配置我在实际工作中调过建议一并处理# 终端输出彩色显示看起来舒服很多 git config --global color.ui true # Windows 上处理换行符防止 CRLF/LF 引发的大规模 diff git config --global core.autocrlf true # 设置默认编辑器为 vim避免 commit 时卡在 nano 里不会退出 git config --global core.editor vim为什么换行符配置重要Windows 的文件默认以 CRLF 结尾Linux/macOS 用 LFGit 如果不做转换你会看到整个文件都被标记为修改而实际上只是换行符变了。core.autocrlf true的含义是提交到仓库时自动转换为 LF检出到工作区时转换为 CRLF这样团队跨平台协作就不会互相污染 diff。关于换行符配置我这里多说一句。如果你的团队里大概率只有 Windows 机器那true就好如果团队混用系统我更推荐input它只在提交时转 LF检出时不转保持仓库干净各平台各用各的。这个配置属于团队级约定最好写进仓库的.gitattributes里一劳永逸。3. 日常操作从建仓库到第一次提交3.1 初始化仓库与文件状态进入项目目录执行git init这时目录里会出现一个隐藏的.git文件夹它就是 Git 的数据库所有版本信息都存在里面。注意正常情况下你不需要动这个文件夹也不要把它复制给别人否则会产生一堆诡异的问题。然后写一个.gitignore文件告诉 Git 哪些东西不需要纳入版本管理依赖目录、编译产物、临时文件、IDE 配置等。这个文件建议在项目一开始就配好否则后面才发现node_modules被提交了清理起来相当折腾。简单示例node_modules/ dist/ *.log .DS_Store .idea/接下来用git status是检查仓库状态最重要的命令没有之一。它会告诉你当前处在哪个分支、哪些文件被改过、哪些是新文件没被跟踪。新手最常见的错误就是不看 status 直接 commit结果把不想提交的文件也提交进去了。3.2 add、commit、status、log 的正确用法一次完整的最小提交流程是git add README.md # 把文件加入暂存区 git commit -m 添加项目说明文档 # 暂存区内容生成一次提交git add只做一件事把工作区的改动放入暂存区。它不会保存历史只相当于打包待发的状态。如果一次改了十几个文件但希望分成两个逻辑提交比如修复 bug 一个、加功能一个就可以先git add相关的几个文件提交再git add另外几个再提交这就是小步提交的基本功。git commit的-m参数直接跟提交信息。提交信息是给人看的也是给未来的自己看的。我见过太多提交信息写成fix、update、111过了三个月他自己也看不懂。推荐格式是动词 做了什么比如修复登录页在移动端无法滚动的问题。提交之后就是查看历史git log --oneline --graph --all--oneline让每条记录只显示一行--graph用字符画出分支走向--all显示所有分支。这个组合是我使用频率最高的查看方式一眼就能看清整个仓库的分叉和合并脉络。还有两个 diff 命令要掌握git diff # 工作区 vs 暂存区的差异 git diff --staged # 暂存区 vs 上次提交的差异记住这个对应关系git diff看的是还没 add 的改动git diff --staged看的是已经 add 但还没 commit 的改动。很多新人在这两个命令上栽跟头核心原因就是对暂存区的概念模糊。实操心得每次 commit 之前一定要先git diff --staged看一眼即将提交的内容确认没有误加文件、没有调试代码。这一步花不了十秒但能避免大量提交了不该提交的东西的尴尬。4. 分支操作别在主分支上裸奔4.1 创建、切换、删除分支分支是 Git 最强大的特性也是新手最容易绕晕的地方。可以这样理解分支就是从某个提交点拉出来的一条平行时间线你在分支上改代码不影响主线的其他人。基础命令git branch # 查看本地分支列表带 * 的是当前分支 git branch feature-login # 创建新分支 git switch feature-login # 切换到该分支传统写法是 git checkout feature-login git switch -c hotfix-001 # 创建并切换一行搞定新版 Git 推荐用git switch和git restore来替代checkout的多重职责语义更清晰switch只管切换分支restore只管恢复文件。旧版命令不是不能用只是它一个命令干了好几件事新人容易迷惑。删除分支git branch -d feature-login # 安全删除未合并的分支会拒绝删除 git branch -D feature-login # 强制删除危险但有时需要实际项目里功能分支开发完合并回主分支后本地分支就可以删掉保持仓库整洁。但注意删除本地分支不会影响远程分支远程的还要单独git push origin --delete。4.2 合并分支的两种方式分支开发完了要汇入主线。合并方式主要有两种merge和rebase。git switch main git merge feature-loginmerge会生成一个合并提交保留两条分支的历史轨迹图的走向是分叉再交汇。优点是历史完整、操作无脑缺点是当开发频率高时历史图会变得像一团毛线球。rebase则不同git switch feature-login git rebase main它的逻辑是把 feature 分支上相对于 main 的全部提交剪下来重新接到 main 的最新提交后面。结果是一条直线历史非常清爽。但代价是提交的哈希值全部变了所以绝不要对已经推送到远程且别人在用的分支做 rebase否则会把协作伙伴搞崩溃。选择建议个人开发或短期功能分支用 rebase 保持线性多人长期共用的分支用 merge 保证安全。没有绝对正确团队约定一致就行。合并时最不愿意看到的就是冲突conflict。当两个人改了同一文件的同一行Git 会停下来把冲突区域标记成 HEAD 你的内容 对方的内容 feature-login处理方式是直接打开文件手动修改成最终想要的代码删掉这些标记符号然后git add该文件再git commit完成合并。遇到冲突别慌这是正常现象。关键是先看清楚冲突内容再动手改不要直接挑一边删另一边。如果拿不准优先和改这部分代码的同事沟通别自己拍脑袋。5. 远程仓库把代码存到远端5.1 关联远程仓库与推送本地仓库建好了把代码推到远程托管平台比如常见的代码托管服务上。在托管平台创建一个空仓库后本地执行git remote add origin https://xxx/你的项目.git git push -u origin mainremote add origin的意思是给远程仓库起个名字叫origin这是约定俗成的默认名。-u参数把本地 main 分支和远程 main 分支的关联关系记下来之后直接敲git push就能推送不用每次写全。第一次向远端推送时可能要输入账号密码。建议用 SSH 方式而不是 HTTPS配置一次公钥之后就不用每次输入凭证了。做法是生成本机密钥对把公钥配置到托管平台账号里然后 remote 地址用gitxxx:你的项目.git这种格式。查看远程仓库配置git remote -v这个命令列出当前关联的所有远端地址排查推错仓库问题时非常有用。5.2 拉取更新的两种姿势团队成员推了新代码你要同步下来。最常用的是git pullgit pull其实是两步的合体先git fetch把远端的最新内容下载到本地不动你的工作区再执行一次合并把远端内容汇入当前分支。明白这一点很重要因为git pull有可能触发合并冲突。如果你希望拉取时用 rebase 而不是 merge可以这样git pull --rebase区别和上一节讲的 merge/rebase 完全一致--rebase会让你的提交依次接到远端最新提交后面历史更线性。我个人的习惯是团队协作分支上本地提交没推送时拉取一律用 rebase避免产生毫无意义的merge remote-tracking branch提交。还有一个容易踩的坑远端有更新但你本地也有未提交的修改这时候git pull可能被拒绝。解决办法是先把本地改动git stash暂存起来pull 之后再git stash pop恢复。推送被拒绝的场景也非常常见。原因通常是远端有本地没有的提交最安全的解法就是git pull --rebase git push先用 rebase 把你的提交放到最新代码之上再推送一气呵成。不要傻乎乎地去git push --force强推会把远端提交冲掉在共用分支上是事故级操作。6. 撤销与回退给自己留后悔药6.1 从容的后悔还没提交的修改Git 最让人安心的就是撤销操作。先记住一个前提不同阶段的撤销命令完全不同用错了不但撤销不了还可能把改动真的丢掉。情况一工作区改了文件但还没 add。想撤销这次修改回到上次提交的状态git restore 文件名 # 或者老写法git checkout -- 文件名这个操作会用版本库里的内容覆盖工作区文件未提交的改动会永久丢失执行前想清楚。情况二已经 add 了想从暂存区撤回来git restore --staged 文件名 # 或者git reset HEAD 文件名这个命令只是把文件从暂存区移出来工作区内容不变安全。它对应的是啊我 add 错文件了的场景。情况三想同时撤销暂存和工作区git reset --hard HEAD--hard会把工作区、暂存区全部恢复到 HEAD当前提交点状态所有未提交的修改全部丢失。这个命令我使用频率极低因为风险太大。6.2 提交错了怎么办如果已经 commit 了发现提交信息写错了或者忘了包含某个文件git commit --amend -m 新的提交信息--amend会修改最近一次提交包括提交信息、包含的文件列表。它不会新增一条提交记录而是把原来那条替换掉。注意这个操作会改写提交哈希所以只适合尚未推送的提交。如果需要回退到更早的提交有三个档位git reset --soft 提交哈希 # 只移动 HEAD暂存区和工作区保留 git reset --mixed 提交哈希 # 移动 HEAD清空暂存区工作区保留默认 git reset --hard 提交哈希 # 全部恢复工作区也回退危险怎么选想撤销 commit 但保留改动重来用--soft想撤销 add 和 commit保留文件内容用--mixed想彻底回到过去文件也变成那个版本用--hard。但这里有个大原则已经推送到远端的分支不要用 reset 回退。因为 reset 会改变历史你强推上去会让别人的本地仓库和历史脱节。正确做法是用revertgit revert 提交哈希revert会生成一条新提交把目标提交的改动反向应用回去。历史仍然完整只是多了一条撤销记录所有人都能安全同步。还有一个救命命令git reflog。它记录的是本地所有 HEAD 移动的痕迹包括被 reset 掉的提交。一旦发现--hard回退过头了可以git reflog # 找到回退前的哈希 git reset --hard 那个哈希只要操作过的历史还在 reflog 里就有机会找回。这是最后一道安全网但注意 reflog 记录有有效期默认约 90 天过期就真的没了。7. 提升效率的进阶命令7.1 stash临时保存现场写代码写到一半接到一个紧急需求要切分支处理。直接切分支会提示本地有未提交的修改无法切换这时候就是git stash的用武之地git stash # 保存工作区当前状态工作区变干净 git switch 其他分支 # 放心切换 # 处理完紧急需求后 git switch 原分支 git stash pop # 恢复暂存的改动git stash list可以查看所有暂存记录git stash apply不删除记录地恢复git stash drop手动删除某条记录。stash 还可以带信息保存多个现场git stash save 登录功能开发到一半我实际用下来stash 非常适合多任务切换场景。但注意stash 是本地操作不会同步到远端长时间放着有丢失风险最好当天处理完就pop出来。7.2 cherry-pick精准挑选提交有个分支上只想要其中某一次提交的改动不想整个合并过来就用 cherry-pickgit cherry-pick 提交哈希比如你在测试分支上修了一个 bug提交哈希是a1b2c3d主线维护分支也想用这个修复但不想要其他乱七八糟的改动一条命令就能把这次提交摘过来。用法非常场景化适合临时修复和跨分支同步单个提交。多个连续提交也可以一次挑选git cherry-pick 起始哈希..结束哈希执行过程中如果冲突了流程和 merge 冲突一样手动改文件、add、然后git cherry-pick --continue继续。7.3 别名与小技巧高频命令手敲确实累可以在全局配置里加别名git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --oneline --graph --all之后输入git st、git lg就能快速执行对应命令。我建议每个人按照自己使用习惯配置一套别名效率提升非常明显。再分享一个查看历史命令的技巧。想查某个文件的所有修改历史git log --oneline -- 文件名 git log -p -- 文件名 # 连每次改动的 diff 一起看想查某一行代码是谁写的、哪次提交引入的git blame 文件名这些命令在排查这个 bug 是什么时候引入的时非常有用。8. 高频问题排查速查表实际工作里遇到的问题翻来覆去就那么几个整理成表格方便快速对照。遇到问题先查表比翻整篇文档有效得多。场景错误示范推荐解法提交信息写错了重新 commit 一次git commit --amend -m 正确信息提交后忘了一个文件用--amend或新增提交git add 漏掉的文件然后git commit --amend --no-edit文件误删还没提交重新手动创建git restore 文件名不小心 reset 过头了绝望重写git reflog找到旧哈希git reset --hard 旧哈希推送被远端拒绝强推--forcegit pull --rebase后正常git push合并冲突不知道怎么处理网上乱搜手动改冲突标记add 后 commit不该提交的文件提交了留下痕迹git reset --soft HEAD~1移除文件后重新提交分支想删但提示未合并强制删除确认不需要后git branch -D想放弃所有本地改动逐个删文件git reset --hard HEAD确认后使用切分支被未提交修改拦截直接强制切git stash保存后切换这几个问题里我发现最容易出事故的是推送被拒绝和确认不要的本地改动。前者切忌--force后者切忌不确认就--hard。多花两秒看 status 和 diff能省掉几小时恢复时间。还有一个隐藏很深的坑文件改名时Git 有时候会识别成删了一个旧的、加了一个新的导致历史关联断裂。处理方法是git mv 旧文件名 新文件名用git mv而不是操作系统重命名Git 就能正确记录重命名行为保留历史追踪。9. 写在最后我的几个实操心得这张表整理的是我日常使用频率最高的操作但在真正的工作里比命令更重要的是一些习惯层面的东西。第一个心得是提交要小、要频繁。一个功能拆成多个逻辑清晰的提交每个提交只做一件事这样回退、排查、代码评审都轻松。别攒一周改动一次性提交那时候你自己都说不清改了啥。第二个心得是提交信息是写给未来的人看的。三个月后回来看代码的人——往往是未来的你自己——会感谢你当初多写了几个字。我见过fix bug这种信息完全无法定位代码意图。好的信息应该像一句话摘要修复订单金额在小数点两位时四舍五入错误。第三个心得是别怕 Git但要敬畏危险命令。--hard、--force、rebase推送这些词动用之前花十秒钟确认这是不是你想要的。我踩过最狠的坑就是对共享分支用了push --force看着同事们一脸茫然的表情那滋味不想来第二次。这几个心得不是从哪本书上抄来的是实实在在在项目里摔出来的。Git 学到后面你会发现命令本身只是工具真正难的是对版本演进的理解和对协作规范的尊重。把这个速查表存下来用到哪个查哪个用十次以上自然就熟了。下一期我会继续整理分支策略和多人协作工作流的实战经验到时候大家再一起讨论。