如何将Git仓库部分变更合并至另一仓库？Azure权限管控方案咨询

核心思路 #

用两个独立的Azure仓库（己方私有仓库、客户协作仓库），靠Azure的分支级权限锁死客户的访问范围，同时用Git分支同步来实现己方变更的选择性推送，既满足客户开发需求，又能完全保护己方核心代码。

具体操作步骤 #

1. 仓库拆分 #

• 己方私有仓库：仅对内部团队开放读写权限，所有核心开发工作都在此完成，完全隔离客户访问。
• 客户协作仓库：由你持有所有权，作为与客户协作的唯一入口。

2. 权限精准控制（Azure Repos端） #

• 给客户团队配置仓库基础权限：允许他们读取仓库内容、创建自己的开发分支（在Azure分支权限设置中，允许基于指定分支创建新分支）。
• 锁死关键分支权限：
  • 对于用来同步己方变更的目标分支（比如client-shared），仅给客户只读权限，禁止他们直接修改，避免打乱推送的变更。
  • 放开客户自分支权限：允许客户创建以customer-开头的分支，给这些分支完全的读写权限，让他们自由提交修改。

3. 己方变更同步流程 #

• 在己方仓库里，把要同步给客户的变更集中到一个专门的分支（比如sync-client）。
• 在客户协作仓库中添加己方仓库为远程源：

  git remote add internal <己方仓库URL>
  

• 拉取己方同步分支的内容，合并到协作仓库的共享分支：

  git fetch internal sync-client
  git checkout client-shared
  git merge internal/sync-client --no-ff
  

• 推送到协作仓库后，客户就能从client-shared拉取更新，再合并到自己的开发分支里。

4. 客户变更处理 #

客户在自己的分支改完代码后，可以发起PR到协作仓库的审核分支（比如customer-review），你审核通过后，要么合并到共享分支，要么按需整合到己方仓库。

为什么不选其他方案？ #

• Git子模块：操作复杂度高，客户容易踩版本同步的坑，而且没法彻底隔离己方仓库的权限，存在泄露风险。
• 单一仓库权限配置：就算能限制分支权限，己方核心代码和客户代码混在一起，容易出现误操作，也不利于后续的代码管理和版本控制。

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