这是一个创建于 1001 天前的主题，其中的信息可能已经有所发展或是发生改变。
原来项目比较小，就 2 个分支再加上打 Tag 就可以应付了。
现在一个新的项目比较庞大，表现在：
- 参与的开发人员多。（ 10 人）
- 项目子模块多。（ 20 多个子模块，大部分可以并行开发）
- 发布的 Target 多（不同的设备不同的 Target 、对应不同的运行参数）
- 每种设备对应一组数据文件。（用来做测试的，数据文件又大又多，不方便进入 Git 仓库）
- 发布版本较频繁。（每 2 周一个版本）
有什么好的作法吗，我感觉单靠 git 流程还搞不定，还得整一套自动化脚本来协助构建。
第 1 条附言 · 2022-03-06 09:22:20 +08:00
这个讲的也不错： https://bbs.huaweicloud.com/blogs/281789
按开发流程拉分支，比如：开发、集成测试、正式发布，各拉一个分支。配合工具对分支增加权限控制，效果应该不错。
楼下有个 v 友说每个 issue 拉一个分支，那如果在上百个 issue 那不是会拉出上百个分支，分支还可以这么玩？
按开发流程拉分支，比如：开发、集成测试、正式发布，各拉一个分支。配合工具对分支增加权限控制，效果应该不错。
楼下有个 v 友说每个 issue 拉一个分支，那如果在上百个 issue 那不是会拉出上百个分支，分支还可以这么玩？
 |
1
wjx0912 2022-03-05 13:21:08 +08:00
|
 |
3
Huelse 2022-03-05 14:04:01 +08:00
如果能分模块的话就简单了，一个模块就一个 submodule
你们是多目标，一个分支就是一个目标，各个分支的.gitmodules 里对应所需 submodule 的分支，只要标注清楚了完全没问题 |
 |
4
jessun1990 2022-03-05 15:02:28 +08:00
我觉得在确定分支之前，首先做好任务切割和分配，将任务切割成类似思维导图中树状结构。然后每个任务打上编号和 deadline ，那么 git 分支的分支名就出来了。
|
 |
5
nathanw 2022-03-05 18:43:52 +08:00 via iPhone
1.10 人开发其实不多，用 git flow 大法，上百人都不是事
2.target 多，就把每个 target 都用一个单独的文件配置，包括运行参数。发布的时候执行对应的文件配置。 3.数据文件用依赖库的形式集成，另外一个独立的 git 维护 4.发布频繁其实挺好的，发布完，代码就 merge 进 dev ，其他人也可以同步下 dev 分支 |
 |
6
likunyan 2022-03-05 18:58:11 +08:00
git flow
|
 |
7
nicevar 2022-03-05 19:35:31 +08:00
开发的时候一个任务对应一个分支，维护的时候一个 issue 一个分支，用一下 jira 就知道了。
|
 |
8
Jaosn 2022-03-05 22:53:26 +08:00
微服务也是一条路
|
 |
9
DinnyXu 2022-03-05 23:08:50 +08:00
目前我们项目跟你描述的差不多，总共有十来个微服务，每个微服务都有 4 个子模块，dev 环境用分支管理的，test 环境用 tag 管理的，线上也是 tag 。部署环境是 Jenkins+Rancher
|
 |
10
initd 2022-03-06 17:24:00 +08:00
|
 |
11
darkengine 2022-03-06 18:34:31 +08:00
构建流程用 jenkins 配合着搞，不同的发布创建不同的 job 就行了
|
Select Language