我们编写一个存放在git存储库中的软件。我们已经将这个软件卖给了几家公司。每家公司都有一台虚拟机在其内部网络中运行我们的一个或多个实例。
我们目前使用git bundle将代码更新推送到远程服务器进行复制。 （很多这些服务器都在企业防火墙之后，所以我们没有更好的选择直接git通信）
这一切都运作得相当好。
纸上......
但实际发生的是，为了更新我们软件的实例，我们必须在我们运行的每个企业中传递本地验证流程。在实践中，这意味着我们很少能够在git中使用我们产品的绝对最新主版本运行我们软件的生产实例。
所以..“明显的”解决方案（我们认为）是一种gitflow-esque方法，我们“简单地”拥有多个发布分支，每个分支对应于我们软件的实际运行生产实例。这将允许我们有多个实例，每个实例运行我们的东西的不同版本，所有这些都具有不同级别的修补程序和所需的东西。
我在最后一段中的引号中加上“明显的”和“sipmly”，因为这个解决方案似乎不是那些东西。在尝试维护每个分支传播的功能和修补程序时，拥有多个发布分支似乎非常麻烦。假设我们编写了一个修补程序，然后我们编写一些内容来将该修补程序合并到50个'发布'分支中以进行分发吗？这很臭吗？
我的问题是......解决这个问题可能存在哪些其他解决方案或推荐？我听说过“持续交付”和“持续部署”软件套件的隆隆声。这是我们需要为我们解决这个问题的世界吗？我认为我真正的问题是这个问题的解决方案是否存在，以及这些解决方案的调用是什么，所以我可以指导我的谷歌。