Gitea PR（合并请求）操作

本文为大纲，可根据公司实际流程补充步骤与截图。

目标

  • 会创建 PR、填写说明、关联 Issue
  • 会评审、讨论、合并或关闭 PR

大纲

  1. 何时用 PR

    • 功能分支开发完成后，将代码合并进目标分支（如 main/develop）前，先提 PR，便于评审与记录。
    • 修复BUG,问题存疑时，先提 PR，关联Issue便于评审与记录。

  2. 创建 PR

    • 在仓库页选择「Pull Request」/「合并请求」→ 新建。
    • 选择：源分支（你的开发分支）→ 目标分支（要合入的分支）。
    • 填写标题、描述；可关联 Issue（如 fix #123）。
    • 如有模板，按模板填写（变更说明、测试情况等）。

  3. 评审与讨论

    • 评审人在「Files changed」中评论具体行，或总评。
    • 作者根据评论修改后推送，PR 自动更新。

  4. 合并 PR

    • 合并方式：Merge commit / Squash / Rebase（以仓库设置为准）。
    • 合并前确认：CI 通过、评审通过、无冲突。
    • 合并后：可选「删除源分支」。

  5. 与工作流的关系

    • 推荐与 协作工作流 一致：如 feature 分支 → develop，hotfix → main。

常见问题

问题1：此分支相比基础分支已过期

原因：远程仓库的develop分支被其他人在其他电脑上合并了，导致本地仓库的develop分支落后了。
解决方案：使用git pull --rebase origin develop 命令，将远程仓库的develop分支拉取到本地仓库的develop分支，然后进行合并。

问题2：合并失败，冲突

原因同上，解决方法同上，本地解决冲突后再强制推送此分支。

问题3: 已经提交评审的PR，需要修改代码，如何操作？

问题场景：

  • 评审人提出了修改意见，需要修改代码。
  • 作者需要修改代码，但是不想重新提交PR，只想修改已有的PR。
    解决方案：当前分支名称直接修改后推送，Gitea会自动更新PR。

问题4：已经合并的PR，需要修改代码，如何操作？

问题场景：

  • 已经合并的PR，需要修改代码。
  • 想继续使用此分支进行开发。
    解决方案：已经合并后的分支名不再可用，PR也关闭了，可以创建一个新分支，再提交PR。
    然后再关联旧的PR，已表明上次PR问题修复的延续。