春松客服下一个大版本 v8 分支使用：develop；探讨 monorepo 及 multirepo 话题
hailiang-wang opened this issue · comments
考虑到新版本开发先使用新的分支进行维护：next。
而将来 next 会合并到 develop进行维护，并进入 master作为正式发布，新的分支 next 需要继承历史，并清空，在提交代码。
osc 分支删除，原 osc 分支代码重命名为 develop 分支。
develop 设置为默认分支。
我支持前端和后端在一个 Repo 中，对开发人员友好，降低沟通成本：
- 一次 clone, pull, push 就可以了解项目全貌
- 一次 compare 可以了解全部状态变化，方便代码 Review
因为我长期作为全栈开发，对于一个 Repo 管理全部产品代码比较推崇。在利弊考虑之间，除非有很吸引人的理由，否则还是在一个 Repo 中。
对于独立出去，带来的构建和部署的好处和带来的坏处相比，好处不大。尤其是在一个 repo 中依然可以独立构建和部署。所以，你可以将分离开两个仓库的优缺点做更多介绍吗？
基于这些分析，我们可以在这周在技术委员会+核心开发者群进行投票。
@hailiang-wang
不分开的几个问题
1、commit log 记录存在互相干扰
2、前端工具链是基于node生态的，后端的工具链是基于java生态的，有重合，会带来更多的不一致和分歧点。例如：打包命令封装node基于npm可以写，maven亦或者gradle也可以写。
分开的好处
1、单一仓库的职责更为专注一些
2、前端各个环境的方案更为灵活
可以有一个 统一仓库 通过 git submodule 的形式，做两个项目的一致性融合 以及 版本对应关系以及统一的 release 发布
@hailiang-wang 不分开的几个问题 1、commit log 记录存在互相干扰 2、前端工具链是基于node生态的，后端的工具链是基于java生态的，有重合，会带来更多的不一致和分歧点。例如：打包命令封装node基于npm可以写，maven亦或者gradle也可以写。
分开的好处 1、单一仓库的职责更为专注一些 2、前端各个环境的方案更为灵活
可以有一个 统一仓库 通过 git submodule 的形式，做两个项目的一致性融合 以及 版本对应关系以及统一的 release 发布
前几次交流中，你说明我们要用 monorepo，就是不分开。我认为这个文章里分析的较为全面：
5 分钟搞懂 Monorepo，因此我支持在一个库。
1、commit log 记录相互干扰：commit log 的 message 遵循 #ISSUE 描述 原则进行提交可以解决；git 对于 commit log 有很多好的工具
2、打包工具和 monorepo 和 multirepo 没有关系，因为构建还是在 CI 工具上，我们使用 Jenkins，前后端代码在 repo 的不同目录下。
3、分开的好处在 monorepo 中由目录约定，可以实现：专注，灵活。
4、git submodule 增加了人工的操作。
可以使用一个仓库，前后端使用两个不合并的分支
昨天和 @Kaifuny 做了探讨，我们有如下共识：
1、基于产品、开发、构建、发布的综合考虑，使用 mono repo 管理产品相关代码，即至少前端和后端在一个 repo 中。通过目录规范不同工作；
2、对于 产品 SDK 可以单独发布 repo：原因是 SDK 涉及多语言，并且根据包管理工作分发，管理版本，SDK 应尽量兼容不同的产品版本；
3、其他情况，比如自动化测试待确认：总的原则是简单，尽量在一个 repo 中。
重新优化 branch 管理：
- 新版本春松客服 v8 开发过程直接使用 develop 管理，稳定版本发布到 master，使用 tag 标签。
- next 分支删除
- 原 master 分支 checkout 为 v3，该代码目前是春松客服 v3.9.0
- 原 develop 分支代码重命名为 master 分支
春松客服 v5，v7 的版本使用了 tag 管理
