在create-pull-request项目中正确处理非基础分支的变更

在使用peter-evans/create-pull-request这个GitHub Action时，开发者可能会遇到一个常见问题：当从一个非基础分支（非目标分支）开始工作时，所有在该分支上的变更会在创建Pull Request时被意外重置。这种情况通常发生在复杂的自动化工作流中，特别是涉及多个临时分支的场景。

问题背景

在一个典型的工作流中，开发者可能会：

1. 首先更新项目的主锁文件，并将更改推送到一个临时分支
2. 基于这个锁文件运行多个任务，每个任务更新项目的不同部分并推送到各自的临时分支
3. 最后将这些变更合并到目标分支并创建Pull Request

问题出现在第三步，当尝试从临时分支（而非目标分支）开始工作时，create-pull-request操作会将这些变更重置到目标分支的状态，导致部分或全部变更丢失。

技术原理分析

create-pull-request的工作原理是：

1. 识别当前工作分支
2. 将当前分支的变更与目标分支（base）进行比较
3. 创建一个新的Pull Request分支，包含这些变更

当从非目标分支开始时，操作会尝试将这些变更"重新基于"目标分支。如果这些变更本身已经包含了目标分支的某些历史，这个过程可能会导致意外的重置行为。

正确的工作流设计

为了避免这个问题，应该遵循以下最佳实践：

1. 始终从目标分支开始：在创建Pull Request前，确保工作流从目标分支（如main）检出开始
2. 明确变更范围：只将需要包含在PR中的变更cherry-pick到工作分支
3. 保持分支线性：避免在临时分支中包含目标分支的历史

解决方案示例

steps:
  - uses: actions/checkout@v4
    with:
      fetch-depth: 0
      ref: main  # 明确从目标分支开始

  - name: 合并需要的变更
    run: |
      # 从临时分支cherry-pick需要的提交
      git fetch origin ci/bump-versions/${{ github.sha }}/flake
      git cherry-pick <commit-hash>

  - name: 创建Pull Request
    uses: peter-evans/create-pull-request@v7
    with:
      base: main  # 目标分支
      branch: feature-branch  # PR分支

总结

理解create-pull-request的内部工作机制对于设计可靠的工作流至关重要。关键是要记住：Pull Request总是相对于某个基础分支的变更集。通过始终从目标分支开始工作，并明确选择要包含的变更，可以避免意外的重置行为，确保所有预期的变更都能正确地包含在最终的Pull Request中。

对于复杂的自动化场景，建议先在小规模测试仓库中验证工作流设计，确保变更能够按预期被捕获和包含。这样可以避免在生产环境中遇到意外的分支管理问题。