我使用beyond-compare来解决合并冲突，并使用git扩展来执行git命令。我的场景是这样的。使用的注释是M表示主提交，P表示父分支提交，C表示子分支提交。
M1 -- M2 -- M3 -- M4 -- ......... -- M50 ...... M60
/ /
/ /
P1 -- P2 -- P3 -- P4 -- P5 /
/
/
C1 -- C2 -- C3 -- C4 -- C5
父分支P5已合并到master，父分支中的所有提交都被压缩，只有一个提交除外，合并后父分支也被删除。我相信这并没有影响到儿童分支。我在子分支中的开发已经完成，我想在master(M60)上用当前提交重新建立子分支的基础。存在合并冲突，因为分支P中的提交和分支C中的提交是在相同的文件(DaVinci、C、C#、xml)上开发的。
关于M60顶部的C分支，我相信我正在做这样的事情。
M1 -- ... -- M50 -- ..... M60
C1 -- C2 -- C3 -- C4 -- C5
我的场景的问题是解决合并冲突。C、xml和C#文件不是问题，但每次我在DaVinci中保存工作空间时，DaVinci都会更新许多密钥(在多个位置上的一些唯一值)，因此这些更改会出现在C分支的多次提交中。我正在使用beyond-compare来解决合并冲突，与在M60创建新分支和在DaVinci中重做工作相比，我似乎花了更多的时间来解决合并矛盾(因为我知道现在需要做什么)。
是否可以仅在分支中的文件的最终版本上解决合并冲突，而不是通过提交来解决冲突？(附言：我不需要提交历史记录)
如果你有更好的想法，请提出建议。
看看git rebase --onto(git help rebase)：
像这样的东西可能对你有用：
git rebase --onto M60 P2
假设您当前正在进行C5提交。
这将从本质上应用当时通过C5在M60上提交的C1，并允许您解决过程中的任何冲突。
完成此操作后，可以通过快进或不快进将新的C5合并到master中。
是否可以仅在分支中的文件的最终版本上解决合并冲突，而不是通过提交来解决冲突？
没有——但是的快捷方式。事实上，有多种可能的捷径；使用哪一个取决于你真正需要什么。
让我复制您的原始图表(有一个小改动)，并假设您使用git rebase --onto:正确地执行了您想要的操作
M1 -- M2 -- M3 -- M4 -- ......... -- M50 ...... M60 <-- master / / P1 -- P2 -- P3 -- P4 -- P5 C1 -- C2 -- C3 -- C4 -- C5 <-- branch
[将成为]
M1 -- ... -- M50 -- ..... M60 <-- master C1 -- C2 -- C3 -- C4 -- C5 <-- branch
(这里真正的变化是注意，提交C5还没有在提交M60时合并到master——如果是，我们需要删除提交M60！)。
现在，该图中的实际错误是C1到C5实际上无法更改。因此，它们将在存储库中保留一段时间，但将不使用。新的提交将有一些新的和不同的散列ID:
M1 -- ... -- M50 -- ..... M60 <-- master
C1'--C2'--C3'--C4'--C5' <-- branch
在这里运行git rebase --onto master P2或类似程序时，您的工作就是生成这些新提交中的每一个。
Git中的每个提交都包含：
- 每个文件的完整快照，以及
- 元数据
完整的快照是你选择的。它包括这些自动生成的密钥：
。。。C、xml和C#文件不是问题，但每次我在DaVinci中保存工作空间时，DaVinci都会更新许多密钥(多个位置的一些唯一值)。。。
如果这些生成的密钥是必需的——如果它们必须在提交中——那么您必须生成它们。
如果可以在每个中间提交中只使用最终键，那就是一个快捷方式：生成一次键，然后用某种自动设备将它们复制粘贴到位。这取决于你想出合适的自动装置；一旦你这样做了，你就有了一个快捷方式：生成最终的密钥并使用这个设备(可能是一个简单的程序，可能是sed脚本)。
如果可以提交缺少密钥的文件，这是一个更好的解决方案永远不要允许这些自动生成的密钥进入任何文件的Git化副本，这样它们在重基、合并或任何其他Git操作过程中都不会发生冲突。
不过，据推测，这些密钥有一定的用途，当你真正开始构建时，你需要它们。这就是Git的clean和smout过滤器的作用。
这些过滤器是您在工作树和Git之间强加的你必须编写它们，但也许你现有的密钥生成软件已经合适了，因此你的"；"污迹"；滤波器将由"；调用密钥生成软件"；。
清洁过滤器的任务是清除自动生成的垃圾。它只需要将任何自动生成的文本替换为空(如果可能的话)或一个合适但不变的占位符(如果合适的话)。这样Git只看到占位符，甚至什么都看不到。
污迹过滤器的任务是取一个干净的文件——一个没有cruft的文件，可能有占位符——并放入必要的cruft，可能是通过替换占位符。
由于各种文件提取命令——git checkout、git switch、git reset --hard、git restore等——将自动运行污迹过滤器，这将在您处理/使用它们时将cruft放入文件中。由于git add将自动运行clean filter，这将从Git看到的文件中删除cruft。因此，Git永远不会看到任何自动生成的文本，这意味着它永远不会干扰Git的使用。
这并不适用于所有系统，但可能适用于您的系统。要了解如何编写干净和模糊过滤器，请阅读gitattributes文档。