选择工作流程

介绍

Lingo.dev CI/CD 旨在提供灵活性，可以与任何现有的工作流程集成。作为起点，本页面提供了一些推荐的工作流程供参考。

注意： 并没有“最佳”工作流程。每种工作流程都有不同的权衡点，并根据用户的偏好、团队规模和既定的工作方式吸引不同的用户。

推荐的工作流程

选项 1：提交到主分支

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

最适合

希望实现无感知、零摩擦翻译更新，并且开发人员参与最少的团队。

优势

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

权衡点

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

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

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

最适合

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

优势

• 翻译更改在合并前是可见且可审核的
• 清晰的审计记录，显示翻译了哪些内容
• 在接受翻译前可以进行手动调整
• 通过明确的翻译提交保持主分支历史的清晰性

权衡

• 需要手动批准拉取请求（除非配置了自动合并）
• 内容更改与翻译可用之间会有轻微延迟
• 在工作流程中需要管理额外的拉取请求

选项 3：提交到功能分支

当功能分支中进行内容更改时，翻译会自动生成并直接提交到这些分支。

最适合

使用长期存在的功能分支并希望将翻译作为功能开发过程一部分的团队。

优势

• 当功能准备就绪时，翻译也已完成
• 在功能审查期间无需单独的翻译工作
• 完整的功能包括内容和翻译
• 与功能标志部署配合良好

权衡

• 翻译提交会出现在功能分支的历史记录中
• 如果多个开发人员在同一分支上工作，可能会出现合并冲突
• 翻译与功能完成相关联，而不是与内容准备相关联
• 可能会为从未发布的实验性功能生成翻译

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

当功能分支中发生内容更改时，翻译会生成并作为单独的拉取请求从这些分支提交。

最适合

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

优势

• 在功能级别完全可见翻译更改
• 能够在功能完成前审查和调整翻译
• 功能开发与翻译集成之间有清晰的分离
• 接受翻译更新的时间安排灵活

权衡

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