如果您正在构建库、产品或任何其他软件系统，版本控制通常是一件大事。这是确定您正在查看的库、产品或系统版本的唯一方法。在组织确定版本控制策略之前，已经就什么构成主要版本与次要版本、如何从营销角度对组件进行版本控制以及如何处理错误修复进行了许多讨论。除此之外，如果该软件系统涉及库或框架，或仅涉及组件，那么您会很想知道该组件的更新何时涉及重大更改。
幸运的是，开源社区已经为我们解决了这两个问题。首先，我们有 语义版本控制 ，它明确定义了在您进行热修复和补丁、微小的向后兼容改进或重大更改时如何更新您的版本。他们甚至定义了你应该如何后缀你的版本号来表示预发布和内部版本号。假设现在所有体面的软件项目都在使用 Git ，那么另一个问题可以通过遵循 GitFlow 分支策略来解决，这是同胞 Vincent Driessen 发起的。 GitFlow 详细描述了您在哪个分支上进行主要开发工作、如何稳定即将发布的版本以及如何跟踪生产版本。
因此，我暂时假设您将接受语义版本控制方案并遵循 GitFlow 规定的分支策略。如果存在某种工具使用分支名称和 master 上的标签（代表生产版本）为您生成正确的版本号，那不是很酷吗？好吧，开源社区再次出手相助。 Jake Ginnivan 和 NServiceBus 背后的公司 ParticularLabs 的人已经构建了它并将其命名为 GitVersion 。那么让我们看看它是如何工作的。
展示自动版本控制之美
首先，我们需要安装 GitVersion，这通过 Chocolatey 非常简单。
> choco install gitversion.portable
这允许您从命令行运行它。您还可以通过将单个可执行文件复制到源代码管理或将其添加为 NuGet 包， 将其挂接到您的构建系统中。它将检测 TeamCity 和 AppVeyor 等构建引擎并采用其输出。现在让我们假设你有一个新的 Git 项目，第一次提交是在 master 分支上：
> choco install gitversion.portable
现在运行 GitVersion 命令行工具
> choco install gitversion.portable
这将导致以下 JSON 输出：
> choco install gitversion.portable
因此，默认情况下，您的版本编号以 0.1.0 开头。请注意针对特定用途的许多变量。例如，我们将包含提交散列的 InformationalVersion 存储在程序集的 AssemblyInformationalVersion 属性中。同样，我们将 NuGetVersion 用于我们的 NuGet 包。最后，我们的内部版本号映射到 FullSemVer 变量。最后一部分非常重要，因为传统的内部版本号并不能说明实际的变化。使用 Git 版本控制，重建特定提交会呈现完全相同的数字。这创造了更多的可追溯性。
让我们按照 Gitflow 继续在 develop 分支上开发并运行 GitVersion。
> choco install gitversion.portable
现在忽略其余变量，结果如下：
> choco install gitversion.portable
你会注意到两件事。首先，次要版本号会自动更新。其次，版本号是固定的，以明确您在开发分支中的工作。现在让我们添加几个提交，看看会发生什么。
> choco install gitversion.portable
这将导致最后一位数字表示自从我们从 master 分支以来的提交次数。
> choco install gitversion.portable
因此，让我们通过功能分支来处理一个小功能。
> choco install gitversion.portable
再次运行 Gitversion 会给你：
> choco install gitversion.portable
同样，您正在处理的版本一目了然。为了模拟在某些功能上的工作，我将假设再进行几次提交，在此不再重复。在这些更改后运行 GitVersion 会导致：
> choco install gitversion.portable
现在是时候将这些更改集成回开发分支了。
> choco install gitversion.portable
因此，无论您做什么，版本始终与更改同步，无需任何手动任务。
现在假设主体开发已经完成，是时候稳定代码库了。让我们通过启动一个发布分支来明确这一点。
> choco install gitversion.portable
所以发布分支似乎不适用于发布版本。相反，它们用于发布系统的测试版。同样，+0 用于表示自上次发布 Beta 包以来的提交次数。因此，如果您确实发送了这样一个包，您应该用 1.0.0-beta.1 之类的东西标记该提交。当您这样做并向该分支添加任何其他提交时，会发生以下情况。
> choco install gitversion.portable
只要您正在稳定系统或发布中间版本以进行验收测试或类似情况，请留在发布分支上。通过这样做，您可以同时支持即将发布的版本和当前的生产版本。现在，当您准备好投入生产时，是时候合并到 master 了。
> choco install gitversion.portable
重要的是要记住，你应该标记你发送的提交，所以在这种情况下，我们将使用最终版本号标记合并结果。让我们看看 GitVersion 会用它做什么。
> choco install gitversion.portable
这标志着开发周期的结束。任何热修复也应该在 master 上结束，并且它们的最后一位数字会递增，例如 1.0.1、1.0.2。任何后续的开发都应该继续开发，所以作为最后一步，让我们切换回那个分支，看看会发生什么。
> choco install gitversion.portable
很好，不是吗？ GitVersion 了解 master 上该标签的概念，并假设您将继续开发分支上的下一个次要版本。如果您真的想继续使用不同的版本，有多种 方法 可以实现。我只是向您展示了最常见的流程。我强烈建议您查看 GitVersion wiki 中的示例。
总之
简而言之，您只需要记住几件事：
- 开发发生在 develop 分支
- 稳定即将发布的版本和发布测试包发生在发布分支
- master 分支跟踪生产版本和热修复。
- 任何时候你发送一些东西，你必须标记那个提交。无需在其他任何地方跟踪发布。
那么，如果您没有定期发布并且您的项目需要持续交付怎么办？好吧，Github 的人也有同样的问题，并想出了一个 GitFlow 的替代品，叫做 GitHubFlow 。幸运的是，GitVersion 也支持这种 开箱即用的流程 。
那么你使用什么分支策略？你如何跟踪你的发布？通过在下面发表评论或在 @ddoomen 发推文让我知道。
