基于GitLab CI的自动化发布流程：Git提交策略选型咨询

别用git commit --amend改写主分支历史 #

• 主分支的提交历史应该是线性可追溯的，amend会直接覆盖已存在的提交记录，一旦其他开发者已经拉取了旧版本代码，后续推送必然会出现冲突，甚至可能导致代码丢失，这在团队协作里是大忌。
• 后续排查问题、回滚版本时，被改写的历史会让溯源工作变得混乱，不符合Git的协作规范。

链式提交/流水线的优化思路 #

链式流水线确实需要写一堆rules来控制各阶段任务，但可以通过以下方式简化复杂度：

• 用提交信息标记区分阶段：比如生成Changelog的提交加[release-changelog]，哈希提交加[release-hash]，CI配置里用rules:if匹配这些标记，只执行对应阶段的任务，跳过其他无关步骤。
• 改用流水线触发API：第一个阶段完成后，通过API手动触发下一个流水线，同时传递环境变量标记当前阶段，不用依赖提交自动触发流水线，减少规则的复杂度。

更推荐的方案：用临时发布分支做准备 #

这是兼顾历史干净和流程简洁的最优解，步骤如下：

1. 开发者从主分支拉出一个临时分支，比如release-prep/v1.2.3，提交带/release标记的初始化内容
2. 在这个临时分支上跑CI流水线，依次完成：
   • 生成Changelog并提交到该分支
   • 运行ansible-sign生成哈希列表并提交到该分支
   • 自动创建对应版本的标签
3. 所有准备工作完成后，把临时分支合并到主分支：可以用squash合并成单个干净的提交，也可以用--no-ff保留发布准备的完整历史（根据团队规范选）
4. 基于标签创建GitLab发布
5. 删除临时发布分支

这种方式的好处：

• 主分支历史完全不受影响，所有发布相关的临时提交都在单独分支上，既保留了可追溯性，又不会污染主分支
• 整个流程在单个分支的流水线里完成，不用处理多提交触发的多个流水线，CI规则写起来更简单
• 不会给其他开发者带来协作冲突的风险

额外的CI配置小技巧 #

• 把发布流程的任务按阶段分组，比如stage: release-prep、stage: release-tag、stage: release-publish，确保任务按顺序执行
• 用环境变量传递版本号：可以从初始化提交的标记里提取，或者用GitLab CI内置变量自动生成
• 加前置检查：比如验证分支命名是否符合发布分支规范，避免误触发发布流程

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