在个人分支整理时优先用变基保持历史整洁，在公共分支协作时务必用合并避免历史篡改。
先说结论：变基适合整理本地未推送的提交，合并适合集成公共分支代码。
- 适合：本地功能分支清理、上线前历史梳理
- 重点看：分支是否已推送到远程、是否有他人基于该分支开发
- 别忽略：变基会改写提交哈希，公共分支变基会导致协作冲突
命令速用版
# 变基操作（整理本地历史）
git checkout feature-branch
git rebase main
# 合并操作（集成公共代码）
git checkout main
git merge feature-branch
# 查看历史图谱
git log `--graph` `--oneline` `--all`为什么会这样
变基（rebase）的本质是将当前分支的提交“挪动”到目标分支的顶端，它会让提交历史变成一条直线，看起来干净，但会修改提交的哈希值。合并（merge）则是创建一个新的合并提交，将两条历史线连在一起，保留了分支产生的真实时间和上下文。
如果分支只在本地使用，没人依赖你的提交历史，变基能让 review 代码时更清晰。一旦分支推送到远程且其他人可能基于此开发，变基就会改变历史，导致他人拉取代码时出现冲突或重复提交，这时候合并才是安全的选择。
分步处理
场景一：本地功能分支整理（使用变基）
1. 确认分支未推送或仅自己使用：检查远程是否有同名分支，或确认队友没有基于该分支开发。
2. 执行变基：在功能分支上运行 git rebase main，将主分支的最新变更应用到当前分支顶端。
3. 处理冲突：如果有冲突，Git 会暂停，手动修改文件后运行 git add . 和 git rebase `--continue`，直到完成。
4. 强制推送（如果需要）：若之前推送到过远程，变基后哈希变了，需用 git push `--force-with-lease` 覆盖远程历史。
场景二：公共分支集成（使用合并）
1. 更新主分支：先切到主分支运行 git pull 确保本地最新。
2. 执行合并：切回主分支，运行 git merge feature-branch。
3. 保留记录：合并提交会保留功能分支的存在痕迹，方便后续追溯某个功能是什么时候引入的。
怎么验证是否生效
使用图谱命令查看历史结构。运行 git log `--graph` `--oneline` `--all`。
如果是变基成功，你会看到功能分支的提交整齐地排列在主分支最新提交之后，没有分叉线。如果是合并成功，你会看到一个菱形的合并提交节点，连接了两条分支线。
另外，检查远程状态：运行 git status 确认没有未推送的变更，或确认推送是否成功。
常见坑
1. 公共分支误用变基：这是最危险的操作。如果多人协作同一分支，你变基后强制推送，队友再次推送时会覆盖你的修改，导致代码丢失。
2. 变基中途放弃：如果在 rebase 过程中遇到复杂冲突想放弃，不要直接 checkout 其他分支，应运行 git rebase `--abort` 回到变基前的状态。
3. 忽略提交哈希变化：变基后提交 ID 会变，之前在代码审查系统里关联的提交链接可能失效，通知团队成员同步更新本地分支。
4. 交互式变基风险：使用 git rebase -i 可以压缩或修改提交，但操作失误容易丢失提交，建议先在测试分支练习。