存储库的数量
为了找到合适的用量，建议遵循以下原则： 根据需要保持一致性 尽可能多的自主权 最低限度的指导方针 可以使用尽可能少的指南来实现一致性。以下是本政策中可能包含的内容的一些示例： Git系统的选择（GitHub、Azure Repos、Git Bucket等）。这里建议选择统一的平台。但它也可以由两个系统组成 - 例如用于开源的 GitHub 和用于内部项目的 Azure Repos。 最小分支工作流程。 GitFlow 是最著名的工作流程。然而，作为最低限度的基础，它太复杂了！这里一个不错的选择是基于主干的开发（TBD）：主分支受策略保护，并且只能通过拉取请求从所谓的主题分支（例如功能或错误修复）“合并”到主分支中（请参阅图 1：基于主干的开发）。注意：分支=分支/合并=合并。我在这里使用英文术语，因为在我看来，它们是国际技术术语。试图翻译所有这些术语的文本非常难以阅读和理解。 命名约定：命名分支应采用 瑞士 电话号码 的命名约定。开发人员之间永恒的哲学争论是主题分支的文件夹是否应该以复数形式（例如 features/*）或单数（例如 feature/*）命名。您选择哪种变体并不重要 - 您应该在所有项目中一致地命名它。 提示：在大多数 Git 系统中，可以调整权限，以便必须自动遵循约定。 对拉取请求的进一步补充：拉取请求可以通过多种方式扩展：CI 构建、代码分析、测试和代码覆盖率、链接的工作项等。这里重要的是仅将最低公分母设置为强制性的。这里的技术进步很快，您不希望不断地调整指南。少即是多——许多内容都更好地包含在团队指南中。 图1：主干开发 基于主干的开发 团队说明（指导） 对于指南中未列出的所有内容，建议编写指南。
https://zh-cn.frnumbers.com/wp-content/uploads/2024/04/ss.png
它可以帮助团队针对日常生活中面临的问题做出正确的决定。 该指南详细阐述了以下几点： 存储库的数量、结构和命名约定 审查指南（审查或代码审查——源代码的相互审查和检查） 手动测试阶段的版本分支/稳定化 处理长期存在的特征 提交消息和拉取请求 存储库的数量、结构和命名约定： 使用 Git 的团队必须做出的第一个决定是存储库的大小和数量。 “整体”存储库（mono-repo）（整个应用程序的存储库）和“多存储库”（许多单独的存储库共同构成应用程序）之间存在区别。两种方法都有优点和缺点。虽然多存储库方法在基于微服务的架构中具有优势，但它也带来了通常无法提前看到的巨大复杂性。多存储库小而薄，可以单独部署。不幸的是，处理依赖关系和故障排除是一个巨大的挑战。 Mono 仓库的情况并非如此。
頁:
[1]