Git进阶：Rebase vs Merge、交互式变基与团队协作工作流策略
Git的提交历史不仅是代码变化的记录，也是团队协作和问题定位的重要工具。一个混乱的提交历史（充满”fix typo”、”WIP”、”merge branch ‘dev’ into feature/xxx”等噪音提交）使`git log`、`git bisect`和`git blame`的使用价值大打折扣。进阶Git技能的核心目标之一是维护有意义的、可读的提交历史。
Merge vs Rebase：根本区别
`git merge`会保留所有分支历史，生成一个新的合并提交（Merge Commit）。如果主分支（main/master）在你的功能分支开发过程中有了新提交，merge后的历史会呈现出分叉-合并的DAG结构。优点：完整保留历史真相，任何时候都能看出代码是何时从哪里合并来的。缺点：提交历史是非线性的，在有大量功能分支并行开发的项目中会变得难以阅读。
`git rebase`将你的分支提交”重新播放”在目标分支的最新提交之上，使历史保持线性。优点：线性历史，`git log`读起来像一条清晰的故事线。缺点：改写了提交哈希（在已推送的分支上使用需要`git push –force`，存在风险），不保留分支的真实合并历史。
黄金规则：永远不要对公共/共享分支进行rebase。对本地功能分支在合并前进行rebase是标准实践，但对main分支rebase会导致其他开发者的历史失效。
交互式变基（Interactive Rebase）
`git rebase -i HEAD~N`（N为想要整理的提交数量）是Git最强大的历史整理工具：可以合并（squash）多个小提交为一个有意义的提交，修改提交消息（reword），删除某个提交（drop），或调整提交顺序。在提交Pull Request前用交互式变基整理本地提交历史，是维护整洁项目历史的重要实践。
Conventional Commits规范（`feat:`、`fix:`、`chore:`、`docs:`前缀）与自动化变更日志工具（如`conventional-changelog`）结合，是大型开源项目管理提交历史的标准做法。
