Git 钩子（如 pre-merge-commit、post-rewrite）不会在存在冲突时触发，因此无法自动解决 merge/rebase 过程中的 POM 版本冲突；但可通过 pre-push 钩子在推送前校验版本合规性，兼顾自动化与安全性。
git 钩子无法自动处理合并冲突：pom 版本管理的正确实践。git 钩子（如 pre-merge-commit、post-rewrite）不会在存在冲突时触发，因此无法自动解决 merge/rebase 过程中的 pom 版本冲突；但可通过 pre-push 钩子在推送前校验版本合规性，兼顾自动化与安全性。
在多模块 Maven 项目中，采用 SNAPSHOT 流水线式版本管理（如 1.2.3.4-DEV-QUALIFIER-SNAPSHOT → 1.2.3.5-SNAPSHOT）是常见实践，但由此引发的 POM 文件频繁冲突，常被误认为可通过 Git Hook “自动修复”。然而，Git 的设计原则明确禁止在冲突状态下执行钩子——这是关键前提：当 git merge 或 git rebase 检测到未解决的冲突（例如 <version> 标签内容不一致）时，操作会中止并等待人工干预，此时 pre-merge-commit、post-rewrite、pre-rebase 等钩子均不会运行。试图依赖这些钩子“自动 checkout theirs 并重写版本”，不仅不可行，还可能破坏工作区一致性。
✅ 正确的工程化路径是：分离“冲突解决”与“版本治理”两个关注点：
冲突必须由开发者手动解决
当 merge/rebase 出现 POM 冲突时（如含 <<<<<<< HEAD 块），应引导开发者使用 git checkout --ours pom.xml（保留本地开发版）或 git checkout --theirs pom.xml（采纳上游版本），再手动合并变更（如新增 dependency、plugin 配置等），最后运行 git add pom.xml && git commit 完成解决。这是唯一安全、可追溯的方式。-
用 pre-push 钩子强制校验版本合规性
在 .git/hooks/pre-push 中嵌入校验逻辑，确保推送前 POM 版本符合团队策略（如开发分支必须含 -DEV- 修饰符，主干分支必须为 X.Y.Z-SNAPSHOT 或正式版）：#!/bin/sh # .git/hooks/pre-push while read local_ref local_sha remote_ref remote_sha; do if [[ "$local_ref" == "refs/heads/main" || "$local_ref" == "refs/heads/master" ]]; then if ! grep -q '<version>[0-9]\+\.[0-9]\+\.[0-9]\+\(-SNAPSHOT\|\.RELEASE\)</version>' pom.xml; then echo "❌ ERROR: main/master branch requires version like '1.2.3-SNAPSHOT' or '1.2.3.RELEASE'" exit 1 fi elif [[ "$local_ref" =~ refs/heads/feature/.* || "$local_ref" =~ refs/heads/dev/.* ]]; then if ! grep -q '<version>[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+-DEV-.*-SNAPSHOT</version>' pom.xml; then echo "❌ ERROR: Feature branch must use DEV-qualified SNAPSHOT (e.g., 1.2.3.4-DEV-PR123-SNAPSHOT)" exit 1 fi fi done✅ 优势：仅在 git push 时校验，不影响日常 commit/rebase 流程；失败即阻断推送，保障远端仓库质量。
-
增强工具链，降低人工负担
- 使用 versions-maven-plugin 自动化版本更新（如 mvn versions:set -DnewVersion=1.2.3.4-DEV-PR123-SNAPSHOT）；
- 在 CI（如 Azure Pipelines）中配置 Maven@4 任务，结合 pre-build 脚本动态注入构建号，避免 POM 文件硬编码 Build 号；
- 推荐将 POM 中易变字段（如 <buildNumber>）外置为 build.properties 或通过 CI 环境变量注入，从根本上减少冲突源。
⚠️ 注意事项：
- ❌ 避免 pre-commit 校验 POM 版本——它会在每次本地提交时触发，干扰快速迭代；
- ❌ 不要尝试解析冲突标记（<<<<<<<）并“自动清理”——这属于 Git 内部格式，无稳定 API 支持，极易出错；
- ✅ 所有钩子脚本需加入 set -e 和日志输出，便于调试；建议用 git config core.hooksPath .githooks 统一管理并纳入版本控制（需配合 .gitattributes 防止换行符问题）。
综上，Git 的冲突机制是保护数据完整性的基石，不应绕过。真正的自动化在于预防冲突发生（如职责分离、属性外置）和在关键出口拦截问题（pre-push 校验），而非强行介入 Git 的冲突解决流程。
