如何在GitHub上控制项目的版本

如今，我试图在GitHub上花费尽可能多的时间（即使我是团队中唯一的团队成员），以真正感受到现实世界中企业应用程序的情况。

我要解决的一个问题是控制版本。假设我们开始了一个项目。然后，团队成员创建了一些分支并在那里发展。准备好进行生产时，我们将所有分支与master分支合并。最后，我们开始使用version 1.0。

现在该版本1.0已发布，并且该软件的该版本存在一些问题。我们希望开始开发版本1.1，以解决由于匆忙执行项目而引入的问题。

现在，问题是这样的：

我们应该如何在这里控制版本控制？

我们是否应该为此创建一个新分支，v1.0并在其中保留1.0软件的版本，并在某些分支上（或不进行）开发，与之合并master，一起使用version 1.1？

是否有针对此类情况的约定？

我发现（并开始采用）以下分支模型：

^{（图片摘自）}

该文章中描述了许多好的做法和严格的规则，我强烈建议您这样做。

兴趣点：

• master分支是您标记版本的地方。这里没有发展。如果在生产环境中部署了错误，请在修补程序分支上修复该错误，并合并并标记新版本。
• 开发发生在开发分支和功能分支上。就个人而言，我会在devel分支和功能分支上的功能上进行错误修复。
• 当软件开始发行时，我分支到发行分支。发布分支是我做最后润饰的地方。突出版本号，更改元数据等。以及一些小错误修正。完成后，我将其合并到母版，标记并称为版本。
• 两个主要分支：主人是“圣洁的分支”；它的HEAD始终是最新的生产代码，develop是夜间分支。它的HEAD总是反映出最新（但可能不稳定）的代码添加。

在您的特定情况下，步骤将取决于该版本的紧急程度。如果遗漏了某些功能，我将返回到开发版本并再次进行整个操作。如果它是已部署版本中的错误，我将分支到一个修补程序分支，修复该错误，并合并并标记v1.1。如果两者都存在，我将首先修复错误，然后再按照说明添加功能。

我大部分时间目睹的是：

• 主人是您的产品。最终，所有将来的x.0版本都将成为主版本。
• 您为生产中的每个版本创建标签/分支，因此仍可以为需要它的任何客户提供支持。
• 合并一个或另一个的修复程序将根据具体情况进行处理。