0

我正在使用超越比较来解决合并冲突和 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 中的提交是在相同的文件（达芬奇、C、C#、xml）上开发的。

在 M60 之上重新定位 C 分支时，我相信我正在做这样的事情。

M1 -- ... -- M50 -- ..... M60
                             \
                              \
                               C1 -- C2 -- C3 -- C4 -- C5

我的方案的问题是解决合并冲突。C、xml 和 C# 文件不是问题，但每次我在 DaVinci 中保存工作区时，DaVinci 都会更新许多键（多个位置的一些唯一值），因此此类更改存在于 C 分支的多个提交中。我正在使用超越比较来解决合并冲突，与在 M60 创建一个新分支并在 DaVinci 中重做工作相比，我似乎花费更多时间来解决合并冲突（因为我知道现在需要做什么）。

是否可以仅解决分支中文件的最终版本的合并冲突，而不是通过提交解决冲突提交？（PS 我不需要提交历史）

如果您有更好的想法，请提出建议。

4

2 回答 2

0

看一下git rebase --onto（git help rebase）：

这样的事情可能对你有用：

git rebase --onto M60 P2

假设您当前正在C5提交中。

这实际上将应用当时的提交槽C1，并让您解决沿途的任何冲突。C5M60

完成此操作后，您可以C5通过快进或不快进将新的合并到主控中。

于 2021-11-12T09:45:57.603 回答
0

是否可以仅解决分支中文件的最终版本的合并冲突，而不是通过提交解决冲突提交？

不——但有一条捷径。事实上，有多种可能的捷径；使用哪一个取决于您真正需要什么。

让我复制您的原始图表（稍作改动），并假设您正确地执行了您想要使用的操作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

（这里真正的变化是注意 commitC5还没有合并到mastercommit M60——如果是，我们需要删除commit M60！）。

现在，这幅画中的实际错误是，字面上不能改变C1through 。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 的清洁和涂抹过滤器的用途。

这些过滤器是你在工作树和 Git 之间强加的东西。 您必须编写它们，但也许您现有的密钥生成软件已经合适，因此您的“涂抹”过滤器将包括“调用密钥生成软件”。

clean 过滤器的任务是删除自动生成的 junk。它只需要用任何内容（如果可能）或合适但不变的占位符（如果合适）替换任何自动生成的文本。这样，Git只看到占位符，甚至什么都看不到。

污迹过滤器的任务是取出一个干净的文件——一个碎片，也许有占位符——然后放入必要的碎片，也许通过替换占位符。

由于各种文件提取命令——<code>git checkout、、、、git switch等git reset --hard——会自动git restore运行你的污迹过滤器，这将在你处理/使用文件时将垃圾放入文件中。由于会自动运行 clean filter ，这将删除 Git 看到的文件中的垃圾。因此，Git 永远不会看到任何自动生成的文本，这意味着它永远不会干扰使用 Git。git add

这不适用于每个系统，但可能适用于您的系统。要了解如何编写干净和涂抹过滤器，请阅读gitattributes 文档。

于 2021-11-12T14:07:30.490 回答