在 git "update" 钩子中获取每个分支的提交

Question

考虑下一个创建所需 git 日志的伪代码：

git checkout master
git checkout -b 123-test-branch-1
git commit -m "#123 b1 c1"
git commit -m "#123 b1 c2"
git push
git checkout master
git checkout -b 456-test-branch-2
git commit -m "#456 b2 c1"
git commit -m "#456 b2 c2"
git push
git checkout 123-test-branch-1
git merge 456-test-branch-2
git commit -m "#123 b1 c3"
git push

在现实世界中，我在远程 git 存储库中的 update 挂钩验证分支名称和提交消息格式。分支名称和提交消息必须包含问题编号，例如123-test-branch-1 和#123 b1 c1 中的问题编号为123。推送分支时，挂钩从分支中提取问题编号并提交消息并进行比较。如果它们不相等，则钩子退出并出错。

当我推送只有“自己的”提交的分支时，这很好用。但是，上面的 git log 示例，推送分支 123-test-branch-1 具有来自合并分支 456-test-branch-2 的提交，因此钩子尝试仅将来自两个分支的所有提交与推送分支 123-test-branch-1 进行比较，并以错误退出，因为来自 456-test-branch-2 的提交具有问题编号456，当需要 123 时。

为了接收提交，我使用git log --pretty=%s ${oldRef}..${newRef}，其中oldRef 和newRef 是“更新”挂钩参数。

所以，我的问题是如何解决这个问题。以某种方式对每个分支进行分组提交，或过滤来自现在推送的分支的提交（但如果 456-test-branch-2 是本地分支并且从未推送且从未验证，则挂钩可能会跳过无效提交）或其他内容。

Answer 1

更新挂钩没有获得足够的信息：它无法获得传入哈希 ID 的“全局视图”。接收前或接收后挂钩确实，¹，因此确实获得了足够的信息——至少对于某些目的而言。

最大的问题在于新分支的创建。例如，假设一个更新正在传递名称refs/heads/a 和refs/heads/b，其中两个名称都是新名称（它们的旧哈希是空哈希），并且refs/heads/a 指向提交N2 和refs/heads/b 指向在此图形片段中提交N3：

                 N2   <-- A
                /
...--O--O--O--N1
                \
                 N3   <-- B

其中所有O 提交都是“旧的”（例如，之前可以从现有的分支或标签名称访问），而N 提交是“新的”，因为以前永远无法访问，因此被列出作者：

git rev-list refs/heads/a refs/heads/b --not \
    $(git for-each-ref --format '%(refname) |
        egrep -v '^(refs/heads/a|refs/heads/b)$')

很明显，这三个N 提交是“新的”，但是您应该将N1 分配到哪个分支？

对此没有唯一的正确答案。毕竟，提交N1 在两个分支上。

无论如何，如果您更关心合并提交，例如：

...O1--O2--N1--N2   <-- A
              /
...-O3--O4--N3    <-- B

——你可能想使用--first-parent 遍历。在这里，我们可以相信，基于这两个分支名称更新（A 从 O2 移动到 N2，B 从 O4 移动到 N3）—N2 的第一个父级是N1（有可能，但很难，以相反的方式实现），所以跟随--first-parents 将“分配”提交N1 到A 而不是B。同样，如果您是从更新挂钩而不是接收前或接收后挂钩执行此操作，那可能是您能做的最好的事情，因为您没有得到 both @987654349 的信息@和 B 建议更新。

---

¹一个 post-receive 挂钩在删除所有锁后运行，因此它与可能更新引用名称的其他操作竞争。 pre-receive 钩子获取所有建议的更新，因此在引用名称更新周围有一个很大的锁定，所以从某种意义上说，在那里进行这项工作显然更安全。

缺点是 pre-receive 钩子在持有大锁的同时运行，所以它所做的任何“慢”操作都会禁止并行性。