50人+Looker团队Git分支困境：feature分支应从何创建？

核心解决思路 #

直接统一从prod创建干净的feature分支，通过自动化同步机制解决Looker UI的同步报错问题，同时适配开发者仅用Looker UI操作的限制，兼顾CI/CD的高效性。

调整后的完整工作流 #

分支映射规则（保留原架构） #

• prod：绑定Looker生产实例，仅接受人工审核后的合并，为绝对稳定的基准分支
• stg：绑定Looker预发布实例，仅通过自动化测试守卫的合并，作为稳定验证环境
• dev：绑定Looker开发沙箱，作为开发者临时提交变更的集成环境，允许混乱但可随时从prod重建

开发与上线全步骤 #

1. 自动化基础同步：消除dev与prod的核心差异

   • 每次prod有合并操作后，立即触发GitHub Action，将prod的核心配置（模型结构、核心视图、权限模板等无冲突内容）增量同步到dev分支
   • 同步逻辑跳过dev中已存在的feature类变更，避免覆盖开发者的工作内容

2. 开发者创建feature分支（适配Looker UI限制）

   • 开发者直接在Looker-dev UI中完成开发，提交变更到dev分支
   • 运维侧通过GitHub Action自动完成以下操作：
     • 从prod拉取干净的代码，创建对应名称的feature分支（如A_feature_A1）
     • 将该开发者提交到dev的变更cherry-pick到这个干净的feature分支
     • 自动推送这个干净的feature分支到远程仓库
   • 全程无需开发者手动操作Git，完全适配他们的使用习惯

3. 合并到stg环境

   • 针对干净的feature分支创建PR到stg，触发GitHub Action执行自动化验证：
     • Looker模型语法校验
     • 数据一致性对比（与prod数据源）
     • 仪表盘性能测试
   • 所有测试通过后自动合并到stg，同步到Looker-stg实例进行业务验证

4. 合并到prod环境

   • 从stg创建PR到prod（或直接使用已验证的feature分支）
   • 触发人工审核流程（由架构师或运维团队确认变更的业务影响、兼容性）
   • 审核通过后合并到prod，同步到Looker生产实例

关键问题的具体解决 #

解决Looker UI同步报错 #

因为feature分支的基础代码来自prod，加上我们通过自动化同步保持dev与prod的核心配置一致，开发者在Looker-dev中开发时，本地与远程dev的差异仅为自身的feature变更，不会出现大规模同步冲突。若出现局部冲突，GitHub Action会自动触发通知，开发者只需在UI中调整后重新提交即可。

适配50人团队的高效CI/CD #

• 每个开发者的变更都被隔离在独立的干净feature分支中，彻底避免dev环境混乱导致的合并冲突
• 自动化分支创建和cherry-pick流程完全无需开发者介入Git操作，符合他们的使用偏好
• stg的自动测试和prod的人工审核分离，既保障了每日大量提交的快速上线，又严格控制了生产环境的变更风险

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