这是一个创建于 1846 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前遇到的问题有 6 个 branch 很久之前从 master 分出，其中每个 branch 共通的代码有 60%.其余的都是定制化的一些内容，现在想把这些 branch 收回做一个管理，切换分之 fix，代价太大， 有同学可以提点下思路？项目是 golang，以及合并之后如何做 relase 谢谢
 | 1 yjxjn 2020-12-09 20:53:09 +08:00 既然很久之前就从 master 分出，那就直接从 master 上 pull 呗，然后看看有没有冲突，解决完冲突 commit 之后，push 到远程分支，提 mergerequest 就完了。 |
 | 2 faker1 OP @yjxjn 对于多个 branch 每个对于 func ABC 的实现是不一样的，那这个时候如何保留， |
| 3 faker1 OP 可能最中还是要一个 baseline，然后其余的独特性，需要特殊处理，如何处理，对于开发人员是友好的，比如编辑器能识别到准确的 |
| 4 faker1 OP 顺便再问下，如何在多个 branch 中，找到大家共同的那个起始点，我搜了下只看到 merge base |
 | 5 ferock PRO 远古分支，合并当前的 master 毫无意义。 何况这样的分支，当时就应该走 fork 路线。 只有 60% 的吻合度，已经可以视为衍生版本了。参考，mysql 和 MariaDB |
| 6 faker1 OP @ferock 60%是需要频繁的 fix/add new code，维护多 branch 代价太大 |
 | 11 fafa2npu 2020-12-09 21:19:22 +08:00 via Android 对于 60%的共用代码单独起一个 repo 作为 base repo，在其他 repo 里引用 base repo 中 build 出来的 package 。 |
| 12 faker1 OP @fafa2npu 这个是有难度的，比如 baseline repo.A 的实现是不能暴露出来的，到时有的 branch 又用到了，，，， |
| 14 faker1 OP package 的拆分也是一个思路， |
 | 15 beidounanxizi 2020-12-09 22:19:47 +08:00 不要走各种分支 就一个 master 分支可以了 hotfix bug 修复 都往 master 合并 master 的上生产河预发 个人分支可以在 dev 环境发 清晰明了 |
 | 16 xupefei 2020-12-09 23:02:42 +08:00 via iPhone 这个问题我司也遇到过，解决方案是聘请一位高人解决冲突，然后跑集成测试。 |
| 19 xupefei 2020-12-10 00:33:08 +08:00 via iPhone @CEBBCAT 不是专职人员，而是公司里一个级别很高的开发。这个人要对系统里的任何地方都很熟悉。 找到这样一个人，给他三周，搞定。 没啥特殊的做法啊，就是一个组件一个组件肉眼 merge，每弄完一个组件就测一遍 |
 | 20 SergeGao 2020-12-10 09:29:36 +08:00 master 作为 upstream repo,只负责所有分支的公共部分,abc 各起一个仓库,公共部分有更改在 upstream 仓库改,然后下游仓库去拉,非通用部分就在各自仓库改 |
 | 21 networm 2020-12-10 10:35:49 +08:00 via iPhone 这个问题一个较好的解决方案是所有定制功能都使用主分支开发，通过开关控制功能的开启。 现有项目需要逐个分支手动合并到主分支，并且添加开关，并通过集成测试，与 @xupepei 说的是一样的。 更进一步的信息可以参考 读书笔记：持续交付 - 狂飙 https://networm.me/2020/11/08/continuous-integration/ |
Select Language