使用git

Question

我们正在管理在任何给定时间生产多个版本的产品的工作流程。对于团队来说这是一个相对较新的情况，我们不确定最好处理这个问题。我们正在使用带有私人bitbucket repo的git。

以前，我们使用的是开发/主git流程类型的工作流程，它运行良好。最近，我们的客户已将多个版本投入生产，我们必须支持每个版本，就好像它是自己的产品一样。

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

我们正在研究的两种可能性：

• 坚持开发/掌握创意，但将其扩展到不同的版本，例如v1.1-develop，v1.1-master，v1.2-develop，v1.2-master等...这就像我们以前的流程，但有3个版本的master / develop。
• 为每个版本v1.1，v1.2，v1.5使用单个分支，并在发布版本时进行标记。如果我们需要处理我们的标签，请按照标签进行操作，将其签出到新分支并重新标记。这个版本看起来非常笨重。
• 我也一直在关注git工作树，但这似乎更像是＃2，因为它提供了多个并发分支，但不是＃1等分支的倍数。

有没有人有这种设置的经验？ ＃1是正确的方法吗？我错过了＃2或＃3的东西会让它更易于管理吗？

Answer 1

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

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

每个点发布都是前进的进展。我们永远不会有版本2.1.2，实际上会对1.1.7进行更改。发现的问题将在1.1.6中得到解决，并会进行适当的标记。

这似乎与你的＃2类似，但我们实际上从来没有“按标签拉”。我们仍然基于分支工作，分支指向每个版本的最新提交。标签更具历史性。

尽管如此，这在很大程度上取决于您的组织如何定义其版本并支持这些版本。这对我们的组织来说非常有效，并且随着时间的推移，我们很容易确保变更能够进入适当的渠道，并且必须使用git进行最小的战斗。