随着负责的项目越来越大,出现了专人维护一个模块的可能,业务与模块划分变得清晰可见,但出现了如下几个问题:
以上问题,促使我寻找一种方案解决这个问题。先简单介绍一下我们的项目构成,由 DMP、DCP、DOP 三个主要业务模块构成,DCP 与其他两个模块之间不存在任何直接关系,DOP 依赖了 DMP 提供的相应基础服务包,DMP 也相对独立,三个模块存在各自发版计划,基于现状,会采用统一的版本号进行管理,这显然是不科学的,所以我提出了使用 GIt Submodule
来解决这个问题。
|-docs
|-apps
|--dop
|--ext
|--toolkit
|-sources
|--basics
|--components
|--templates
|--plugins
|--terminals
|-examples
DMP、DCP、DOP 三个业务模块分别创建一个 Git 进行维护。同时,例如:Basic
、Env
、Template
等公共模块都作为子模块进行管理。
DMP
|-docs
|-apps
|--dop(与DOP共用子模块)
|--ext
|--toolkit
|-sources
|--basics(与DOP共用子模块)
|--components
|--templates(与DOP共用子模块)
|--terminals
|-examples(子模块,权限等级可以比较低,以供他人学习查看)
DCP
|-docs
|--toolkit
|-sources
|--components
|--plugins
|--terminals
DOP
|-docs
|-apps(与DOP共用子模块)
|-sources
|--basics(与DMP共用子模块)
|--components
|--templates(与DMP共用子模块)
|--terminals
看似好像模块变多了,但各个业务变得清晰,版本可控,公共部分进行 Git Submodule
,使开发者只要关注需要关注的就行了,模块之间的权限也变的灵活。
Git Submodule
使用基于已有项目进行改造
Git Repository
创建。git push
到相应的远程仓库中,这样子模块的代码已经被管理起来了git submodule add
,需要将相应的子模块目录删除才能执行git clone --recursive [远程仓库地址]
或者
git clone [远程父仓库地址]
git submodule update --init --recursive
git submodule foreach 'git checkout master; git pull'
Update .gitmodules
git mv oldpath newpath
git rm oldpath
git add newpath
git submodule sync