D365 - Azure Devops - Git Repo - 如何检查存储在主分支的单独文件夹中的文件的历史记录 [英] D365 - Azure Devops - Git Repo - How to check the history of a file which is stored in separate folders in the Main branch

问题描述

在我们公司，我们正在开发 D365，我们将每个更改导出为补丁解决方案，创建一个分支，然后执行拉取请求并与主合并.

In Our company, we are developing D365 and we export each change as a patch solution, create a branch and then do a pull request and merge with the main.

补丁在 Main 中合并为单独的文件夹.

The patches are merged as separate folders inside Main.

例如.我修改了一个名为solution.xml"的文件.在 Dynamics 中，创建一个补丁，签入补丁并将合并为MustaqueTest_Patch_5fa28cd1\Other\Solution.xml"；并在下一次更改为相同的solution.xml"文件，合并后将合并到不同的文件夹MustaqueTest_Patch_fe90da4e\Other\Solution.xml"下.同样.

eg. I modify a file named "solution.xml" in Dynamics, create a patch, check in the patch and will be merged as "MustaqueTest_Patch_5fa28cd1\Other\Solution.xml" and in the next change to the same "solution.xml" file, after merge it will be merged under a different folder "MustaqueTest_Patch_fe90da4e\Other\Solution.xml." and likewise.

我被困在这里的挑战是查看文件的版本更改.由于这些文件被添加到单独的文件夹中，我无法检查该文件的版本历史.

The challenge I am stuck here is to view the version changes for the file. As these are added in separate folders, I couldnt check the version history of that file.

你能建议如何做到这一点吗?

Can you please advise how this can be done ?

另一个挑战是当我检查 git diff 时，我必须知道签入层次结构的顺序来比较哪个困难.

Another challenge is when i checked the git diff, I had to know the sequence of checkin hierarchy to compare which is difficult.

git diff :MustaqueTest_Patch_fe90da4e/Other/Solution.xml MustaqueTest_Patch_124985mp/Other/Solution.xml

git diff :MustaqueTest_Patch_fe90da4e/Other/Solution.xml MustaqueTest_Patch_124985mp/Other/Solution.xml

根据最新评论，对于 Main 中的那些文件，我看不到用于检查以前文件的提交选项.

As per the latest comment, for those files in the Main, I couldnt see the commit option to check with the previous files.

推荐答案

我认为我无法为您提供一种更好的方法来比较补丁之间的更改.不过，我将尝试提供一些有关我们如何跟踪解决方案更改的见解，以及一些可能会改进您在 Dynamics 和源代码控制中管理解决方案的方式的建议.

I don't think I can provide a better way for you to compare changes across patches. However I will try provide some insight into how we track changes to solutions and some suggestions that may improve how you manage solutions in Dynamics and in source control.

... 并在下一次更改为相同的solution.xml"文件，合并后会合并到不同的文件夹下

... and in the next change to the same "solution.xml" file, after merge it will be merged under a different folder

如果您正在编辑同一个补丁，那么您应该将 solution.xml 解压到同一个文件夹中，而不是创建一个新文件夹.补丁将有一个唯一的名称 {BaseSolutionName}_Patch_{PatchId}.

If you are editing the same patch, then you should be unpacking the solution.xml into the same folder, not creating a new one. The patch will have a unique name {BaseSolutionName}_Patch_{PatchId}.

如果您要创建新补丁，则应始终将其解压缩到基于唯一名称的新文件夹中.

If you are creating an new patch, then this should always be unpacked into a new folder based on the unique name.

补丁是对基本解决方案进行更改的容器.我认为您不应该经常比较同一解决方案的两个或多个补丁，以免造成麻烦.例如，如果您要跨两个补丁修改 Account 实体主表单，则

The patches are a container of changes to the base solution. I don't think you should be comparing two or more patches of the same solution so often that this is a hassle. For example, if you are modifying the Account entity main form across two patches, then

1. 您应该在单个补丁中进行这些更改，因为组件更改不会与它们在其中进行的解决方案隔离
2. 当 solution.xml 被解压时，您对表单所做的更改将显示在两个补丁中，因为表单包含在两个补丁中

1. You should be making these changes in a single patch due to how component changes are not segregated to the solution they were made in
2. The changes you make to the form will show in both patches when then solution.xml is unpacked, as the form is included in both patches

解决方案打包工具

正如您帖子中的评论所提到的，这不是理想的方式跟踪变化.在理想情况下，您将整个解决方案和补丁解压缩到源代码管理中，作为代表补丁中包含的每个组件的单独 XML 文件.为此，您可以使用诸如 SolutionPackager 之类的工具.

这个工具:

... 可逆地将 Microsoft Dataverse 压缩解决方案文件分解为多个 XML 文件和其他文件，以便源代码控制系统可以轻松管理这些文件 (源)

... reversibly decompose a Microsoft Dataverse compressed solution file into multiple XML files and other files so that these files can be easily managed by a source control system (source)

您的补丁仍将存在于单独的文件夹中直到您将补丁汇总到您的基本解决方案中，但您可以更轻松地比较对补丁所做的更改.

Your patches would still exist in separate folders until you roll-up your patches into your base solution, but you can more easily compare changes made to patches.

当补丁被汇总到基础解决方案中时，您的补丁文件夹应该被删除(因为不再存在于 Dynamics 中，所以不应该存在于源代码管理中).在您的补丁中所做的所有更改现在将表示为对基本解决方案中的 solution.xml 的更改，而不是针对每个补丁的单独 solution.xml 中的更改.

When the patches are rolled up into the base solution, your patch folders should be deleted (as the no longer exist in Dynamics, so should not exist in source control). All the changes made in your patches will be represented as changes to the solution.xml in the base solution now, instead of changes in separate solution.xmls specific to each patch.

我强烈建议使用 ALM 工具集来简化解决方案的打包、解包、部署和更改跟踪.有很多可用的，但我推荐 Microsoft.PowerPlatform.DevOps

I would highly recommend using a ALM toolset to simplify the packing, unpacking, deployment and change tracking of solution. There are many available , but I recommend Microsoft.PowerPlatform.DevOps

希望这会有所帮助.

这篇关于D365 - Azure Devops - Git Repo - 如何检查存储在主分支的单独文件夹中的文件的历史记录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！