在我们公司，我们正在开发D365，我们将每个更改导出为补丁解决方案，创建分支，然后执行拉入请求并与Main合并。
这些面片将合并为Main内的单独文件夹。
例如。我在动力学中修改了一个名为“soltion.xml”的文件，创建了一个补丁，签入补丁，并将其合并为“MustaqueTest_Patch_5fa28cd1\Other\Solution.xml”，在下一次更改为相同的“soltion.xml”文件时，合并后它将被合并到不同的文件夹“MustaqueTest_Patch_fe90da4e\Other\Solution.xml.”下同样也是如此。
我在这里遇到的挑战是查看文件的版本更改。因为它们被添加到不同的文件夹中，所以我无法检查该文件的版本历史。
你能告诉我如何做到这一点吗？
另一个挑战是，当我检查git diff时，我必须知道要比较的签入层次的顺序，这是困难的。
Git Diff：MustaqueTest_Patch_fe90da4e/Other/Solution.xml MustaqueTest_Patch_124985mp/Other/Solution.xml
根据最新的评论，对于主中的那些文件，我看不到提交选项来检查以前的文件。
1条答案
按热度按时间px9o7tmv1#
我认为我不能为您提供一种更好的方法来比较补丁之间的更改。但是，我将尝试提供一些关于我们如何跟踪解决方案更改的见解，以及一些可能会改进您在Dynamic和源代码控制中管理解决方案的方式的建议。
多个补丁
..。在下一次更改相同的“soltion.xml”文件时，合并后它将被合并到不同的文件夹下
如果您正在编辑相同的补丁，那么您应该将
solution.xml解压到相同的文件夹中，而不是创建一个新的。补丁程序将具有唯一的名称{BaseSolutionName}_Patch_{PatchId}。如果您要创建新补丁，则应始终将其解压缩到基于唯一名称的新文件夹中。
补丁是基本解决方案更改的容器。我认为您不应该如此频繁地比较同一解决方案的两个或多个补丁，以至于这是一件麻烦的事情。例如，如果要跨两个修补程序修改帐户实体主窗体，则
1.您应该在单个补丁程序中进行这些更改，因为组件更改没有与在其中进行更改的解决方案分开
1.当解压
solution.xml时，您对表单所做的更改将显示在两个补丁中，因为表单包含在两个补丁中解决方案打包工具
正如您帖子上的评论所提到的，这不是跟踪更改的理想方式。在理想情况下，您应该将整个解决方案和补丁程序解包到源代码管理中，作为表示补丁程序中包含的每个组件的单独的XML文件。为此，您需要使用SolutionPackager之类的工具。
此工具：
..。可逆地将Microsoft Dataverse压缩解决方案文件分解为多个XML文件和其他文件，以便这些文件可以由源代码控制系统(source)轻松管理
您的补丁程序仍将存在于单独的文件夹中**，直到**您将补丁程序汇总到您的基本解决方案中，但您可以更轻松地比较对补丁程序所做的更改。
补丁汇总
当补丁被卷到基本解决方案中时，您的补丁文件夹应该被删除(因为Dynamic中不再存在，所以应该不存在于源代码管理中)。现在，在补丁程序中所做的所有更改将表示为对基本解决方案中
solution.xml的更改，而不是特定于每个补丁程序的单独solution.xml中的更改。预建ALM解决方案
我强烈建议使用ALM工具集来简化解决方案的打包、解包、部署和更改跟踪。有很多可用的，但我推荐Microsoft.PowerPlatform.DevOps
希望这能有所帮助。