Git子子分支变基的最优实现策略咨询

我们采用的分支结构：

• 以develop为基础分支，衍生epic分支对应史诗级需求
• 从epic分支拉出feature分支，对应史诗下的单个用户故事
• 完成的feature分支合并回epic，最终epic合并到develop

场景背景 #

初始分支历史如下：

develop: A -> B
epic: A -> B
feature-branch-1: A -> B -> C -> D 
feature-branch-2: A -> B -> C -> D -> E -> F

feature-branch-1经评审修改后，追加提交J、K，随后与epic变基，分支历史变更为：

feature-branch-1: A -> B -> P
feature-branch-2: A -> B -> C -> D -> E -> F

需要将feature-branch-2的历史调整为：

feature-branch-2: A -> B -> P -> E -> F 

目前采用临时分支+删除重建+cherry-pick的方式，寻求更高效的解决方案。

最优解决方案：使用git rebase --onto命令 #

无需创建临时分支或逐个cherry-pick提交，直接通过--onto参数精准指定变基的目标分支和需要保留的提交范围：

步骤1：切换到目标分支 #

git checkout feature-branch-2

步骤2：执行定向变基 #

git rebase --onto的核心语法是：

git rebase --onto <目标分支> <需要跳过的提交截止点>

在这个场景中：

• <目标分支>是feature-branch-1（即最终要基于的A->B->P）
• <需要跳过的提交截止点>是feature-branch-2中E之前的最后一个旧提交D（也就是我们要丢弃C、D，只保留E、F）

首先通过git log feature-branch-2找到D的提交哈希（比如d123456），然后执行：

git rebase --onto feature-branch-1 d123456

步骤3：验证结果 #

变基完成后，查看分支历史确认结构：

git log --oneline feature-branch-2

此时分支历史应显示为A -> B -> P -> E -> F。

冲突处理 #

如果变基过程中出现代码冲突：

1. 手动编辑冲突文件，解决冲突
2. 执行git add <已解决冲突的文件>
3. 执行git rebase --continue继续变基流程
4. 若需终止变基，可执行git rebase --abort

协作注意事项 #

如果feature-branch-2已经推送到远程仓库，变基后需要强制推送更新：

git push -f origin feature-branch-2

执行前需确保团队内其他成员知晓此操作，避免本地分支与远程分支出现不一致。

内容的提问来源于stack exchange，提问作者Pranav Suryadevara