Git提交修正（amend）后快速处理依赖分支的方法咨询

基础场景 #

初始提交结构：

parent--- a1a1a1 (A) --- b1b1b1 (B)
                            ^
                            |
                           HEAD

切换至分支A完成修改后，执行git commit --amend（未修改提交信息），提交树变为：

parent--- a1a1a1 --- b1b1b1 (B)
      \
       -- a2a2a2 (A)
             ^
             |
            HEAD

原处理流程需删除重建分支B并移植提交：

git branch -D B # 删除旧分支B
git switch -c B # 创建新分支B
git cherry-pick b1b1b1 # 移植旧提交b1b1b1

最终提交结构：

parent--- a1a1a1 --- b1b1b1
      \
       -- a2a2a2 (A) --- b2b2b2 (B)
                            ^
                            |
                           HEAD

该流程在多依赖分支下过于繁琐，求更高效的处理方式。

合并提交场景 #

当存在合并提交时，操作难度进一步提升：

parent--- a1a1a1 (A) --- b1b1b1 (B) --- d1d1d1(D)
      \                               /
       -- c1c1c1 (C) -----------------

此时对A执行git commit --amend后，难以保证其他分支（尤其是合并提交D）的正确性。

背景 #

工业协作场景中，无法等待分支A合并后再开发分支B，通常会提交A审核的同时并行开发B。若收到A的评审意见，需用git commit --amend整合修改，之后要继续开发B或处理合并提交D，反复重排操作十分繁琐。

优化解决方案 #

基础场景：用git rebase --onto替代删除重建

无需删除分支B，直接在分支B上执行以下命令即可将提交重放到新的A分支之上：

# 切换到分支B
git switch B
# 将B中基于旧A（a1a1a1）的提交重放到新A（a2a2a2）上
git rebase --onto a2a2a2 a1a1a1

执行后提交树会直接更新为目标结构，一步完成分支B的基准切换。

合并提交场景：用git rebase -r保留合并结构

针对包含合并提交的复杂分支，使用带-r（--rebase-merges）参数的rebase命令，可在重排时保留原有的合并逻辑：

# 切换到分支D
git switch D
# 重排D分支，以新A（a2a2a2）为基准，保留合并提交
git rebase -r --onto a2a2a2 a1a1a1

该命令会重新执行原合并操作，确保合并提交D能基于新的A提交正确重建，避免手动处理合并冲突的繁琐。

额外建议：减少重复重排的技巧

若分支A可能收到多次评审修改，建议先在A分支新增修复提交，待所有评审意见处理完毕后，再用git rebase -i将修复提交squash到原A提交中，最后对所有依赖分支执行一次rebase。这种方式可避免每次修改A后都要重排依赖分支，减少操作次数。

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