如果你想要一套能直接上手的 Git 操作组合，优先掌握提交规范、分支整合和冲突处理这三类高频场景，它们能覆盖日常开发中 80% 以上的 Git 使用需求。
先说结论：Git 操作没有银弹，但有几个经过验证的命令组合能解决大部分协作和版本管理问题。新手先从基础提交和分支管理入手，熟练后再尝试 rebase 等高级操作。
- 适合：日常开发协作、版本回溯、代码合并场景
- 先看：提交信息规范、分支整合方式、冲突解决流程
- 建议：先在测试仓库练习 rebase 和 cherry-pick，确认理解后再用于生产项目
- 风险：rebase 会改写历史，公共分支严禁强制推送
场景一：如何安全撤销最近的提交
根据是否已推送到远程，选择不同的撤销方式。
1. 仅本地撤销（未 push）
如果想保留修改内容，仅撤销提交记录：
git reset `--soft` HEAD~1
如果想彻底丢弃修改内容：
git reset `--hard` HEAD~1
2. 已推送到远程（安全撤销）
如果提交已共享，使用 revert 生成新的反向提交，避免改写历史：
git revert <提交哈希值>
场景二：如何压缩多个提交为一个
在合并请求前，将多个琐碎提交整理为一个清晰的提交记录。
步骤：
git rebase -i HEAD~3
编辑器会打开提交列表，将除第一行外的 pick 改为 squash 或 s，保存退出后编辑最终提交信息。
注意：此操作会改写历史，仅限本地分支或未共享分支使用。
场景三：如何恢复误删的分支
如果误删了分支且未推送，可通过 reflog 找回。
步骤：
git reflog
找到删除前的分支指向哈希值，执行：
git checkout -b <恢复分支名> <哈希值>
场景四：冲突处理完整流程
当合并或 rebase 产生冲突时，Git 会标记冲突文件。
步骤：
- 手动编辑文件解决冲突标记（<<<<<<< 等）。
- 标记冲突已解决：
git add <冲突文件>
- 继续完成操作：
git rebase `--continue`
或git commit
- 若需放弃操作：
git rebase `--abort`
怎么验证是否生效
配置验证：执行git config user.name和git config user.email查看当前配置是否正确。
提交历史验证：执行git log查看提交记录，确认提交信息格式是否符合规范。
分支整合验证：执行git log `--oneline` `--graph`查看提交历史是否线性整洁。
冲突解决验证：执行git status确认没有未解决的冲突文件。
恢复验证：执行git branch -a确认恢复的分支是否存在。
常见坑
1. rebase 风险：rebase 会改写提交历史，不要在已经推送到远程且其他人正在使用的分支上使用，否则会导致协作混乱。
2. cherry-pick 依赖：挑选提交时要注意依赖关系，如果目标提交依赖其他未挑选的提交，可能会导致代码不完整或编译失败。
3. 冲突标记：冲突解决后必须执行git add标记，否则 Git 会认为冲突仍未解决，无法继续合并或 rebase。
4. 提交信息：提交信息过于简略（如只写"update"）会导致后续无法快速定位修改内容，建议按规范写清楚修改范围和内容。
5. 强制推送：在公共分支上强制推送（git push `--force`）会覆盖他人提交，除非确认只有你在使用该分支，否则避免使用。建议使用git push `--force-with-lease`增加安全性。
附录：Git 命令速查表（修正版）
git config `--global` user.name "你的名字" git config `--global` user.email "你的邮箱@example.com" git init git commit -m "feat(模块): 功能描述" git rebase main git cherry-pick <提交哈希值> git add . git clone <仓库地址> git reset `--soft` HEAD~1 git reflog
原文链接：https://www.zjcp.cc/ask/11224.html