@marczhao 我的理解是 DNS 协议理论上是要求 UDP 53 和 TCP 53 都开放的，在 UDP 53 出现数据过多截断的情况下换 TCP 53 （虽然情况不常见）。

https://thomasvilhena.com/2021/11/prevent-merge-from-specific-branch-git-hook
这里提供了一个根据 GIT_REFLOG_ACTION 来判断行为的拦截思路

https://stackoverflow.com/a/74816940
这里提供了另一个在 prepare-commit-msg 中进行拦截的思路

@Albertcord 最好的避免 merge 地狱的方式就是不 merge 。在 trunk - release branch 的模式里，所有的 cherry-pick 都是从 trunk -> release branch ，纯单向，不会搞错。

还是以你的项目为例，在 trunk （ develop ，其实应该用 master 更合适）上开发，当需要交付版本的时候，拉出一个 release branch （ master ，其实应该用 release-v1.0 类似的更合适），开始在这个分支上进行针对交付的修改（关闭某些未完成的功能，调整某些版本号标识，比如 VERSION="dev" -> VERSION="v1.0"，etc ）。这个分支就是「专属于该发布使用的」。

接下来看一些具体情况：

Q：发现 v1.0 有 bug 需要修复怎么办？（ hotfix 场景）
A：如果是 release-branch 独有的问题，在 release-branch 上修复即可；如果是 master 上也存在的问题，先在 master 上修复，然后 cherry-pick 到 release-branch 上。

Q：需要在 v1.0 上发布新的功能怎么办？（ release 场景）
A：首先已知所有新功能都应该在 master 上开发，而不是在 release-branch 上。接着需要根据增加新的功能涉及的 commit 范围做出选择，1. 从 trunk 上重新开一个 release branch 分支走完整的发布流程，或者 2. 从 trunk 上 cherry-pick 修改到 release branch 上。

可以看到不管什么场景下，都是 trunk -> release branch 单向的。

对于 git flow ，我其实是不太能理解为什么它是 work 的…… 比如当你需要同时维护多个版本线 (v1.x ，v2.x ）时，git flow 的 main 分支是单线的，怎么办；比如当你在 main 上需要标记 VERSION="v1.0"，从 main 派生出的 develop 分支上需要标记 VERSION="dev"，然后 develop 分支又会在 release 时合入 main 分支（ VERSION 打架），hotfix 分支又会从 main 分支派生出来同时合入 main 分支和 develop 分支（ VERSION 又打架）……

你现在这个模式大致上就是 trunk 开发 release 分支发布的模式，trunk = develop ，release 分支 = master ，在这个模式下，release 分支是不应该 merge 回 trunk 的。所以应该选择 「 diff 出 master 比 develop 多的 commit ，逐个 cherry-pick 到 develop 」这条路，再精确点说，应该是「逐一检查 master 上的提交，判断是否需要 cherry-pick 到 develop 」。