首先公共部分提取要做好，区分什么是公共部分
--- 与业务无关，比如 UI 库，utils 等等

其次部分共享数据，因为上了子域名。只需要做好 cookie 共享就行。每个系统自行获取共享数据，获取的能力可以放到公共部分

最后业务中如果有需要共享的部分，建议走 webpack 的 mudole federation 即可。不需要上什么微前端，场景不合适


至于你纠结的点：
1：monorepo 用不用不是大问题，无非是本地开发体验更友好，走单独的 library 再 link 效果差不多。
2：不适合微前端方案，不建议上
3：monorepo 只是一种代码组织方式，和微前端没关系。

首先，A 分支里面的功能很难通过 cheery-pick 处理。大概率 commit 并不是按照单一功能来提交的，并且后续的 bug 修复也会产生非常多的 commit 。所以 cherry-pick 这条路走不通。同理 rebase ，merge 之类的也很难

我建议是如果 A 里面的功能是对 main 的架构完善和补充，可以整理出来这部分代码合回到 main 中
如果只是特定功能或者业务逻辑处理，并且除了 B 难以再复用，那就直接用现在的方案，拷贝过来对比看
如果是通用业务逻辑，可以基于 main 拉取一个分支 C ，再将 A 中代码沉淀到此分支。B 分支再 rebase C

统一感谢大家的祝福，也祝各位工作顺心～天天开心

@Shawnan 恭喜转管理
@ha2ha 我主要考虑几个点：1 、绝大部流行的技术都是国外搞出来的，懂英语永远可以看第一手资料
2 、扩展视野，无论是学习东西还是沟通交流。会英语和不会的选择面差距很大
3 、工作技能，英语好可以去外企。
4 、如果以后有一天国内真的混不下去了，不管是 run 还是远程找工作，英语都是门槛

@pt2021 对，所以说也走错了很多路。
@lincanbin 挺好的啊，频繁跳槽并不好
@chuck1in 是公司架构是 ddd ，前端基于这个的基础来做的解决方案。所以要了解才行，不然做技术评审的时候听不懂
@liaojl 频繁换确实不太好，咱们这也是没办法呢，那个时候那懂这些

@Noicdi 感谢～也祝你生活愉快
@shetz163 thirty is a new twenty ！
@Yukineko 刚刚是毕业第一份工作的 5 倍，中途其实很多都是干了几个月

@Noicdi 感谢～也祝你生活愉快

@admol 谢谢，也祝你身心愉悦～

@aqw012 我的微信：Y29kaW5nU3RhY2tvdmVyZmxvdw==

@yuanmomo 没有找到你的微信～，可以加个微信吗？

冲

其他几个选项到今天也不会很差才对

笑死了被这个对话