Git分支管理merge rebase详解

merge和rebase都是用来整合分支变更的，但底层逻辑完全不同。merge保留历史拓扑，rebase重写历史。选哪个取决于你要什么效果。 merge — 合并提交

git checkout main
git merge feature

merge会创建一个新的合并提交，这个提交有两个父节点。历史图上能看到分支分叉再合并的痕迹。适合公共分支，因为不会改动已有提交。 常用参数：

git merge --no-ff feature   # 强制创建合并提交，即使可以fast-forward
git merge --squash feature  # 把feature所有提交压缩成一个新提交，不保留分支历史

squash merge适合合并琐碎的开发提交，比如”fix typo””wip”这类垃圾提交。合并后feature分支的每个commit都消失了，只留下一个干净的变更。但注意，squash后的提交和feature分支没有父子关系，后续再改feature分支会产生冲突。 rebase — 变基

git checkout feature
git rebase main

rebase把feature分支上的每个提交逐个应用到main的顶端。效果是feature分支看起来像从main最新节点直接长出来的，历史是一条直线。 rebase的核心操作是：找到两个分支的共同祖先，把当前分支从祖先之后的每个提交暂存，切换到目标分支，再逐个应用。如果有冲突，解决后执行`git rebase –continue`，跳过一个commit用`–skip`，放弃操作用`–abort`。 什么时候用rebase – 自己维护的本地分支，还没推送到远程 – 想保持提交历史线性，方便git bisect二分查找 – 合并前整理提交，用`git rebase -i`交互式变基 交互式变基可以重排、合并、修改、删除提交：

git rebase -i HEAD~3  # 修改最近3个提交

编辑器里会显示每个commit，把pick改成squash就把当前提交合并到上一个。改commit message用reword。 什么时候用merge – 公共分支（main、develop），多人协作 – 需要保留分支合并的拓扑信息 – 不想改写别人的提交 一个典型工作流 开发新功能时，从main创建feature分支。开发过程中main有更新，在feature分支上执行`git rebase main`，把基础更新到最新。这样feature分支始终基于当前main，合并时不会出现大量冲突。 推送前再做一次rebase，用`git merge –no-ff`合并回main。远程仓库里main能看到一个清晰的合并节点，feature分支的细节在合并提交里。 rebase的陷阱 永远不要对已经推送到远程的分支做rebase。如果其他人在你的分支基础上开发，rebase会改变提交哈希，导致对方pull时出现大量重复提交。强制推送（`git push –force`）会搞乱所有人的仓库。 如果真的需要修改远程分支，用`–force-with-lease`比`–force`安全，它会检查远程分支是否被其他人更新过。 cherry-pick — 精挑细选

git cherry-pick <commit-hash>

把某个分支上的特定提交应用到当前分支。适合修复bug：在main上修了bug，用cherry-pick把修复提交复制到release分支。注意cherry-pick会创建新提交，哈希值不同。 实际场景对比 假设feature分支有3个提交，main分支有2个新提交。 merge的最终状态：main指向一个合并提交，feature分支指向原来的3个提交。历史图上有分叉。 rebase的最终状态：feature分支指向3个新提交（哈希值变了），这3个提交基于main的最新节点。历史是一条直线。 如果feature分支只用于本地开发，选rebase。如果feature分支被多人共享，选merge。 关于服务器 如果你需要托管Git仓库或跑CI/CD，雨云性价比高、稳定、好用。我个人的项目就部署在雨云上，GitLab和Jenkins跑起来没出过问题，延迟低，磁盘IO够用。

雨云是国内一家老牌云服务商，提供高性价比的云服务器和虚拟主机。我用它部署了好几个项目，速度和稳定性都不错。通过 https://www.rainyun.com/SAJA_ 注册可以领一张 5折优惠券，有需要的朋友可以看看。