Git 常用命令：解决 “代码回滚”“分支合并冲突” 的 8 个高频场景

作为程序员日常协作和版本管理的核心工具，Git 的重要性无需多言，但很多人只会用 git add、git commit、git push 三个基础命令，遇到「代码写错要回滚」「分支合并出冲突」就手足无措，要么瞎操作导致代码丢失，要么卡半天找不到解决方案。

其实，日常开发中 80% 的 Git 问题，都集中在「代码回滚」和「分支合并冲突」两大场景。今天就整理了 8 个高频场景，每个场景对应具体的命令组合、详细操作步骤，还有新手必看的避坑提示，全程无冗余，复制命令就能用，帮你彻底搞定 Git 版本管理难题，提升协作效率！

注：本文命令适配 Windows（Git Bash）、Mac（终端）、Linux 环境，所有操作均经过实测，兼顾本地仓库和远程仓库场景，新手建议先在测试仓库练习，避免操作失误丢失核心代码。

一、先理清：核心前提（避免踩致命坑）

在开始学习具体场景前，先记住 2 个核心前提，能帮你避开 90% 的 Git 操作失误，尤其适合新手：

• Git 操作分为「本地仓库」和「远程仓库」，回滚、冲突解决优先在本地操作完成，确认无误后再推送到远程（git push）；

• 任何涉及「代码回滚」的操作，先执行 git status 查看当前仓库状态（是否有未提交的修改），避免覆盖未保存的代码。

下面重点拆解 8 个高频场景，按「代码回滚场景（4个）→ 分支合并冲突场景（4个）」分类，每个场景都明确「什么时候用」「怎么用」「注意什么」。

二、代码回滚场景（4个高频，覆盖本地+远程）

代码回滚的核心是「撤销错误操作」，但不同场景（未提交、已提交未推送、已推送远程）的命令完全不同，错用命令会导致代码丢失或远程仓库混乱，务必对应场景操作。

场景1：本地修改未执行 git add（写错代码，想彻底放弃本地修改）

适用场景：写代码时误改了文件，还没执行git add（工作区有修改，暂存区为空），想一键放弃所有本地修改，恢复到上一次 commit 的状态。

核心命令：git checkout . 或 git restore .

操作步骤：

1. 执行 git status，确认提示「Changes not staged for commit」（工作区有修改，未添加到暂存区）；

2. 直接执行git checkout .（注意末尾的小数点，代表当前目录下所有文件）；

3. 再次执行 git status，提示「nothing to commit, working tree clean」，即恢复成功。

避坑提示：该命令会彻底删除本地未 add 的修改，无法恢复，执行前务必确认没有需要保留的代码；若只想放弃单个文件的修改，将 .替换为文件名（如 git checkout test.java）。

场景2：已执行 git add（暂存区有内容，未 commit）

适用场景：执行了 git add（将修改添加到暂存区），但发现代码有错误，想撤销暂存区的修改，同时保留工作区的修改（方便后续修改后重新 add）。

核心命令：git reset HEAD . 或 git restore --staged .

操作步骤：

1. 执行 git status，确认提示「Changes to be committed」（暂存区有内容）；

2. 执行 git reset HEAD .，撤销暂存区的所有修改（工作区的修改会保留）；

3. 此时执行 git status，会回到「Changes not staged for commit」状态，可修改代码后重新 git add。

避坑提示：该命令仅撤销「暂存区」的修改，不会删除工作区的代码，比 git checkout . 更安全；若只想撤销单个文件的暂存，替换 . 为文件名即可。

场景3：已执行 git commit（本地已提交，未 push 到远程）

适用场景：执行了 git commit（将修改提交到本地仓库），但发现提交的代码有错误，想回滚到上一次 commit 的状态，同时保留当前的修改（方便修正后重新提交）。

核心命令：git reset --soft HEAD~1

操作步骤：

1. 执行 git log，查看本地提交记录，确认需要回滚的版本（HEAD~1 代表上一次提交，HEAD~2 代表上上次，以此类推）；

2. 执行 git reset --soft HEAD~1，回滚到上一次 commit 状态；

3. 执行 git status，会发现之前提交的修改回到了「暂存区」，可修改错误后，重新执行 git commit 和 git push。

避坑提示：--soft 是关键参数，代表「保留工作区和暂存区的修改」；若用 --hard（如 git reset --hard HEAD~1），会彻底删除当前提交的修改，无法恢复，谨慎使用！

场景4：已执行 git push（修改已推送至远程仓库）

适用场景：最危险的场景——代码已 push 到远程仓库（如 GitHub、GitLab），发现提交的代码有严重错误，需要回滚远程仓库的版本，同时同步本地仓库。

核心命令：git revert 提交ID（推荐，安全无风险） 或 git reset --hard 提交ID + git push -f（不推荐，有风险）

操作步骤（推荐用 git revert，安全）：

1. 执行 git log，复制需要回滚的「提交ID」（commit 后面的一串字母+数字，如 2f3a5d7）；

2. 执行 git revert 提交ID，此时会自动生成一个新的 commit（用于撤销之前的错误提交）；

3. 若出现编辑器（如 Vim），直接保存退出（Vim 中按 Esc，输入 :wq 回车）；

4. 执行 git push，将新的 revert 提交推送到远程，完成远程仓库回滚。

避坑提示：

• 优先用 git revert：不会删除远程的错误提交记录，只是新增一个撤销提交，不影响团队其他成员的代码拉取，最安全；

• 慎用 git push -f：强制推送会覆盖远程仓库的提交记录，若团队成员已拉取错误版本，会导致其代码冲突，仅适合个人仓库或无人拉取的场景。

三、分支合并冲突场景（4个高频，覆盖协作核心）

分支合并冲突是团队协作中最常见的问题，核心原因是「多个分支修改了同一个文件的同一行代码」，Git 无法自动判断保留哪一个版本。解决冲突的关键是「手动选择保留的代码」，步骤固定，无需慌张。

先明确前提：合并分支前，务必保证当前分支和目标分支的代码都是最新的（执行 git pull 更新），能减少 80% 的冲突。

场景5：本地分支合并到 master（无冲突，正常合并）

适用场景：在本地开发分支（如 dev）完成功能开发，想将代码合并到本地 master 分支，且没有冲突（最理想的情况）。

核心命令：git checkout master + git merge 开发分支名

操作步骤：

1. 切换到 master 分支：git checkout master；

2. 更新 master 分支的最新代码（若本地是最新，可跳过）：git pull origin master；

3. 合并开发分支（如 dev 分支）：git merge dev；

4. 合并成功后，执行 git push origin master，将合并后的代码推送到远程 master。

避坑提示：合并前务必确认开发分支（dev）已完成所有 commit，没有未提交的修改；若有未提交的修改，可先 git stash 暂存，合并完成后再 git stash pop 恢复。

场景6：本地分支合并，出现冲突（手动解决冲突）

适用场景：合并分支时（如 dev 合并到 master），Git 提示「Automatic merge failed; fix conflicts and then commit the result」，说明出现冲突，需要手动解决。

核心命令：git status（查看冲突文件） + 手动修改冲突文件 + git add + git commit

操作步骤：

1. 执行 git status，查看提示中的「冲突文件」（标注为 both modified）；

2. 打开冲突文件，会看到 Git 自动标记的冲突区域，格式如下： <<<<<<< HEAD # 当前分支（master）的代码 master 分支的代码内容 ======= # 分隔线，上方是当前分支，下方是待合并分支（dev） dev 分支的代码内容 >>>>>>> dev # 待合并分支（dev）的代码

3. 手动修改冲突区域：删除 Git 标记的符号（<<<<<<<、=======、>>>>>>>），保留需要的代码（可保留一方，或融合双方代码）；

4. 修改完成后，执行 git add 冲突文件名（标记冲突已解决）；

5. 执行 git commit -m "解决合并冲突：保留dev分支的xxx代码"，完成合并；

6. 最后执行 git push，推送合并后的代码到远程。

避坑提示：解决冲突时，务必仔细核对代码，避免误删核心代码；若不确定保留哪部分，可咨询团队中负责该代码的成员，不要盲目修改。

场景7：拉取远程代码（git pull）时出现冲突

适用场景：执行 git pull origin 分支名（拉取远程代码到本地）时，出现冲突——原因是本地修改了某个文件，远程也修改了同一个文件的同一行代码。

核心命令：git stash（暂存本地修改） + git pull + git stash pop（恢复本地修改） + 解决冲突

操作步骤：

1. 暂存本地未提交的修改（避免被 pull 覆盖）：git stash；

2. 拉取远程最新代码：git pull origin 分支名（如 git pull origin master）；

3. 恢复本地暂存的修改：git stash pop，此时 Git 会提示冲突文件；

4. 按照「场景6」的方法，手动解决冲突、git add、git commit；

5. 执行 git push，将解决冲突后的代码推送到远程。

避坑提示：git stash 暂存的修改，可通过 git stash list 查看，若恢复时出错，可执行 git stash drop 删除暂存（谨慎，删除后无法恢复）。

场景8：放弃合并（合并冲突后，不想继续合并）

适用场景：合并分支时出现冲突，且暂时无法解决（如不确定保留哪部分代码），想放弃当前合并操作，恢复到合并前的状态。

核心命令：git merge --abort

操作步骤：

1. 在出现冲突的终端中，直接执行 git merge --abort；

2. 执行 git status，确认提示「nothing to commit, working tree clean」，即恢复到合并前的状态；

3. 后续可先和团队成员确认代码，再重新执行合并操作。

避坑提示：该命令仅在「合并过程中出现冲突，未执行 git add 和 git commit」时有效；若已执行 git add（标记冲突已解决），则无法用该命令放弃，需手动回滚。

四、新手必看：Git 高频命令汇总（快速查询）

为了方便大家日常查询，汇总本文所有高频命令，按场景分类，可收藏备用：

场景分类	核心命令	说明
代码回滚	git checkout .	放弃本地未 add 的修改
代码回滚	git reset HEAD .	撤销暂存区的修改（保留工作区）
代码回滚	git reset --soft HEAD~1	回滚本地已 commit 未 push 的修改
代码回滚	git revert 提交ID	安全回滚远程已推送的修改
分支合并	git merge 分支名	合并指定分支到当前分支
冲突解决	git merge --abort	放弃当前合并，恢复到合并前
冲突解决	git stash / git stash pop	暂存/恢复本地修改，解决 pull 冲突
通用查询	git status / git log	查看仓库状态 / 提交记录

五、总结

Git 的核心价值是「版本管理+团队协作」，而本文的 8 个高频场景，刚好覆盖了日常开发中最容易遇到的难题——代码回滚和分支合并冲突。其实 Git 命令没有那么复杂，记住「对应场景用对应命令」，再遵循「先本地操作、再远程推送」的原则，就能避开大部分坑。

新手建议：不用死记硬背所有命令，先熟练掌握本文的 8 个场景，日常开发中遇到问题就对照查询，练 2-3 次就能形成肌肉记忆；遇到冲突不要慌，核心是「手动选择保留的代码」，解决后及时提交推送，避免影响团队协作。

最后，收藏本文，后续遇到 Git 回滚、冲突问题，直接复制命令和步骤就能解决，省时又省力～ 若需要其他 Git 场景（如分支创建/删除、标签管理）的命令，可在评论区留言！