git - 使用相同的代码库维护多个版本

Question

我目前正在开发一个 (laravel) 项目，该项目应该会产生两个版本，但我发现自己不断地重新调整和 merge 我的代码。我想是我的 git 工作流程出错了，但我需要注意我做错了什么。
我的宏观问题是 :就像 IntelliJ 维护着几十个具有几乎相同基本功能但内置于不同版本中的 IDE 一样，是否有一些特定的 VCS 策略或最佳实践来这样做？
详细
假设我有一个项目(一个代码库)，用于两个客户 A 和 B。A 想要一个蓝色主题，B 想要一个绿色主题，所以目前我只将它们放在两个不同的分支上。这些分支通常具有特定于客户的更改。
现在我有一个新的功能想要开发，它同时适用于 A 和 B。这就是我现在的做法:

创建分支 new_feature_branch来自 main

在 new_feature_branch 上完成代码

发送 PR 并 merge 到 main

rebase client_a_branch和 client_b_branch在 main

这在正常功能上运行良好，但是当主分支上有一个小错误(比如打字错误)时，每次都必须检查所有这些，以便修补后的代码可以到达客户端分支看起来有点尴尬和......对我来说不直观(？)。
我只想确定这是否是“具有相同代码库的多个版本”项目的一般处理方式？如果不是，一般是怎么做的？ (指向我应该研究的内容的简单链接或关键字会很有帮助)
我完全不知道生产中的事情是如何运作的，而且我对自己的 git 知识也没有信心，如果这个问题看起来很幼稚或其他什么，那么抱歉。
提前致谢!

Answer 1

在以下情况下 Rebase 应该没问题:

客户端分支上的所有独特提交都是线性的。这意味着您没有新的 merge 提交(可能来自 PR)。

其他人没有积极开发客户端分支。这(通常)很重要，因为在 rebase 后您必须强制推送，并且如果其他开发人员正在积极地从客户端分支分支，则每次 rebase 时都需要进行协调。

客户分支不会偏离 main 太远. “太远”当然是主观的并且取决于案例，但想象一个场景，其中每个客户端分支都有 100 个自己的提交，这些提交大量修改了共享代码。最终 rebase 可能会变得乏味，因为在 rebase 期间需要解决许多 merge 冲突。

备注 :关于 rebase 的普遍看法到此结束，我的意见如下。
你应该/可以做什么？

暂时继续你的 rebase 策略，直到你不能或它变得太乏味，或者你做出改变，这样你就不再需要单独的客户端分支(在下面的 #2 中描述)。如果你不能再 rebase 但还没有达到 #2，那么开始定期 merge main进入客户端分支，而不是将它们重新绑定(bind)到 main .总的来说，我倾向于更喜欢这种工作流程:“在可能的情况下重新定位并且有意义，否则 merge 。”

采取措施让每个客户只拥有一个具有最少配置/模板的主分支，以处理部署时的差异。我曾与许多拥有多个客户的公司合作过，从代码库略有不同，到代码库大不相同。显然，代码库越接近， merge 它们就越容易。请注意，您是否能做到这一点通常取决于谁拥有代码。如果您拥有该软件，那么您可以更轻松地控制谁获得哪些功能以及何时获得，并且可能可以实现带有标志/开关/等的单一代码库。如果客户雇用您只为他们编写自定义代码，则更加困难，甚至可能无法拥有一个单一的代码库。在我公司，我们最近完成了将 3 个不同的客户代码库 merge 为一个 main分支。由于复杂性，需要数年时间才能完成。现在我们为每个拥有单独部署的客户提供不同的配置，对于那些共享相同物理运行时环境的客户，我们有基于登录用户公司的代码切换或数据库数据差异。自从我们进行切换以来，所有新的开发和部署都得到了极大的简化。

如果如您所描述的那样，客户端之间的唯一区别是颜色主题或细微差别，那么我认为 #2 应该很容易实现。