1

根据我的SO 帖子，我一直使用 Github 作为我们的 VCS，并且在 windows Github 工具的帮助下，处理这些基本操作非常棒。然而，对于类似合并的操作，我必须回到 Gitbash （SO Post），但没关系。

因此，源代码级别的 VCS 就位。现在，我们想向前迈出一步，使用其简单的问题跟踪器来进行“发布控制”。对我们来说，这意味着能够跟踪每个稳定的构建（它可以是新功能或错误修复等）。这个想法是创建问题，将它们绑定到里程碑并使用 Github 提交评论来关闭问题并标记它作为一个稳定的版本/构建。标记在哪里出现？

我了解到我们有一个“开发”分支来进行持续的更改，并定期与 master 合并（即每个稳定版本）。

这是正确的方法吗？我们需要能够从 1.1 回到发布/构建 1.0 - 某种回滚以防万一将来需要它（这可能吗？如何？） Github 是否满足或我们还需要使用一些外部工具？

请分享您的经验和建议。

4

1 回答 1

0

在等待其他专家的评论时，我想分享一个我遇到的并且看起来很棒的模型！

一个成功的 Git 分支模型（ SO Post）

总而言之，这是我如何满足我的基本需求（并在需要时对其进行扩展）-

  • 最初维护两个分支“master”和“development”
  • Master 应该始终有一个稳定的版本，并且开发有一个持续的源（可能不稳定）
  • 未来，如果我们需要在发布后修复错误，我们可以创建一个 hotfix 分支，并在稳定时将其与 master/development 合并
  • 我发现的一件好事是我可以以标签的形式维护稳定的版本（即每个新版本的新标签）
  • 最终，随着我们继续每个稳定版本，主分支将与开发合并

使用上述模型可以处理更多内容，但我看到我最初的担忧得到了解决。有更好的建议吗？

于 2013-04-12T14:11:19.737 回答