Git中能否将分支及其未合并的子分支一同执行变基操作？

没问题，完全可以做到，但得按正确的顺序操作——毕竟你的子分支是基于feature-1的旧版本，直接变基父分支不管子分支的话，后续子分支会出现历史分叉的问题。下面是针对你的分支模型的具体操作步骤和关键注意事项：

操作步骤 #

1. 拉取最新的dev分支
   首先确保本地的dev分支是最新的（已经合并了feature-2的版本）：

   git checkout dev
   git pull
   

2. 变基feature-1到更新后的dev
   切换到feature-1分支，执行变基操作，将它的提交历史重新基于最新的dev：

   git checkout feature-1
   git rebase dev
   

   • 过程中如果遇到冲突，Git会暂停变基，你需要手动解决代码冲突，然后执行git add .标记冲突已解决，再用git rebase --continue继续变基流程。
   • 如果中途想放弃变基，执行git rebase --abort即可回到变基前的状态。

3. 变基子分支到更新后的feature-1
   因为子分支（比如subtask-1-xxxx）原本是基于旧版本的feature-1，现在feature-1的历史已经被变基修改了，所以需要把子弹支也重新基于新的feature-1：

   git checkout subtask-1-xxxx
   git rebase feature-1
   

   • 同样，遇到冲突时按上述方式解决即可。

进阶技巧：用git rebase --onto精准变基 #

如果你的feature-1在变基前有明确的起点（比如知道它最初是从哪个dev的提交分出来的），可以用--onto参数跳过feature-1已经处理过的提交，直接把子弹支的提交移到新的feature-1上，减少重复冲突处理：
假设feature-1旧版本的起点是提交abc123（可以用git log --oneline feature-1 ^dev找到这个起点），那么命令可以写成：

git rebase --onto feature-1 abc123 subtask-1-xxxx

关键注意事项 #

• 不要变基已公开的分支：如果你的feature-1或子分支已经推送到远程仓库，并且有其他团队成员在上面工作，变基后需要强制推送（git push --force-with-lease，比--force更安全），但一定要提前和团队沟通，避免其他人的工作丢失。
• 变基会修改提交历史：这是变基的核心特性，所以只适合在**未合并到公共分支（如dev、master）**的私有分支上操作，符合你当前“尚未完成的feature-1”的场景。
• 保持分支依赖顺序：必须先变基父分支，再变基子分支，否则子分支会基于旧的父分支历史，导致后续合并出现不必要的冲突。

内容的提问来源于stack exchange，提问作者Lyubomyr Shaydariv