Git分支管理是CI/CD稳定运行的底层前提，需严格对齐分支策略与CI触发规则、Docker构建上下文、分支保护、Tag发布及文档化。
Git 分支管理不是流程装饰，而是 CI/CD 流水线能否稳定触发、精准构建、安全回滚的底层前提。没对齐分支策略的 CI 配置，迟早会因 merge 冲突、环境误用或 tag 漏发导致部署失败。
CI 触发条件必须绑定明确的分支规则
很多团队把 main 和 develop 都设为“推送即构建”，结果测试镜像污染生产流水线，或开发提交反复触发全量测试拖慢反馈。CI 系统（如 GitHub Actions、Gitee Pipelines）的触发配置必须按角色区分：
-
main分支只响应push和pull_request的closed事件（即合并完成），用于触发生产镜像构建与发布 -
develop分支响应push，但跳过部署步骤，仅运行单元测试 + 静态检查 -
feature/*分支不直接触发 CI，只在 PR 提交时启动预检（lint + build + 单测），避免无效构建 - 所有触发逻辑需在
.github/workflows/ci.yml或.gitee/pipelines.yml中显式声明分支白名单，禁用通配符模糊匹配
Docker 构建上下文必须与 Git 分支严格对应
常见错误是 Dockerfile 固定从 . 复制文件，却在 CI 中 checkout 错误分支——比如本该构建 release/v2.1，却用了 develop 的工作树。正确做法是让构建过程显式控制代码来源：
- 使用
--build-arg GIT_BRANCH=${{ github.head_ref }}（GitHub）或${GITEE_BRANCH}（Gitee）传入当前分支名 - Dockerfile 中用
RUN git clone -b ${GIT_BRANCH} --depth 1 https://xxx.git /app替代COPY . /app，避免本地未提交文件干扰 - 若必须用
COPY，则 CI 脚本中先执行git checkout ${GIT_BRANCH} && git clean -fdx，确保工作树干净 - 多阶段构建时，不同阶段可指定不同分支：编译阶段用
develop，打包阶段用main对应的 commit hash
分支保护与自动合并需协同设计
光设分支保护（如 require status checks）不够，还得让自动化真正接管关键路径。否则 PR 合并仍依赖人工点按钮，破坏流水线闭环：
- 在
main和develop上启用强制require pull request reviews和require status checks，但 review 通过后立即启用auto-merge - CI 流水线末尾添加一步：当所有检查通过且目标分支为
main时，调用 GitHub API 自动合并 PR（POST /repos/{owner}/{repo}/pulls/{pull_number}/merge） - 禁止任何人向
main强制推送（force push），Gitee/GitHub 均支持在分支保护中勾选此项 - hotfix 分支合并到
main后，必须自动 cherry-pick 到develop，可用脚本配合git cherry-pick -x实现，避免修复遗漏
Tag 发布必须与分支状态解耦
用 git tag v1.2.0 打标签本身不危险，危险的是 CI 把 tag 当作“任意提交”的信号——比如误将 feature/login 分支上的临时 tag 当成正式发布。关键约束有：
- CI 只响应带前缀的 tag，例如
^v[0-9]+\.[0-9]+\.[0-9]+$，排除dev-xxx或test-xxx - tag 必须打在
main分支的 HEAD 提交上，CI 脚本中增加校验：git describe --tags --exact-match HEAD 2>/dev/null || exit 1 - 发布镜像的 tag 名必须与 Git tag 一致（如
v1.2.0），且同时打一个latest（仅限非生产环境）或stable（生产环境）别名 - 每次 tag 构建完成后，自动更新
VERSION文件并提交回main，避免手动维护版本号出错
最易被忽略的一点：分支策略和 CI 配置必须写进 CONTRIBUTING.md 并随代码一起版本化。很多人把 CI YAML 当作运维配置单独管理，结果分支规则改了，CI 却没同步更新，问题要等第一次发布失败才暴露。
