我正在编写一个prepare-commit-msg（作为预合并）钩子，需要获取合并的源分支名称以传递给REST API。换句话说，我需要从git merge <branchname>.
到目前为止，我已经尝试重新解析MERGE_HEAD，但是当钩子触发时它似乎尚未设置。目前，我只是使用git revparse --abbrev-ref @ { - 1}来获取我所在的最后一个分支，但这不一定总是我要合并的分支
我试图强制执行的规则是，除非满足某些条件，否则用户不应将其功能分支与master合并。如果有一个更好的钩子来做到这一点，这也将有所帮助。 Prepare-commit-msg是唯一一个似乎将提交类型作为参数的人。
答案 0 :(得分：2)
到目前为止，我已经尝试重新解析MERGE_HEAD，但是当钩子触发时它似乎尚未设置。
这是正确的;但问题比那更重要。 （和/或更小，也许！:-)）（我在这里也注意到Arkadiusz Drabczyk's comment：git merge没有合并 - 即，快速前进 - 跳过一切< / em>的。）
首先，考虑一下如果用户运行会发生什么：
git merge a97131c
分支是什么？好吧，让我们画一点图：
...--*--o--o--@ <-- blarg (HEAD), xtest
\
o--A--B <-- br1
\
C <-- br2, br3
HEAD告诉我们当前分支的名称是blarg，所以尽管当前提交是提交@（例如，其散列可能是9fd178a），实际上进行了合并提交，它将指向新的合并提交名称blarg。
接下来，哪个提交是a97131c？它可能是提交A，B和C中的任何一个。如果它是提交A，则这本身不是任何分支提示，因此正在合并的分支有 no 适当的名称。我们只是合并提交A，结果将是：
...--*--o--o--o <-- xtest
\ \
o-----A--@ <-- blarg (HEAD)
|\
| B <-- br1
\
C <-- br2, br3
如果a97131c是提交B的ID，我们可能正在执行git merge br1，结果将是：
...--*--o--o--o <-- xtest
\ \
o @ <-- blarg (HEAD)
\ /
A----B <-- br1
\
C <-- br2, br3
如果a97131c是提交C的ID，我们可能会执行git merge br2或git merge br3。 （我将绘制结果图作为练习，但请注意，与之前一样，移动的唯一名称是blarg。）
无论如何，这是一种啰嗦的方式，即使你可以获得某人作为论据发布的分支的名称 - 通常，你可以：它在{{分泌出来“ 1}} - 它实际上并不重要。 在Git中，分支名称几乎无关紧要。重要的是提交。
我试图强制执行的规则是，除非满足某些条件，否则用户不应将其功能分支与master合并。如果有一个更好的钩子来做到这一点，这也将有所帮助。 Prepare-commit-msg是唯一一个似乎将提交类型作为参数的人。
听起来好像真正的目标是禁止导致任何任何新提交或提交出现在.git/MERGE_MSG上的提交，除非这些新提交遇到某些约束。当然，我不知道你的约束是什么，我只能注意到几个项目：
master就会完全跳过常规git merge和pre-commit挂钩。所以你必须尽早使用commit-msg钩子来抓住它。
但是，如果在prepare-commit-msg期间prepare-commit-msg挂钩退出非零，则合并仍在进行中。随后的git merge将提交合并。此操作 运行git commit和pre-commit挂钩（与成功的自动合并不同）。但是，再次，当退出非零会阻止提交时，合并仍在进行中，准备提交。
用户始终可以跳过这些挂钩（或不设置它们）。要真正执行某些操作，您需要在提交进入某个存储库您控制时执行此操作。在许多典型的设置中，这意味着在一个集中的存储库中，各个开发人员commit-msg的工作。您可以在git push或pre-receive挂钩（和/或通过Gitolite及其发烧友系统）执行此操作。
所有这一切，在单个开发人员端强制执行某些规则可能仍然很好，这样他们就不会做很多工作并且认为一切都很好然后继续推送并使推送失败。处理 this 的最简单方法是编写一个有人要使用的包装器：而不是直接运行update，它们运行你的包装器，它进行预检查，然后只是困扰如果事情看起来不错，调用 git checkout master; git merge featureX。
您仍然可以在集中式服务器上实施严格的强制执行，以确保开发人员没有绕过规则。但是你给他们一个工具来帮助他们，然后说：“如果你想避免在很晚的时候绊倒规则，请使用这个工具。”