1.1 分支管理
综合评估git flow、github flow、gitlable flow后，结合开发团队的规模、提交频率及所要应对的业务场景，参考git flow简化其内部分支管理，参考gitlab flow强化外部分支管理，如图 1所示。
图 1 git flow分支管理
1.1.1 内部分支管理
(1) 内部开发，主要有两个常驻分支，一个master分支和一个dev分支，master为持续集成的发布分支，dev为开发分支。
(2) 对git flow中的hotfix、feature不做强制创建分支的要求，参考github flow不区分功能分支和补丁分支，统称为内部开发的临时分支，如果不存在多人协同，也可在本地创建分支管理。
(3) 内部开发的临时分支来自dev分支，开发完成合并到dev分支后删除。
(4) 提交到dev分支的代码需要由指定人员进行review，并自测保证系统正常运行才能push到远程仓库。
(5) 发布过程可视情况是否创建release分支，如果近期没有新功能提交且发布过程短，可以使用dev分支替代release分支，在发布过程中禁止dev分支的推送，发布过程中出现的问题直接在dev上修复，然后同步到master。
1.1.2 外部分支管理
(6) 每对外发布一个新版本时，在master分支的最新commit打上tag加上版本说明，并从master创建分支stable-vx.x，此分支只修复本版本中的bug，原则上不再集成新功能。
(7) 已发布稳定版本的问题修复后提交先到stable分支，同时也同步到dev分支，后续内部发布是会更新到master分支。
1.2 子模块管理
参考git submodule管理项目仓库和平台仓库的依赖关系，如图 2所示，这种管理方式具备如下优势：
(8) 对于子工程来说，不需要知道自己的主项目的存在，子模块是一个完整的git仓库，按照正常的git代码管理规范操作即可；
(9) 对于主项目而言，子模块的远程仓库发生更新时，可以在主项目中通过git status查看，并选择是否需要使用git submodule update更新子模块。
(10) 当主项目下子模块文件夹的内容发生未跟踪的修改，且需要同步到子模块远程仓库时，可以进入子模块文件夹，使用git push推送到子模块的远程仓库。
具体操作详见2.4。
图 2 项目仓库和平台仓库管理
2.1 子模块
2.1.1 创建子模块
mkdir -p submodule-dir
cd submodule-dir
git submodule add -b
git status
git add .
git commit -m
git push
2.1.2 拉取仓库代码
拉取主工程仓库同时拉取子模块仓库代码操作如下，如果不想拉取子模块仓库代码，可以只执行第一条命令，主工程可以根据配置文件选择拉取哪些子模块仓库。
git clone URL
git submodule init
git submodule update
或者使用命令
git clone URL
2.1.3 更新子模块
如果子模块远程仓库有更新，主模块通过git status 可以查看，然后执行如下命令可以同步更新：
git submodule update --remote
2.1.4 提交子模块的修改
提交子模块的修改可以在子模块的仓库中修改后提交到远程，然后通过上述2.4.3更新子模块。
但是实际开发过程中，通常会在主模块的开发环境中直接修改子模块，可以在主模块中通过git status 可以查看，但是主模块中是无法提交的，需要切换到子模块的目录，然后按照子模块的提交流程操作如下，其中推送的命令需要注意。
git add
git commit -m
git push origin HEAD:<name-of-remote-branch>
2.1.5 删除子模块
git submodule deinit submodule-dir
git rm submodule-dir
git commit -m ""
git push
