关于个性化需求的 git 分支管理

• 資深大佬 : TimePPT

  呆过的某团队曾经尝试过，主版本正常开发，个性化定制需求模块化 or 插件化

• 資深大佬 : pomony

  @TimePPT +1 感觉根据模块化的功能来确定分支而不是具体的公司来定，模块化的分支开发好了，往对应公司的分支合并即可~

• 主 資深大佬 : vhysug01

  @TimePPT
  @pomony

  谢谢大佬，尽管不太明白插件化 /模块化 实现，但是大致有点想法了

• 資深大佬 : lazyrm

  gitflow 能行？

• 資深大佬 : baiyi

  Github Fork

  Git 用 remote，比把模块全堆在分支上要清晰一点

• 主 資深大佬 : vhysug01

  @lazyrm
  gitflow 应该也是要配合模块化开发，不然合并会出现一堆问题

• 資深大佬 : wangyzj

  master 上分开到 a,b 后
  每周从 master 上 merge 回来
  然后回归吧

• 資深大佬 : 340244120w

  这就是最简单也是最好的办法了，你们要做的仅仅是规范分支名称
• 資深大佬 : 66450146

  每个功能都加 feature flag，每个包一个配置文件设定哪些功能是启用的

• 資深大佬 : asdf2020

  gitflow 模式就可以吧，我们就是多个 feature 分支，然后每次发版是 release 合并到 master，然后 release 代码合并到 未发布的 featureXX 分支，这样保持一致，避免未来合并代码出错了

• 資深大佬 : konakona

  你这个应用场景我推荐 2 种 flow，分别是 gitlab flow 和 github flow 。不考虑 git flow，太繁琐不合适。

• 資深大佬 : kingzeus

  我现在的方案：
  1.分库，所有都是从主仓库 fork 出来
  2.功能分支，通用的功能推送到主仓库，单独的功能放在子仓库里
  3.主仓库定时发布版本，子仓库定期从主仓库同步

  简单说，使用 gitflow 的方式，管理仓库之间的逻辑

• 資深大佬 : HannibaI

  需要定制化的功能为啥不是放到代码里来管理而是用分支？

• 主 資深大佬 : vhysug01

  @HannibaI 会有小部分冲突，而且多家公司即使只是有小定制化，也会陷入多重 if else 大坑中

• 資深大佬 : dany813

  我们目前是把所有的定制化的分支，全部插件化，即插即用，主版本就一个主分支，然后打 tag

• 資深大佬 : xuanbg

  这个和代码结构有关系，假设定制化代码和通用代码井水不犯河水，那就很简单了。定制化代码的修改只在定制分支进行，通用代码的修改最终合并到 master，然后再把 master 合并到定制化分支就行。
  如果不能做到相互不干扰，那最好是各个分支各自修改，分支也永远不要相互合并。这样其实和多个项目没有区别。