Maven部署和git分支地狱

我正在开发一个单页应用程序，在某个时候，我们决定重新命名（新的皮肤和功能），并决定重新设计css，这使我们改变了html和js。我们本应尽快将新的分支机构合并回master，但现在由于一些营销问题，不得不再推迟六个月。如果我们合并回master，以前的皮肤将被破坏，这意味着我们无法部署任何修复程序…我们不断地从master合并，以使新分支保持最新，但这不能再持续六个月

一个想法是将分支的版本从1.x.x更改为2.x.x，并能够从分支开始创建发布分支和标记，因为我们希望开始部署到私有Beta等，这将使我们在1.x.x处有一个主分支，在2.x.x处有一个分支

另一个解决方案是将旧主题移植到新的css架构中，以便能够合并回主架构，这将需要很长时间

有没有其他办法解决这样的问题？你能看到第一种方法的其他问题吗？

由于牵强的詹金斯选项变得可行，我将我的评论转化为答案

---

创建一个Jenkins作业，在每次提交到主分支时尝试将主分支合并到新分支。不要将实际合并结果推送到任何地方。但是，如果合并失败，则让作业失败，这表明应该有人进行手动合并。这样，您只需在发生冲突时进行合并（在接下来的六个月内）。然而，在半年后不断合并或进行一次大合并时，却无法避免出现问题。

我不确定自己是否看到了问题。有两个版本的应用程序位于不同的分支中。为什么不想从开发测试版的分支中释放测试版（将其视为“主”分支）。不要将实际合并结果推送到任何地方。但是，如果合并失败，则让作业失败，这表明应该有人进行手动合并。这样，您只需在发生冲突时进行合并（在接下来的六个月内）。然而，在半年后不断合并或进行一次大合并时，我们却被拯救了。@Makoto我忘了提到，我们的QA正在敦促我们能够部署新分支的标记版本，因为他们想要稳定和可复制的东西来引发bugagainst@JonasBerlin是的，我们用詹金斯，这是个好主意thnx@Makoto另外，90%的代码与当前主代码相同。如果我们将分支的版本升级到2.x.x，您是否看到从主分支合并的问题？