关于基于GitLab特性分支与标签搭建作业管控策略的疑问

你提到的only: [master]配置只是这套管控策略里的一小部分，要完整落地基于特性分支与标签的作业管控模式，需要结合特性分支工作流规范、标签标记规则以及更细致的CI/CD作业触发逻辑，以下是具体的落地说明：

一、核心工作流规范 #

• 特性分支开发：开发新功能时，从主分支（如main/master）拉出独立的特性分支，命名统一用feature/功能名称格式（比如feature/user-payment），所有新代码提交都在特性分支上进行。
• 评审与预发布标记：特性开发完成后，先发起Merge Request（MR）做代码评审，评审通过后，给当前特性分支的代码打一个预发布标签（比如pre-release/v1.2.0-payment），标记这个待合并的代码节点。
• 主分支合并与正式标签：把特性分支合并到主分支后，给主分支的对应提交打正式发布标签（比如release/v1.2.0），用于触发生产环境的发布作业。

二、CI/CD作业的规则配置（.gitlab-ci.yml） #

你用到的only指令是基础，但要覆盖评审、预发布、生产全流程，需要针对不同场景配置不同的触发规则：

1. 评审阶段作业（代码检查、单元测试） #

这类作业要在特性分支推送代码时自动触发，确保每次提交都符合质量要求：

lint_and_unit_test:
  stage: test
  script:
    - npm run lint
    - npm run test
  only:
    - /^feature\/.*$/  # 匹配所有以feature/开头的特性分支

2. 预发布环境部署作业 #

这类作业在创建预发布标签时触发，用于验证特性功能：

deploy_staging:
  stage: deploy
  script:
    - ./deploy-staging.sh
  only:
    - /^pre-release\/.*$/  # 匹配所有预发布标签

3. 生产环境发布作业 #

这类作业仅在创建正式发布标签时触发，确保只有经过验证的代码才会部署到生产：

deploy_production:
  stage: deploy
  script:
    - ./deploy-production.sh
  only:
    - /^release\/.*$/  # 匹配所有正式发布标签

4. 主分支验证作业（可选） #

如果需要在合并到主分支后做最后一轮验证，可配置主分支触发的作业：

main_branch_verify:
  stage: verify
  script:
    - npm run build
    - npm run e2e-test
  only:
    - master  # 替换成你的主分支名称

三、额外管控要点 #

• 标签命名强制规范：必须统一标签的命名格式，这样CI才能精准匹配触发条件，避免误操作。
• MR合并权限控制：在GitLab设置分支保护，要求特性分支必须通过MR评审、且预发布环境验证通过后，才能合并到主分支。
• 标签创建权限限制：仅允许特定角色（如运维、项目负责人）创建正式发布标签，防止随意发布。

内容的提问来源于stack exchange，提问作者Michu93