git pull --rebase 能让历史更清晰，因其执行 fetch + rebase，将本地提交“挪到”更新后的远程分支顶端，形成线性历史，避免 merge 产生的冗余合并节点。

用 git pull --rebase 替代默认的 git pull（即 merge 模式），能让提交历史保持线性、无多余合并节点，特别适合功能分支开发和 PR 前整理。

为什么 Pull-Rebase 能让历史更清晰

默认 git pull 执行 fetch + merge，会在本地分支上创建一个「合并提交」（merge commit），即使远程更新只是几个普通提交。这会让历史图出现分叉和菱形节点，干扰阅读。而 git pull --rebase 执行的是 fetch + rebase：它把你的本地未推送提交「挪到」更新后的远程分支顶端，形成一条干净的直线。

如何安全启用 Pull-Rebase

推荐全局配置，避免每次手动加 --rebase：

• 运行 git config --global pull.rebase true，此后所有 git pull 默认变 rebasing 行为
• 若只想对某仓库启用，去掉 --global，在该仓库内执行即可
• 临时禁用：用 git pull --no-rebase（当真需要 merge 时）

遇到冲突时该怎么处理

Rebase 过程中冲突不可避免，但处理逻辑比 merge 更直接：

git摸鱼周报自动化

生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。

下载

• Git 会停在第一个有冲突的提交，提示你解决
• 修改文件 → git add . → git rebase --continue
• 若想跳过当前提交（慎用）：git rebase --skip
• 若想中止整个 rebase：git rebase --abort，一切回到 pull 前状态

配合分支策略效果更好

Pull-Rebase 最适合「单功能分支 + 频繁同步主干」的场景：

• 例如你在 feat/login 分支开发，每天开始前先 git pull 同步 main 的最新改动
• 完成开发后，只需 git checkout main && git merge feat/login —— 因为 feat 分支是线性的，这次 merge 是 fast-forward，不产生合并提交
• 最终 main 历史就是一串平滑提交，不含冗余 merge 节点

不复杂但容易忽略：只要团队统一开启 pull.rebase，再配合简洁的分支命名和定期同步，就能长期维持可读性强、便于 bisect 和 review 的提交流。