Git变基后Release分支未同步问题及合规修改方案咨询

1. 这是预期行为吗？ #

是的，这完全是预期行为。

你对Feature分支执行git rebase commit_id，只是修改了Feature分支的本地提交历史，让它的起点从原Release分支的某个节点切换到了commit_id。而PR合并到Release分支的操作（无论是普通合并、 squash合并还是rebase合并），核心是把Feature分支的增量内容整合到Release分支中，不会改动Release分支已有的历史基线——Release分支会保留原本从仓库根节点到合并前的完整提交链，仅在末尾新增合并相关的提交（或Feature分支的提交）。

2. 如何在PR限制下将Release分支变基到目标历史提交？ #

由于禁止直接推送Release分支，必须通过PR流程操作，可按以下步骤执行：

• 基于目标历史提交commit_id创建临时Feature分支

  git checkout commit_id
  git checkout -b feature/rebase-release-to-target
  

• 迁移原Release分支的后续提交到新分支
  需要把原Release分支中commit_id之后产生的所有提交迁移到新分支，有两种常用方式：

  • 方式一：用rebase --onto批量迁移
    先拉取远程最新的Release分支：

    git fetch origin
    

    执行rebase命令完成批量迁移：

    git rebase --onto commit_id commit_id origin/release
    

    注：如果commit_id是仓库的根提交，替换commit_id为它的父提交哈希，或通过git log确认准确的提交范围。
  • 方式二：逐个cherry-pick提交
    先查看commit_id到远程Release最新提交的所有记录：

    git log --oneline commit_id..origin/release
    

    复制输出的提交哈希，逐个执行cherry-pick：

    git cherry-pick <提交哈希1>
    git cherry-pick <提交哈希2>
    # 若出现冲突，解决后执行git cherry-pick --continue
    

• 强制推送临时Feature分支到远程

  git push -u origin feature/rebase-release-to-target --force
  

• 发起PR并合并
  在PR描述中明确说明操作目的是将Release分支基线调整到commit_id，等待审核通过后合并。合并完成后，远程Release分支的历史就会以commit_id为起点，包含原有的后续提交。

注意：这种操作会修改Release分支的历史，需提前告知团队所有成员。合并完成后，相关人员需执行以下命令同步本地分支：

git fetch origin && git checkout release && git reset --hard origin/release

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