问题描述
最近我遇到了一个关于PR（Pull Request）构建的问题，这个构建似乎只是检查代码是否可以合并，而没有真正基于合并后的代码进行构建。
我一直以为PR构建应该执行以下步骤（假设一个feature分支要合并到master分支）：
– 检出目标分支（master）
– 拉取/合并源分支（feature）
– 确保合并没有问题[或者失败]
– 触发构建的必要步骤，如编译、测试等
– 清理操作
我尝试在互联网上搜索有关PR构建过程的步骤，但没有找到清晰的信息。我想在这个社区中咨询一下，是否我的理解是正确的，或者我一直对PR构建有错误的理解。
附注：
我们正在使用Bitbucket Branch Source Plugin。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在使用不同的CI/CD工具和插件时，PR构建的具体步骤可能会有所不同。以下是一般情况下PR构建可能涉及的步骤：
检出目标分支（master）： 首先，系统会检出目标分支（通常是主分支，如master）的代码。这样可以确保构建和合并代码的基础是正确的。
拉取/合并源分支（feature）： 接下来，系统会拉取或合并源分支（通常是一个功能分支）的代码到目标分支。这个步骤确保了将最新的更改合并到主分支中。
解决合并冲突： 如果在将源分支合并到目标分支时出现冲突，系统会通知开发者并要求解决冲突。解决冲突后，才能继续进行后续步骤。
执行构建步骤： 一旦代码合并成功，系统会触发构建步骤。这可能包括编译代码、运行测试、生成文档等操作，具体取决于项目的需求。
清理操作： 在构建步骤完成后，通常会进行一些清理操作，例如清除临时文件、停止服务等，以确保环境的干净和稳定。
在你提到的Bitbucket Branch Source Plugin的情况下，具体的操作可能会受到插件的影响。你可以根据插件的文档来了解它是如何管理PR构建的流程的。
无论使用哪种工具，PR构建的核心目的都是确保在合并代码到主分支之前，对代码进行必要的测试和验证，以保证新代码的质量和稳定性。具体步骤可能会因项目和工具的不同而有所变化，但核心原则是一致的。
参考资料:
– Understanding the GitHub flow
– Bitbucket Branch Source Plugin Documentation
注意： 根据你所使用的具体工具和插件，上述解决方案可能需要进行适当的调整。始终建议查阅相关工具的文档以获取更详细的信息。