选择工作流

简介

Lingo.dev CI/CD 设计灵活，可集成到任何现有工作流中。作为起点，本页提供了一些推荐的工作流供参考。

注意： 没有“最佳”工作流。每种工作流都有不同的权衡，适用于不同用户，具体取决于他们的偏好、团队规模和既有的工作方式。

推荐工作流

选项 1：提交到主分支

当内容更改合并到主分支时，翻译会自动生成并直接提交回主分支。

最适合

希望实现无感、零阻力翻译更新，且开发者参与最少的团队。

优势

• 全自动化，无需人工干预
• 翻译会立即在主分支中可用
• 设置和维护最简单
• 无需额外管理分支或拉取请求

权衡

• 没有翻译审核流程
• 翻译提交可能会触发额外的 CI 运行
• 变更会直接出现在主分支，无法直观看到翻译内容
• 对翻译部署时机的控制较少

选项 2：从主分支拉取请求

内容合并到主分支后，翻译会生成并作为新的拉取请求从主分支提交。

最适合

希望在主分支集中管理流程的同时，具备翻译可见性和审核能力的团队。

优势

• 翻译变更在合并前可见且可审核
• 明确记录了哪些内容被翻译
• 可在接受翻译前手动调整
• 保持主分支历史清晰，翻译提交明确

权衡点

• 需要手动批准拉取请求（除非已配置 auto-merge）
• 内容变更与翻译可用之间有轻微延迟
• 工作流中需管理额外的拉取请求

选项 3：提交到功能分支

当功能分支中有内容变更时，翻译会自动生成并直接提交到同一分支。

最适合

适合使用长期存在的功能分支，并希望将翻译纳入功能开发流程的团队。

优势

• 功能准备就绪时，翻译也已就绪
• 功能评审期间无需单独处理翻译工作
• 完整的功能包含内容和翻译
• 与 feature flag 部署配合良好

权衡点

• 翻译提交会出现在功能分支历史中
• 多名开发者在同一分支工作时可能产生合并冲突
• 翻译与功能完成度相关，而非内容准备度
• 可能为从未上线的实验性功能生成翻译

选项 4：从功能分支创建拉取请求

当功能分支中有内容变更时，翻译会生成并作为该分支的单独拉取请求提交。

最适合

希望在保持功能分支工作流的同时，对翻译拥有最大控制权和可见性的团队。

优势

• 在功能层面完全可见翻译变更
• 可在功能完成前审查和调整翻译
• 功能开发与翻译集成清晰分离
• 可灵活选择何时接受翻译更新

权衡点

• 管理流程最为复杂
• 每个功能需多个拉取请求（功能 + 翻译）
• 如果功能变更，翻译拉取请求可能变得过时
• 需要在功能和翻译拉取请求之间进行协调