Git 钩子（如 pre-merge-commit、post-rewrite）在发生合并或变基冲突时不会被触发，因此无法自动解析冲突内容；但可通过 pre-push 钩子在推送前校验并规范化 POM 版本，兼顾自动化与开发者自主权。
git 钩子（如 pre-merge-commit、post-rewrite）在发生合并或变基冲突时不会被触发，因此无法自动解析冲突内容；但可通过 pre-push 钩子在推送前校验并规范化 pom 版本，兼顾自动化与开发者自主权。
在基于 Maven 的多模块 Java 项目中，pom.xml 的版本字段（如 <version>1.2.3.4-DEV-QUALIFIER-SNAPSHOT</version>）常因分支策略与持续集成流程而高频变更。当开发者从 main 分支拉取更新（git merge main 或 git rebase main）时，POM 版本行极易产生文本冲突——尤其当 main 推进构建号（如 1.2.3.5-SNAPSHOT），而本地分支保留开发标识（如 1.2.3.4-DEV-QUALIFIER-SNAPSHOT）。此时，Git 钩子机制存在根本性限制：
✅ 可触发的钩子：pre-commit、pre-push、post-checkout 等在无冲突的常规操作中正常运行；
❌ 不可触发的钩子：pre-merge-commit、post-merge、pre-rebase、post-rewrite 等在冲突发生时完全不执行——Git 会中断流程并等待人工介入，钩子脚本无机会介入冲突文件的读写。
这意味着：
- ❌ 无法用 pre-merge-commit 自动执行 git checkout --theirs pom.xml；
- ❌ 无法用 post-rewrite 在变基中途修改冲突中的版本内容；
- ❌ 无法通过任何内置钩子“自动剥离冲突标记”（<<<<<<<, =======, >>>>>>>）并保留上游版本。
✅ 正确解法：pre-push 钩子 + 智能版本归一化
推荐采用 pre-push 钩子，在代码推送至远程前完成两项关键动作：
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
- 检测当前分支是否为功能分支（非 main）；
- 自动将 POM 中的版本重写为规范格式：<MAJOR>.<MINOR>.<PATCH>.<BUILD>-DEV-QUALIFIER-SNAPSHOT，同时保留所有非版本行的修改（如依赖、插件配置等）。
以下是一个健壮的 pre-push 钩子示例（保存为 .git/hooks/pre-push，需 chmod +x）：
#!/bin/bash
# .git/hooks/pre-push —— 自动规范化功能分支 POM 版本
# 仅对推送至 origin/main 以外的引用生效（避免干扰 release 流程）
while read local_ref local_sha remote_ref remote_sha; do
if [[ "$remote_ref" != "refs/heads/main" && "$remote_ref" != "refs/heads/master" ]]; then
# 获取当前分支名
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
# 跳过 main/master 分支自身
[[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "master" ]] && continue
# 提取 upstream main 的最新版本（假设使用 origin/main）
UPSTREAM_VERSION=$(git show origin/main:pom.xml 2>/dev/null | \
sed -n 's/.*<version>\([^<]*\)<\/version>.*/\1/p' | head -1)
if [[ -n "$UPSTREAM_VERSION" && "$UPSTREAM_VERSION" == *"-SNAPSHOT" ]]; then
# 解析 MAJOR.MINOR.PATCH.BUILD，追加 -DEV-QUALIFIER
if [[ "$UPSTREAM_VERSION" =~ ^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)-SNAPSHOT$ ]]; then
NEW_VERSION="${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.${BASH_REMATCH[3]}.${BASH_REMATCH[4]}-DEV-QUALIFIER-SNAPSHOT"
# 安全替换：仅修改 <version>...</version> 行，保留其余所有内容（含依赖、properties 等）
perl -i.bak -pe "
s/(<version>)[^<]*(<\/version>)/\${1}${NEW_VERSION}\${2}/ if /^[\t ]*<version>/;
" pom.xml
echo "[pre-push] ✅ Auto-updated pom.xml version → $NEW_VERSION"
git add pom.xml
fi
fi
fi
done
# 强制校验：推送前确保 POM 版本符合规范（防绕过）
if git diff --cached --quiet pom.xml; then
echo "[pre-push] ⚠️ pom.xml unchanged — skipping version check"
else
if ! grep -q "<version>[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+-DEV-QUALIFIER-SNAPSHOT</version>" pom.xml; then
echo "[pre-push] ❌ ERROR: pom.xml version does not match DEV-QUALIFIER-SNAPSHOT pattern"
echo " Please run 'mvn versions:set -DnewVersion=...-DEV-QUALIFIER-SNAPSHOT' or fix manually."
exit 1
fi
fi⚠️ 关键注意事项
- 不替代人工冲突解决：该脚本不处理冲突状态本身，而是在冲突已手动解决（git add pom.xml 后）、准备推送时介入。开发者仍需先运行 git mergetool 或手动编辑，清除冲突标记并暂存文件。
- 零侵入依赖变更：正则替换严格限定于 <version> 标签内，新增的 <dependency>、<plugin> 或 <properties> 均不受影响，彻底规避“丢失依赖”的风险。
- 团队协同前提：需统一约定 DEV-QUALIFIER 命名规则（如 alpha、feature-x），并将其纳入 CI 构建参数，确保本地开发与 nightly build 行为一致。
-
钩子分发方案：.git/hooks/ 不随克隆传播。建议将此脚本存为 scripts/git-hooks/pre-push，并通过以下方式启用：
# 项目根目录执行（一次配置，全局生效） git config core.hooksPath scripts/git-hooks
并在 README.md 中声明：“本项目使用 pre-push 钩子自动管理开发分支 POM 版本”。
? 总结
面对 POM 版本频繁冲突的现实，接受 Git 的设计约束是专业实践的第一步：钩子不是万能的“冲突机器人”，而是流程守门员。pre-push 是平衡自动化与可控性的最优选择——它不越界干预 Git 内部状态，却在最关键的交付节点施加轻量、可验证、可审计的约束。最终，清晰的分支语义（main = 发布态，feature/* = 开发态）、标准化的版本策略（Semantic Versioning + 构建号分离）与恰当的钩子定位（推送前校验，而非合并中接管），共同构成可持续的工程效能基石。
