使用git管理多个并发发布

我们正在管理在任何给定时间具有多个生产版本的产品的工作流。这对车队来说是一个相对较新的情况，我们不确定最好的处理方法。我们将git与私人bitbucket回购一起使用

以前，我们使用的是develope/master git流类型的工作流，它非常有效。最近，我们的客户已经将多个版本投入生产，我们必须像支持自己的产品一样支持每个版本

例如，我们有1.1、1.2和1.5版本，我们必须能够在不影响其他版本的情况下处理和部署每一版本。但理想情况下，它们位于同一个项目中，因为某些更改将在分支之间共享，而其他更改则不会共享

我们正在调查两种可能性：

坚持开发/主控理念，但将其扩展到不同版本，如v1.1-develop、v1.1-master、v1.2-develop、v1.2-master等。。。这与我们之前的流程完全相同，但有3个版本的master/develope。 为每个版本v1.1、v1.2、v1.5使用一个分支，并在发布时进行标记。如果我们需要处理这个分支，我们可以通过标签将它拉出来，处理它，将它签出到一个新的分支中，然后重新标记它。这个版本看起来很笨重。 我也一直在研究git工作树，但它更像是2，因为它提供了多个并发分支，而不是像1这样的分支的倍数。

---

有人有过这种设置的经验吗？1是正确的方法吗？我是否遗漏了2或3版本，这将使其更易于管理？

我的公司为每个版本维护一个单独的分支，因此1.1、1.2、2.1等。然后，我们在每个分支内使用标记来标记点版本，因此1.1.7、1.2.4、2.1.2

分支用于主要/次要版本，因为这是支持/维护的决定点。基于这种分离，我们只支持一定数量的过去版本

每一次发布都是向前推进的。我们永远不会发布1.1.7版，而实际上会对1.1.6版进行更改。发现的问题将在1.1.8中解决，并将适当标记

这看起来像你的2，但我们从来没有真正拉标签。我们仍然基于分支工作，分支指向每个版本的最新提交。标签更具历史性

---

也就是说，这在很大程度上取决于您的组织如何定义其版本以及对这些版本的支持。这对我们的组织非常有效，随着时间的推移，我们可以很容易地确保更改进入适当的渠道，并尽可能少地与git发生冲突。

这听起来更像是一个哲学问题，而不是一个有具体答案的问题。我可以看到这一点，但我实际上正在寻找一个实现过程，而不仅仅是为了什么是最好的方法。我知道你在说什么，这不是一个坏问题，但对于这里的格式来说，它有点太开放了。你提出的那些选择可能会奏效，所以它们在技术上没有什么问题。这类事情最好在论坛上进行讨论，人们可以在论坛上分享他们的故事，这不适合这种问答形式。