在过去的十年中，软件渐渐成为了一个行业热点，我们的客户需要在更短的开发周期内开发更多且质量更高的软件。客户们希望能够将基于模型的开发（MBD）与持续集成和测试过程相结合，我们对此非常理解。出于这个原因，我们推翻了所持有的观念，以提供最佳的解决方案。有一种观点认为，MBD 文件（例如 *.dd、*.mdl 或 *.slx 文件）不适合在拉取请求工作流中进行审查、评论和批准。在这篇博文中，我们会向您展示我们的解决方案，该解决方案使用带 MBD 文件的拉取请求，致力于推进您的软件开发进程。

拉取什么呢？拉取请求的简要说明

开发软件通常最好分多个小步骤完成。所有更改都存储在应用程序生命周期管理（ALM）套件中，比如 Microsoft® Azure DevOps。为确保多个开发人员并行工作而不会相互干扰各自开发的功能，您可以创建功能分支。功能分支是用于处理特定功能或修补程序的单独位置。每个功能分支必须合并回主分支，而主分支不会直接更改。这是拉取请求的有用之处。拉取请求可简化开发人员的协作并确保流程安全，因为它们确保每个更改在合并到主分支之前都经过适当的审查。在拉取请求中，团队可以直接查看更改，并通过 ALM 的 Web 界面讨论建议的功能或修补程序的实现。在迭代过程中，团队提供反馈或调整实现。一旦实现被认为是好的，它就会合并到主分支中。在创建拉取请求之前，将主分支合并到功能分支中非常有用，这样可以检查自创建功能分支以来是否对主分支进行了任何更改，并解决可能的冲突。

面对 MBD 文件的问题

对 MBD 文件使用拉取请求的主要问题是团队只被告知两个不同的文件修订，而不是显式更改。这意味着变化之处不能像源代码文件那样直接显示在 ALM 的 Web 界面中。然而，可以使用像 Model Compare 这样的商业比较工具。要使用它们进行审阅，每个团队成员都必须下载原始版本和修改版本并在本地进行比较。这会对工作流产生负面影响，如果不额外处理，就不允许用户直接检查、评论或批准更改。然而，这些问题势必要解决。

拉取请求工作流中 MBD 文件的解决方案

要对 MBD 文件使用已建立的源文件的拉取请求工作流，您可以为更改的文件修订自动创建差异报告。这意味着每个拉取请求或更新都会触发差异报告的创建过程。这些报告发布到共享位置，例如工件服务器、共享网络驱动器或直接附加到拉取请求。这就允许团队成员直接查看更改并评论更改。拉取请求的作者可以过滤所有打开的评论，在其本地开发环境中修复它们并更新拉取请求。每次更新拉取请求时，都会自动生成一个新的差异报告。这有利于产生无缝的拉取请求工作流，直到它完成并合并到主分支中。。我们建议检查主分支上是否有任何更改，因为功能分支是通过将主分支合并到功能分支中创建的。如果主分支和功能分支上的 MBD 文件发生更改，则在本地开发环境中可以轻松解决文件冲突。

启动您的拉取请求之旅

在您正式开始之前，我们希望您为您的拉取请求工作流提供以下提示：

• 将大功能拆分为多个小部分。在连续的流程中，更改通常会被集成或测试。因此，请避免具有数千个模型元素更改的拉取请求。
• 清楚地分离更改。拉取请求不应混淆多个任务。因此，请为每个功能或修补程序使用一个分支和拉取请求。如果无法隔离更改，请创建不同的提交以允许审阅者区分更改。
• 在创建拉取请求之前，将主分支中可能的更改整合到功能分支中。这大大降低了合并冲突的可能性。

推翻持有的观念

日复一日，我们遇到根深蒂固的观念。所以，您也可以在这篇博客文章的结尾用“没有什么不可能的”这句话来结束，因此提到穆罕默德·阿里。阿里从未说过这些话，我们的观念不过是基于一家知名体育用品制造商的广告语。然而，这种思维方式具有梦寐以求的力量，因为不可能性可以代表潜力并推动变革。出于这个原因，dSPACE 始终尝试挑战我们的观念，为客户提供解决问题的最佳解决方案。在这篇博文中，我们概述了建立带有 MBD 文件的拉取请求工作流的解决方案。这使我们的客户能够在更短的开发周期内开发更多、更高质量的软件，因为拉取请求已经证明可用于源代码文件。在生活中，变则通，通则久。因此，我们鼓励您与我们联系并分享您对该主题的经验或要求。这将有助于我们进一步优化我们的解决方案，以帮助您取得成功。