我目前正在开发一个 (laravel) 项目,该项目应该会产生两个版本,但我发现自己不断地重新调整和 merge 我的代码。我想是我的 git 工作流程出错了,但我需要注意我做错了什么。
我的宏观问题是 :就像 IntelliJ 维护着几十个具有几乎相同基本功能但内置于不同版本中的 IDE 一样,是否有一些特定的 VCS 策略或最佳实践来这样做?
详细
假设我有一个项目(一个代码库),用于两个客户 A 和 B。A 想要一个蓝色主题,B 想要一个绿色主题,所以目前我只将它们放在两个不同的分支上。这些分支通常具有特定于客户的更改。
现在我有一个新的功能想要开发,它同时适用于 A 和 B。这就是我现在的做法:
new_feature_branch
来自 main
new_feature_branch
上完成代码main
client_a_branch
和 client_b_branch
在 main
这在正常功能上运行良好,但是当主分支上有一个小错误(比如打字错误)时,每次都必须检查所有这些,以便修补后的代码可以到达客户端分支看起来有点尴尬和......对我来说不直观(?)。
我只想确定这是否是“具有相同代码库的多个版本”项目的一般处理方式?如果不是,一般是怎么做的? (指向我应该研究的内容的简单链接或关键字会很有帮助)
我完全不知道生产中的事情是如何运作的,而且我对自己的 git 知识也没有信心,如果这个问题看起来很幼稚或其他什么,那么抱歉。
提前致谢!
最佳答案
在以下情况下 Rebase 应该没问题:
main
太远. “太远”当然是主观的并且取决于案例,但想象一个场景,其中每个客户端分支都有 100 个自己的提交,这些提交大量修改了共享代码。最终 rebase 可能会变得乏味,因为在 rebase 期间需要解决许多 merge 冲突。 备注 :关于 rebase 的普遍看法到此结束,我的意见如下。
你应该/可以做什么?
main
进入客户端分支,而不是将它们重新绑定(bind)到 main
.总的来说,我倾向于更喜欢这种工作流程:“在可能的情况下重新定位并且有意义,否则 merge 。” main
分支。由于复杂性,需要数年时间才能完成。现在我们为每个拥有单独部署的客户提供不同的配置,对于那些共享相同物理运行时环境的客户,我们有基于登录用户公司的代码切换或数据库数据差异。自从我们进行切换以来,所有新的开发和部署都得到了极大的简化。 如果如您所描述的那样,客户端之间的唯一区别是颜色主题或细微差别,那么我认为 #2 应该很容易实现。
关于git - 使用相同的代码库维护多个版本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67931060/