告别 "Merge branch"：一行配置让你的 Git 历史清爽无比

你是否在 `git log` 中经常看到这种毫无营养的提交记录？

Merge branch 'master' of github.com:username/project into master

这条记录通常发生在你执行 `git pull` 的时候。它不仅没有包含任何实际的代码变更信息，还会让你的 Git 提交历史像“公交车线路图”一样分叉再汇合，乱糟糟的难以阅读。

其实，只需要修改一个简单的 Git 配置，就能让你的提交历史变成一条干净、优雅的直线。

🚀 一键解决方案

打开终端，输入以下命令：

```bash git config --global pull.rebase true ```

搞定！ 从此以后，当你 `git pull` 拉取代码时，Git 将自动帮你整理提交记录，不再产生多余的 Merge 节点。

🧐 原理：发生了什么？

要理解这个配置的作用，我们需要知道 `git pull` 到底在做什么。

1. 默认行为 (Merge 模式)

默认情况下（`pull.rebase = false`），`git pull` 实际上等于 `git fetch` + `git merge`。

当你本地有新提交，远程也有别人推上去的新提交时，Git 会试图把这两条分叉的线“系”在一起，通过创建一个新的“合并节点”来实现。

• 结果：产生分叉，以及一个多余的 Merge Commit。

```text A---B (你的本地提交) / \ D---E-------M (Merge 节点，多余且丑陋) \ / F---G (远程的新提交) ```

2. 配置后行为 (Rebase 模式)

当你设置 `pull.rebase = true` 后，`git pull` 实际上等于 `git fetch` + `git rebase`。

Git 的处理逻辑变成了：

1. 把你本地未推送的提交（Commit A, B）先“拿起来”放到一边（暂存）。
2. 把远程的新提交（Commit F, G）拉下来，更新你的本地基底。
3. 把你刚才暂存的提交，接在远程提交的最后面。

• 结果：历史记录是一条完美的直线。

```text D---E---F---G---A'---B' (由远程到本地，线性排列) ```

💡 为什么要这么做？

1. 历史清晰：没有无意义的分叉，回溯代码变更（Blame/Log）时一目了然。
2. 符合逻辑：它模拟了“我是在大家最新的代码基础上开发的”这一逻辑。尽管实际时间线上你可能早于同事提交，但在代码逻辑上，你的提交应该基于最新的主干。
3. 冲突处理更直观：在 Rebase 过程中处理冲突，往往比在 Merge 大乱炖中处理要更有条理。

⚠️ 注意事项

`pull.rebase` 主要用于拉取代码更新本地分支，这是绝大多数日常开发场景，非常安全。

唯一原则：永远不要对已经推送到公共远程分支（且别人也在基于此开发）的提交进行 Rebase。但 `git pull` 处理的是你“本地还没推”的提交，所以不用担心。

总结

保持代码整洁不仅体现在代码逻辑上，也体现在版本控制的历史中。

```bash

推荐每台新电脑都执行一次

git config --global pull.rebase true ```

一个小小的配置，从此告别 "Merge branch" 刷屏。 Happy Coding!