如何组织项目同步商业源更新？仓库拆分与Git方案选型

一、仓库结构：优先保留单仓库 #

从你的场景出发，建议先保留单仓库结构，原因如下：

• 三个应用（api、admin、frontend）同属一个商业源码AA的基础框架，整体关联性强，单仓库更便于统一管理和同步上游更新；
• 若拆分为主仓库+三个子仓库，后续商业方更新时需分别同步三个子模块的上游代码，会大幅增加同步复杂度和冲突处理成本；
• 若后续各应用发展为完全独立的项目（有独立发布周期、技术栈、团队），再考虑拆分为多仓库也不迟。

二、最优同步方案：分支策略+双仓库隔离 #

结合你的需求，推荐采用「纯上游仓库BB + 开发仓库CC」的双仓库模式，配合Git Flow或GitHub Flow分支策略，具体步骤如下：

1. 初始化上游仓库BB #

BB作为纯商业源码的镜像仓库，仅用于同步商业方的更新，不做任何自定义开发：

# 创建并初始化BB仓库
mkdir AA-BB && cd AA-BB
git init

# 将商业源码AA的归档解压到当前目录
unzip /path/to/AA-v1.0.zip -d .

# 初始提交并推送到远程仓库
git add .
git commit -m "Initial import: AA v1.0"
git remote add origin <你的BB仓库远程地址>
git push -u origin main

# 后续商业方更新时，直接覆盖代码并提交新版本
# 比如拿到AA v1.1归档后：
unzip /path/to/AA-v1.1.zip -d .
git add .
git commit -m "Update to AA v1.1"
git tag -a v1.1 -m "AA official v1.1" # 打标签便于追溯版本
git push origin main --tags

2. 创建开发仓库CC并初始化分支策略 #

CC基于BB克隆而来，用于开发自定义功能，采用你熟悉的Git Flow或GitHub Flow：

# 克隆BB仓库作为CC
git clone <BB仓库远程地址> AA-CC
cd AA-CC

# 添加自己的开发远程仓库（避免直接推送到BB）
git remote add dev-origin <你的CC仓库远程地址>

# 若使用Git Flow，初始化分支规则
git flow init -d # -d 采用默认配置

# 若使用GitHub Flow，直接基于main分支创建feature分支开发
git checkout -b feature/custom-auth

3. 同步BB更新到CC #

当BB有商业方的新版本更新时，在CC中执行以下步骤同步：

# 拉取BB的最新代码
git fetch origin

# 切换到CC的主分支（main），合并BB的更新
git checkout main
git merge origin/main

# 若有冲突，手动解决后提交
# git add <冲突文件>
# git commit -m "Resolve conflicts when syncing AA v1.1"

# 将同步后的主分支推送到CC远程
git push dev-origin main

# 同步到开发分支（以Git Flow的develop为例）
git checkout develop
git merge main
git push dev-origin develop

# 若正在开发feature分支，也可将main的更新合并到当前feature
git checkout feature/custom-auth
git merge main

三、其他方案的优劣对比 #

• Submodules子模块：适合管理独立的第三方依赖，但你的场景是整个商业源码作为基础框架，拆分三个子模块会让同步上游的操作变得繁琐，每次更新都要逐个处理子模块，不推荐；
• git-vendor：主要用于将第三方依赖/vendor目录纳入版本管理，更适合零散的依赖包，而非整个项目源码，不符合你的需求；
• Forking复刻：本质和克隆BB创建CC类似，但如果是私有仓库，fork可能存在权限或协作上的限制，直接克隆并添加双远程的方式更灵活可控。

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