Git 常用命令速查与回滚技巧：从日常提交到安全撤销

Git 是日常开发中最离不开的版本控制工具，几乎每个项目都会用到它。但很多人的用法停留在 add、commit、push 这几条命令上，一旦遇到提交错了、合并冲突了、分支误删了，就容易手忙脚乱。本文把我工作中最常用的 Git 命令和回滚方法整理成一份速查笔记，重点说清楚每条命令到底改变了什么，以及在什么场景下使用才安全。

一、每天都会用到的五条命令

新建仓库或者加入已有项目是第一步。git init 可以在当前目录初始化一个新仓库，git clone 可以把远程仓库完整复制到本地。开始写代码之后，git status 是最值得养成的习惯，它能清楚地告诉你工作区和暂存区现在是什么状态，改了哪些文件，有没有新加入但还没有被跟踪的文件。

改动确认无误后，用 git add 把改动放进暂存区。可以一次加入全部改动，也可以只加入某一个文件，分批提交时后者更灵活。git commit 把暂存区的内容提交到本地仓库。提交信息建议写清楚改了什么、为什么改，这会让以后的排查工作轻松很多。最后用 git push 把本地提交推送到远程仓库，第一次推送新分支时加上 -u 建立上下游关联，以后就可以直接写 git push。

二、用分支把改动隔离开

分支是 Git 最实用的功能之一。git branch 可以查看本地分支，前面带有星号的就是当前所在的分支。创建并切换到一个新分支，可以用 git checkout -b 新分支名，现在更推荐使用 git switch -c 新分支名，语义更加清晰，不容易和检出文件的操作混淆。

开发完成后，把分支合并回主分支。先切换到目标分支，再执行 git merge。合并时如果出现冲突也不要慌，打开冲突文件，把标记出来的冲突部分逐一确认，改好之后重新 add 并提交就可以了。日常开发建议每个需求单独开一个分支，合并完成并确认没有问题之后，再用 git branch -d 删除已经被合并的分支，让分支列表保持干净。

三、回滚之前，先分清改动在哪里

回滚是最容易用错的地方，操作之前首先要判断：要撤销的改动现在处在哪一个阶段。

第一种情况，改动还在工作区，还没有执行 add。这时可以用 git checkout – 文件名，丢弃工作区的改动，让文件回到上一次提交时的状态。这条命令会直接丢弃改动，执行之前务必确认文件内容真的不再需要了。

第二种情况，改动已经被 add 到了暂存区，但还没有提交。用 git reset HEAD 文件名，可以把文件从暂存区撤回来，工作区里的改动仍然保留，相当于只撤销了 add 这一步，代码本身不受影响。

第三种情况，改动已经提交到了本地仓库。如果只想撤销最近一次提交但保留代码改动，用 git reset --soft HEAD~1。如果想撤销提交，同时把改动退回工作区，用 git reset --mixed HEAD~1，这是默认的模式。如果确定连工作区的改动也不要了，才使用 git reset --hard HEAD~1。但这条命令具有破坏性，工作区的改动是找不回来的，执行之前一定要再三确认。

四、已经推送到远程的提交怎么撤销

已经推送到远程的提交，不建议再用 reset 加强制推送来处理，因为这样会改写已经公开的历史，影响其他协作者的本地仓库。更安全的做法是使用 git revert。它会生成一个新的提交，用来抵消指定提交带来的改动，历史记录保持连续，其他人正常拉取也不会出问题。

举个例子，如果某一次提交引入了一个错误，找到那次提交的哈希值前几位，执行 git revert 加哈希值，就会生成一笔反向提交，再正常推送就完成了撤销。需要撤销连续多笔提交时，可以按时间倒序依次 revert，或者一次性指定一个范围。

五、误删分支和提交的补救方法

误删分支之后不要急着重新写代码，先试试 git reflog。它记录了 HEAD 每一次移动的位置，包括提交、切换分支、重置等操作。从记录中找到误删分支最后一次提交的哈希值，再用 git branch 新分支名 哈希值，就可以把分支恢复出来。

同样的道理，用 reset --hard 改错了之后，也可以通过 reflog 找到之前的提交，再 reset 回去。只要提交过一次并且 reflog 记录还没有过期，大多数误操作都有补救的机会。平时也要记得，重要的分支不要在本地轻易删除，推到远程的分支还有远程仓库这层保护。

六、几个容易踩的坑

第一，分清 git pull 和 git fetch。pull 相当于 fetch 再加 merge，会直接把远程的改动合并到当前分支；fetch 只下载远程的改动，并不做合并，适合先看清楚远程发生了什么，再决定怎么合并。重要的合并操作之前，先 fetch 看一眼往往更稳妥。

第二，提交信息不要只写修改或者更新。写清楚改了什么功能、修复了哪个问题、关联了哪个需求，以后定位问题时翻提交记录就能快速找到线索，节省大量的时间。

第三，不要在主分支上直接开发，也不要把账号密码、密钥之类的敏感信息写进提交里。敏感信息一旦推送到远程仓库，即使后面删除了提交，也可能已经留在历史记录和别人的本地仓库里，清理起来非常麻烦。

结语

Git 的命令看起来很多，但只要理解工作区、暂存区和本地仓库这三个区域，以及每条命令是在哪两个区域之间搬运改动，就能很快分清该用哪一条。平时多用 status 和 log 确认当前状态，遇到问题先查 reflog，大多数麻烦都能找到补救的办法。希望这份笔记能帮你把 Git 用得更踏实一些。