不能直接用 Git Flow 管理 Revel 项目，因其环境分层、构建机制和 app.conf 驱动行为与 Git Flow 的分支模型不兼容，易导致配置错乱、缓存失效及控制器行为异常。
Revel 项目用 Git 做团队协作时，不能照搬通用 Git 分支模型——它自带明确的环境分层（dev / test / prod）、构建产物生成机制（revel build）、以及依赖 app.conf 配置驱动的行为（比如 resourceVersion、revel.controller.reuse）。直接套用 Git Flow 或 GitHub Flow 容易在配置同步、静态资源缓存失效、控制器对象池行为验证等环节出问题。
为什么不能直接用 Git Flow 管理 Revel 项目
Git Flow 要求长期维护 develop 和 master 分支，并通过 release/* 分支做预发布。但 Revel 的部署强依赖 app.conf 中的环境变量（如 mode=PROD、run.mode=prod）和构建时注入的版本标识（如 resourceVersion）。若这些配置分散在不同分支、未随代码一起合入，会导致：
-
develop分支跑起来是 dev 模式，但构建出的二进制却误用了 prod 配置，引发 session 加密密钥不匹配或日志级别异常 -
release/v1.2分支里没更新resourceVersion，上线后用户仍加载旧版 CSS/JS - CI 流水线基于分支名自动设置
run.mode，但分支命名规则和 Revel 的conf/app.conf段落不对应，导致测试环境实际运行在 dev 模式
推荐的 Revel 分支策略：Env-Driven Single Mainline
以 main 为唯一长期存活主干分支，所有环境部署都从 main 的特定 commit 构建，靠配置文件段落 + 构建参数区分行为。这是 Revel “约定优于配置”理念在 Git 层的延伸。
关键实践：
- 所有功能开发基于
main新开短期 feature 分支（如feat/user-auth），完成后必须通过 CI 验证revel run -a myapp -c conf/dev.conf和revel build -a myapp -c conf/prod.conf均能成功启动 -
conf/app.conf必须包含完整环境段落：[dev]、[test]、[prod]，且每个段落显式声明run.mode、session.cookie.secure、resourceVersion等关键项；禁止用 fallback 默认值 - CI 构建脚本中，用
--config显式指定配置文件路径，例如：revel build -a myapp -c conf/prod.conf -o myapp-prod；不依赖分支名自动映射 - 生产发布不 merge，而是打带语义化标签的 release commit：
git tag -a v1.2.0 -m "deploy to prod: resourceVersion=abc1234"，该 commit 必须已通过 prod 配置的完整构建+冒烟测试
如何让 resourceVersion 在分支间保持一致且可追溯
Revel 的静态资源缓存失效机制依赖 resourceVersion 注入模板，而这个值如果硬编码在 conf/app.conf 里，不同分支容易不一致；如果用构建时动态生成，又难追溯具体版本对应哪次提交。
安全做法是把它绑定到 Git 提交本身：
- 在
conf/app.conf的[dev]和[test]段落中，设resourceVersion = "dev"或"test"，仅用于本地调试 - 在
[prod]段落中，**不写死值**，改为：resourceVersion = ${GIT_COMMIT}（需 CI 支持变量替换）或更稳妥地，在构建前用 sed 替换：sed -i 's/resourceVersion = .*/resourceVersion = '"$(git rev-parse --short HEAD)"'/' conf/app.conf - 确保
conf/app.conf不被.gitignore忽略，且所有环境段落保留在同一文件中——避免拆成多个配置文件导致 diff 时漏掉关键变更
CI/CD 流水线必须校验的三个 Revel 特定检查点
普通 Go 项目 CI 只跑 go test 和 go build，但 Revel 项目还需确认框架层行为是否按预期生效：
- 检查
revel build输出的二进制能否被revel run正确加载：执行./myapp -c conf/test.conf -port 9999 && sleep 2 && curl -sf http://localhost:9999/health | grep ok - 验证
resourceVersion是否真实注入到 HTML：构建后提取views/index.html中的 script 标签，检查src="/public/js/app.js?v=...后缀是否匹配当前 commit short SHA - 确认控制器对象池启用：在
conf/prod.conf中检查是否存在revel.controller.reuse = true，且revel.controller.stack值 ≥ 10；缺失则阻断发布
最常被忽略的一点：Revel 的 conf/app.conf 是运行时读取的，不是编译期嵌入的。这意味着即使你改了代码、打了 tag、跑了 CI，只要没把新配置推送到部署目标机器的 conf/ 目录下，resourceVersion 和 revel.controller.reuse 就不会生效——配置和二进制必须原子性同步。
