在之前的学习中，我对于git的一些基础命令有了基本的认识。但是在实际应用中，我却发现有些命令不是想象中的那么简单，在执行前需要谨慎，以下来做个总结
一、git reset 和 git revert
问题来源
• git reset：经常被误用，导致代码回退后丢失重要修改
• git revert：被误认为和 reset 功能相同，但它实际上是通过“撤销提交”的方式生成一个新的提交
区别
• git reset：直接修改历史版本，适合本地仓库清理，不推荐在团队协作中使用
• git revert：安全地在版本历史中添加撤销记录，适合协作开发
容易出错的场景
假设当前有三次提交：
A -> B -> C (HEAD)
若想回退到 B 的状态：
- 如果使用 git reset --hard B：
• HEAD 会指向 B，C 的提交记录会丢失
• 若没有备份或其他分支指向 C，则无法恢复
- 如果使用 git revert C：
• 会生成一个新的提交 C'，用来撤销 C 的内容
二、git checkout 和 git switch
问题来源
• git checkout 是一个多功能命令，但正因为如此，它容易被误用。例如切换分支时，
git checkout <branch_name>
• 恢复文件时：
git checkout -- <file_name>
容易出错的场景
- 文件丢失问题
当你执行 git checkout -- 时，会直接用版本库中的文件覆盖当前工作区中的文件。这个操作是不可逆的，未保存的修改会丢失。
- 混淆分支切换和文件恢复
同一个命令既可以用来切换分支，又可以用来恢复文件，容易引起混乱
Git的新版本中引入了更明确的命令，故建议用以下更明确的命令：
• git switch：专用于分支切换
• git restore：专用于恢复文件
三、git pull
问题来源
git pull 是一个高频指令，用于同步远程仓库的更改到本地。但它实际上是 git fetch 和 git merge 的组合，直接拉取并合并代码，这可能导致冲突或意外覆盖
容易出错的场景
- 强行合并导致冲突
当远程分支和本地分支都有修改时，git pull 会直接尝试合并，若出现冲突，必须手动解决
- 历史记录被污染
如果团队多人协作，直接拉取并合并可能让主分支的提交记录变得凌乱
建议
- 使用 git fetch + git rebase 代替 git pull，避免合并提交：
git fectch git rebase origin/main - 如果习惯使用 git pull，建议添加 --rebase 参数：
git pull --rebase
四、git push --force
问题来源
git push --force 是一个强制推送的命令，可以覆盖远程仓库的历史记录。在某些情况下会导致他人的工作成果丢失，因此需要谨慎使用。
容易出错的场景
- 覆盖远程分支
假设你的同事刚刚在远程分支上提交了一个新功能，而你本地的分支版本较旧。使用 git push --force 后，你的旧版本会覆盖远程的新版本，导致同事的工作丢失。
- 误操作导致团队数据丢失
在多人协作的项目中，强推可能会引起混乱，甚至无法恢复远程仓库的部分历史记录。
建议
-
使用 --force-with-lease 替代 --force
git push --force-with-lease -
在强推之前，始终备份或同步远程分支：
git fetch origin git rebase origin/main
