Git pre-merge-commit hook：如何在合并期间忽略文件？

如何解决Git pre-merge-commit hook：如何在合并期间忽略文件？

背景

我在一个复杂的 git 流程中工作，其中一些特定的分支获得特定的子模块和一些需要提交但不能合并的特定配置文件。

这些文件很少，但让任何人合并分支而不小心不要合并这些文件太危险了。

为了使其自动化，我在服务器端和本地端研究了预合并提交钩子。

如果发生冲突，我会使用 .gitattributes 和 git/config 文件来解决与自定义合并驱动程序的冲突。它就像一个魅力。

问题

但是，在没有冲突的情况下，我正在努力使其工作。在这种情况下，合并成功执行并触发了我的预合并挂钩。它发挥它的魔力，然后成功退出。但是，由于某种原因，git 在钩子之后重新做一些合并的东西，这使它变得无用。这是我目睹的行为：

合并前

我有两个分支，比如说 A_current 和 B_incoming。

两者都有一个我不想合并的文件。此文件名为 do_not_merge_me。在某些时候，do_not_merge_me 中的 B_incoming 内容发生了变化。假设它从 contentA 到 contentB

合并期间

当我将 B_incoming 合并到 A_current 时，我看到的是：

• 合并继续进行，并在暂存区添加文件，包括 do_not_merge_me。
• 合并成功，所以触发了我的钩子
• 我的钩子在暂存区找到 do_not_merge_me 并将其从暂存区中删除（最后，它是一个 git reset do_not_merge_me 后跟一个 git checkout do_not_merge_me）
• 我的钩子已正确结束，do_not_merge_me 不再位于暂存区
• Git 做了一些黑魔法：它重做合并并重新上演 do_not_merge_me
• Git 验证提交，我看到在我的控制台中添加了这个：

Merge made by the 'recursive' strategy.
 do_not_merge_me               | 2 +-

• 奇怪的是，合并完成后，我在暂存区得到了正确版本的文件（在此之前，我从未在合并后的暂存区看到任何内容）

问题

此处 https://git-scm.com/docs/githooks#_pre_merge_commit 提供的 git 文档指出，在成功处理合并之后和验证提交之前触发预合并提交。

我的问题是：

1. 为什么我会在暂存区得到正确的版本？
2. 有什么方法可以实现我的目标吗？
3. 为什么 git 在钩子之后做一些合并？这是一个错误吗？

解决方法

简短的回答是你不能。

当 git merge 运行时，它会将三个提交读入 Git 的index。这三个提交是：

• 合并基础（在插槽 1 中）；
• --ours 提交（在插槽 2 中）；和
• --theirs 提交（在插槽 3 中）。

它们以通常的索引格式存储：包含斜杠的路径名、mode（常规文件为 100644 或 100755，符号链接为 120000，gitlink 为 160000）和哈希 ID。

>

合并的第一部分然后比较模式以确保它们是合适的（如果不合适，这就是合并冲突）。假设这里是正常文件和合适的模式，它继续比较哈希 ID：

• 三者相等？文件合并成功，放到slot 0，擦除slot 1-3
• 两个相等？取第三个：下降到插槽 0，擦除插槽 1-3
• 三个不相等？留待稍后，了解真正的合并代码。

我认为还有一些特殊情况（例如，文件存在于合并库和他们/我们的合并库中，但在我们/他们的合并中被删除）也直接在索引中处理，我认为，但您的特殊情况 - 文件在theirs，但在 ours 和 base 中相同 - 遇到中间“两个相等？取第三个”的情况：提交和合并基础中的文件相同，因此 Git 只是 假设 他们更新的文件是正确的结果。

当 Git 在早期阶段执行此操作时，它根本不会运行您的合并驱动程序。文件进入暂存槽零——“准备提交”——而不是冲突，你永远没有机会做任何事情。您的 pre-merge-commit 将被调用，但索引中文件的副本将是 theirs 提交中的副本。

我们现在进入非常黑暗的魔法部分：“索引”假设有一个始终使用的索引 (.git/index)。事实并非如此：大部分是正确的，但是：

• $GIT_INDEX_FILE 覆盖名称；
• 添加的工作树（来自git worktree add）有自己的索引；和
• 各种 Git 命令将索引读入内存，然后进行处理。

在这种情况下，看起来 git merge 具有内存中的索引，并且只是按原样使用它来进行新的提交。您的 git add 替换了 .git/index 文件中的 stage-zero 副本，但 git merge 没有注意到这一点，并继续使用之前存在的传入副本生成新的合并提交甚至运行了你的 pre-merge-commit 钩子。

假设这一切都是真的——它可能会从一个 Git 版本更改为另一个版本，这取决于 Git 何时以及是否重新读取索引——这将回答您的问题 #1，并将答案呈现为 #2 “不”，#3 的答案是“你正在尝试做一些 Git 处理范围之外的事情”。

你想做的并不是天生不合理，只是 Git 不支持。

,

因此，对于需要在合并期间应用更改的任何人，这是我提供的解决方案。

请记住，正如@torek 在 this comment 中指出的那样，此解决方案可能会在某些极端情况下产生一些问题。

大多数时候，您希望避免在合并时进行修改。首选验证。

这些步骤对我的 git (2.31.1) 版本很适用。我不知道这种行为是否跨版本一致。

1. 使用 .gitattributes 为您需要修改的文件实施自定义合并策略。它必须应用这些修改。这与第 3 步执行的操作相同，但以防目标文件发生冲突

2. 实现一个 pre-merge-commit 钩子。这将在冲突解决后触发。这意味着您将可以访问反映合并结果的暂存区域。

3. 修改暂存区：使用 pre-merge-commit 钩子，您可以修改暂存区，这实际上不会修改合并结果（存储在其他地方）。相反，当您的脚本成功退出时，您的修改将进入暂存区。这是我第一次在合并后看到舞台区域留下了一些东西。

注意：这样做的原因是 git 似乎启动了第二次合并

4. 最后，您需要实现一个 post-merge hook，以使用实际暂存区域内容修改合并提交。您需要先删除文件 .git/MERGE_HEAD，然后才能这样做。