记忆转储 
Git在push的时候防止出现Merge曲线的办法
在日常开发中，有时候会有这样一个场景：
在本地修改了几份文件并完成了 git commit，但忘记了作 git push。过了几天回到项目，你想起要推代码，于是习惯性地先执行了一句：
git pull这时候发现远程仓库里同伴们提交了不少新代码。Git 自动帮你做了一次合并，等你在推上去（git push）之后，在 GitHub / GitLab 的网络图上就会赫然出现一条巨大的 Merge 交叉曲线。
最让人郁闷的是：你改的那几个文件，同伴根本就没动过，大家改的完全是不同的地方，本应该平滑提交的代码却留下了一个不必要的“合并节点（Merge Commit）”。
这篇文章将教你如何撤销这个 Merge 曲线，恢复成一条漂亮的直线的 Commit 历史。
为什么会出现这个 Merge 曲线？
当你本地有尚未 Push 的 Commit，同时远程仓库又有新的 Commit 时，默认的 git pull 实际上等同于：
git fetch + git mergeGit 为了保留两边的历史记录，会主动创建一个新的 Merge Commit 把两个分支的分叉连接起来。即使两边的修改毫无冲突，这个合并节点也会被强制建立。
解决方案
根据你是否已经将这个 Merge 曲线推送到服务器，解决办法略有区别。
场景一：只在本地 Pull 了，还没有 Push 到服务器
这是最轻松的解决方式，只需要 “撤销合并 + 重新变基” 即可。
1. 撤销刚才的合并（回到 pull 前的状态）
git reset --hard ORIG_HEAD注：ORIG_HEAD 指向你执行危险操作（如 merge/pull）之前的节点。
2. 使用 --rebase 重新拉取
git pull --rebase这会把你本地未提交的改动“临时取下”，先将远程最新的代码拉下来，然后再把你的 Commit 依次“变基（Rebase）”贴在最顶部。
3. 正常推送
git push此时你推送到远程仓库的历史就是一条纯粹的直线，只增加了一个干净的黑点！
场景二：Merge 曲线已经 Push 到了远程服务器
如果合并线已经提交到了服务器，想要抹掉它，就需要重写远程历史（Force Push）。
⚠️ 注意：如果这是团队多人公用的主分支（如
main/master），且别人已经基于这个 Merge 节点拉取了代码，不建议强行覆盖。如果是你自己的开发分支，可以放心操作。
1. 本地回退到 Merge 节点之前
# 回退到上一个提交节点（即 Merge 之前的版本）git reset --hard HEAD~12. 重新用 Rebase 方式拉取
git pull --rebase3. 强行推送到远程覆盖历史
git push origin <你的分支名> --force这样服务器上的合并曲线就会被完全抹去，历史恢复为干干净净的单条线。
常见顾虑：git pull --rebase 会覆盖别人的代码吗？
绝对不会！
不管是 merge 还是 rebase，Git 的安全机制是一模一样的：
- 如果改动的文件没有交集，Git 会自动无缝平移你的 Commit。
- 如果碰巧改了同一文件的同一行，Git 会立即中断变基，提示你手动解决冲突。只有当你解决冲突并执行
git rebase --continue后，变基才会继续进行。
一劳永逸：配置 Git 默认使用 Rebase
为了以后不再手动输入 --rebase，也不用再担心生成难看的分叉线，建议在全局配置中开启 pull 自动 rebase：
git config --global pull.rebase true配置完成后，以后每次使用普通的 git pull，Git 都会自动帮你的 Commit 平移到远程最新代码的头部，保持分支历史永久简洁优雅。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！