多开发者未签名提交分支如何合并到要求签名的main分支

问题场景 #

• 待合并分支（示例名feature-x）包含多位开发者提交的未签名commit，向开启了「基准分支所有提交必须签名」规则的main分支发起合并时被拦截
• 本地合并后直接推送main不可行，分支保护规则要求至少1位有写入权限的评审者审批，直接推送会报如下错误：

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: At least 1 approving review is required by reviewers with write access.

• 直接基于当前main拉取新分支重提PR无法解决问题，新分支会完整继承feature-x上的所有未签名提交
• 临时关闭分支保护规则可完成合并，但属于绕过规则的应急手段，仅适合规则刚上线、存量未签名PR集中处理的场景，不适用于规则常态化执行的情况

可行操作方案 #

方案1：批量补全分支所有提交签名后走正常PR流程 #

单个开发者即可完成分支全量提交的补签名操作，注意该操作会重写分支提交历史，所有旧提交会生成新的commit hash，补签后的提交签名归属为执行操作的开发者，原提交的作者信息会正常保留。
操作步骤：

1. 本地拉取最新的远程feature-x分支代码，确认本地工作区无未提交的改动
2. 执行带补签逻辑的变基命令，从feature-x和main的分叉点开始，给所有历史提交补签名：

   git rebase -i --exec 'git commit --amend --no-edit -n -S' -i main
   

   命令说明：--exec参数会对变基范围内的每一个提交执行后续的补签命令，-S会调用本地提前配置好的GPG密钥为提交签名，--no-edit表示保留原有提交信息不做修改
3. 变基执行完成后，将补签后的代码推送到远程新分支（不建议直接强推原feature-x分支，避免影响其他协作者的本地工作）：

   git push origin HEAD:feature-x-signed --force
   

4. 基于新的feature-x-signed分支向main发起PR，走正常的评审审批流程即可。此时分支上所有提交都带有有效GPG签名，满足保护分支的校验要求，审批通过后可直接合并，无需绕过保护规则直接推送main。

方案2：使用Squash压缩提交合并（操作成本最低） #

如果团队不需要保留feature-x分支上细粒度的提交记录，可以直接在PR合并选项中选择Squash Merge（压缩合并），执行合并操作时，平台会自动将分支上的所有提交压缩为1个新提交，由点击合并按钮的账号为这个新提交签名，天然满足分支保护的签名校验要求，不需要提前对历史提交做任何处理。

注意事项 #

• 如果团队规则要求提交签名必须和提交作者一一对应，那么单个开发者批量补签的方案不适用，需要每个提交的作者在本地给自己的提交补签后，再统一合并提交记录
• 重写分支历史强推前，必须和所有在该分支上协作的开发者同步信息，避免其他人基于旧提交开发的代码丢失
• 长期来看，需要求所有开发者本地配置Git自动GPG签名，从提交源头避免未签名提交进入代码库，减少后续补签的额外工作量

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