1 简介

本文介绍敏捷开发团队协作、GitHub 权限管理、子模块依赖 以及 最小授权原则。

在一个 GitHub 仓库中，默认的权限控制粒度是基于 整个仓库 的：要么能访问整个代码库，要么完全没有权限。

我们通常的需求是：开发者 A 只能维护订单管理功能的代码，而不能触碰鉴权登录功能的代码。这属于 功能级别的最小授权控制。

GitHub 自身对“代码目录或模块级别”的权限控制有限，所以需要通过 仓库拆分、子模块依赖、开发管理策略 等方式来实现。

2. 使用 Git 子模块/多仓库的方式

方案：服务拆分 + Git 子模块

将不同功能（如订单管理、鉴权登录）拆分为 独立仓库：

  orders-service（订单管理功能）

  auth-service（鉴权登录功能）

主仓库 tests 只做 聚合和依赖管理，通过 Git Submodule 或者 Git Subtree 方式引入子服务：

  tests/
  ├── orders-service/ (submodule)
  └── auth-service/ (submodule)

• 权限控制

给负责订单管理的开发者，只授予 orders-service 仓库的写权限。

他们在主仓库中只能更新自己的子模块引用（例如提交某个版本号）。

对于 auth-service，他们只能看到接口调用，不能直接访问源码（除非开放只读权限）。

✅ 优点：

符合 最小授权 原则。

独立版本管理，每个子服务可以独立 CI/CD。

有利于服务边界清晰（微服务化）。

❌ 缺点：

子模块使用复杂度高，开发体验差（容易忘记更新、版本漂移）。

CI/CD 流水线需要额外处理子模块版本依赖。

如果功能耦合严重，拆分仓库会带来维护成本。

3. 其他可选的软件工程管理方式

• 方式 A：单仓库（Monorepo） + 代码所有权规则（Code Owners）

使用一个大仓库，把所有功能放在一起。

在 GitHub 中配置 CODEOWNERS 文件，规定某个目录/文件只能由特定开发者审核合并：

  /orders/*   @order-dev-team
  /auth/*     @auth-dev-team

开发者即使能看到所有代码，但对不属于自己负责的模块，无法直接合并修改，必须经由指定代码所有者审核。

✅ 优点：

代码集中，依赖管理更方便。

避免子模块带来的复杂性。

代码审查机制天然结合 GitHub PR 流程。

❌ 缺点：

无法从仓库级别真正阻止开发者“访问”非授权代码（只能限制合并权限）。

对敏感代码保护不足（适合信任度较高的团队）。

• 方式 B：微服务架构 + 独立仓库 + API 网关

完全将不同业务功能解耦为独立的服务，开发团队只负责自己服务的仓库。

团队间通过 API（REST/gRPC）交互，而不是直接依赖源码。

可以在 GitHub 组织下建立多个私有仓库，按需分配权限。

✅ 优点：

最严格的隔离，天然满足最小授权原则。

服务独立性强，便于扩展、部署、回滚。

安全性高：敏感功能完全不暴露给无关开发者。

❌ 缺点：

架构成本高，对小团队可能过度设计。

部署、运维复杂，需要成熟的 DevOps 流程。

• 方式 C：基于 Feature Flag 的代码访问控制

在单仓库内，通过 功能开关（Feature Flag） 或配置文件控制某些功能模块的启用/禁用。

虽然无法物理隔离代码访问，但可以通过工具链（IDE 插件、预提交钩子）阻止开发者修改非授权模块。

✅ 优点：

保持单仓库开发便利性。

与敏捷迭代流程结合良好。

❌ 缺点：

权限控制弱，更多依赖流程和规范。

不适合高安全性要求场景。

4 小结

方案					隔离粒度			权限控制强度			复杂度			适用场景
Git 子模块/多仓库	仓库级				强（真正隔离代码访问）	高		多团队、功能独立性强
Monorepo + CODEOWNERS	目录级		中（依赖审查机制）	中	敏捷迭代、小中型团队
微服务架构 + 独立仓库	服务级		最强（API 级别隔离）	高	大规模分布式系统
Feature Flag + 流程规范	功能级		弱（依赖约束与工具）	低	内部信任度高的团队

总的来说，如果团队需要 真正的最小范围授权控制，最佳实践是：

仓库拆分 + 子模块（或 API 接口依赖），从仓库层面隔离。

如果安全性要求没那么高，可以用 Monorepo + CODEOWNERS，开发效率更高。