为什么你的 PR 总是多出一堆奇怪的 commit？90% 的人都踩过这个 Git 坑
在日常开发中，功能分支开发周期较长时，主干分支往往已经有了新的提交。这时需要将主干的最新代码同步到自己的功能分支，常见的方式有两种：merge 和 rebase。本文通过实际场景对比两种方式的区别与使用方法。
背景：为什么需要同步主干？
假设你从主干 main 切出了功能分支 feature/my-work，开发过程中主干有了新的提交，此时你的分支历史如下：
makefile
main: A ── B ── C（新提交）
feature: A ── B ── D（你的提交）如果不同步主干，提 PR 时可能产生冲突，或者遗漏主干的重要修改。
git pull 是什么？
git pull 是 git fetch + 合并操作的快捷命令，默认使用 merge 方式：
bash
git pull origin main
# 等价于
git fetch origin
git merge origin/main也可以指定使用 rebase 方式：
bash
git pull --rebase origin main
# 等价于
git fetch origin
git rebase origin/main两者的区别与下文 merge / rebase 章节一致。如果希望 git pull 始终使用 rebase，可以设置全局配置：
bash
git config --global pull.rebase true💡 建议 ：对于个人功能分支，推荐全局开启
pull.rebase true，保持提交历史线性整洁。
方式一：merge
原理
将主干的最新提交合并进你的分支，并生成一个新的 MergeCommit 记录这次合并。
makefile
main: A ── B ── C
\
feature: A ── B ── D ── M（MergeCommit）操作步骤
第一步：拉取远程最新代码
bash
git fetch origin第二步：切换到自己的功能分支
bash
git checkout feature/my-work第三步：合并主干
bash
git merge origin/main处理冲突（如有）
bash
# 手动解决冲突后
git add .
git merge --continue
# 放弃本次合并
git merge --abort第四步：推送到远程
bash
git push origin feature/my-work提 PR 后的 commit 记录
sql
D 你的提交
M Merge branch 'origin/main' into feature/my-work方式二：rebase（推荐）
原理
将你的提交「移植」到主干最新提交的后面，历史记录保持线性，不会产生多余的 MergeCommit。
vbnet
main: A ── B ── C
\
feature: A ── B ── C ── D'（你的提交被接在 C 后面）操作步骤
第一步：拉取远程最新代码
bash
git fetch origin第二步：切换到自己的功能分支
bash
git checkout feature/my-work第三步：变基到主干
bash
git rebase origin/main处理冲突（如有）
rebase 会逐个回放你的每一个 commit，每个 commit 都可能产生冲突，需要逐一处理：
bash
# 手动解决冲突后
git add .
git rebase --continue
# 放弃本次 rebase
git rebase --abort第四步：force push 到远程
由于 rebase 改写了本地提交历史，必须使用 force push 同步到远程：
bash
git push origin feature/my-work --force-with-lease⚠️ 为什么用
--force-with-lease而不是--force？--force会无条件覆盖远程分支，存在覆盖他人提交的风险。--force-with-lease更安全------如果远程分支有你本地没有的新提交，会拒绝推送并提示，避免意外覆盖他人代码。
提 PR 后的 commit 记录
vbnet
D' 你的提交（仅此一条，干净清晰）两种方式对比
| merge | rebase | |
|---|---|---|
| 历史记录 | 非线性，含 MergeCommit | 线性，简洁清晰 |
| PR commit 数量 | 自己的 commit + MergeCommit | 只有自己的 commit |
| 推送方式 | 正常 git push |
git push --force-with-lease |
| 冲突处理次数 | 只处理一次 | 每个 commit 都可能处理一次 |
| 适合场景 | 多人协作的公共分支 | 个人功能分支同步主干 |
常见问题
Q：rebase 时提示 hint: use --reapply-cherry-picks to include skipped commits
这是正常现象。rebase 检测到你分支上的某个 commit 内容已经存在于目标分支（例如之前被 cherry-pick 过），会自动跳过该 commit，避免重复提交。
可以关闭这条提示：
bash
git config --global advice.skippedCherryPicks falseQ：rebase 之后提 PR，为什么还是有重复的 commit？
rebase 只改写了本地历史，如果没有执行 force push，远程分支仍然是旧的历史。PR 提的是远程分支，所以重复的 commit 还是会被带进去。
务必在 rebase 完成后执行：
bash
git push origin feature/my-work --force-with-leaseQ：git pull 默认是 merge，能改成 rebase 吗？
可以，设置全局配置：
bash
# git pull 默认使用 rebase
git config --global pull.rebase true设置后，git pull 等价于 git pull --rebase，不再产生多余的 MergeCommit。
总结
- 个人功能分支 同步主干，推荐使用 rebase，PR 历史干净，只包含自己真正新增的 commit。
- 公共分支 之间的合并，推荐使用 merge，保留完整历史，不需要 force push，更安全。
- 无论哪种方式，同步前都应先执行
git fetch origin获取远程最新状态。