create-pull-request项目分支更新机制深度解析

核心问题场景

在GitHub Actions工作流中使用create-pull-request项目时，开发者发现当目标分支（如testing分支）已存在未合并提交时，执行操作后原有提交会被新提交覆盖，而非预期中的保留历史提交并追加新变更。

技术原理剖析

该现象本质上是create-pull-request的标准工作模式所致。其默认行为是：

1. 分支创建策略：当指定现有分支作为PR分支时，并非直接在该分支上追加提交，而是会：

   • 基于当前工作区创建临时分支
   • 将临时分支重置（reset）到目标分支最新状态
   • 强制推送（force-with-lease）覆盖原分支

2. 版本树重构：该操作会重构分支的提交历史，使分支仅包含本次工作流产生的新提交，而非保留原有提交历史。

解决方案

针对需要保留历史提交的场景，推荐以下两种技术方案：

方案一：预合并工作流

- name: 合并现有变更
  run: |
    git config --global user.name "GitHub Actions"
    git config --global user.email "[e-mail]"
    git checkout testing
    git merge --no-ff $GITHUB_SHA

方案二：使用分支保护策略

1. 在仓库设置中为testing分支启用分支保护
2. 配置"Require linear history"选项
3. 工作流中增加分支状态检查步骤

最佳实践建议

1. 环境分支分离：建议区分长期分支和临时PR分支

   • 长期分支：用于累积变更（如dev）
   • 临时分支：由create-pull-request自动管理

2. 提交策略优化：

   • 对需要保留历史的变更使用rebase而非merge
   • 考虑使用--no-ff保持合并提交记录

3. 工作流设计：

   • 对关键分支设置force-push保护
   • 在重要操作前添加分支状态检查

技术思考

这种设计实际上体现了Git工作流的两种哲学：

• 重写历史（适合功能开发分支）
• 保留历史（适合集成分支）

理解这一点有助于根据实际场景选择合适的工具配置。对于需要严格保留提交历史的场景，可能需要考虑其他工作流设计或自定义Action实现。

总结

create-pull-request项目的这一行为是其设计特性而非缺陷，理解其底层机制可以帮助开发者更好地规划代码提交流程。在持续集成环境中，明确分支用途并建立相应的工作流规范，是避免此类问题的根本解决方案。