我目前正在处理一个项目（只有我自己），并且我已经知道如何处理它的版本控制。我使用的是经典的<major>.<minor>.<build or patch>。
我的问题是我想在我的一些 commits 中有 tags 指向相应的版本，但我不想手动进行。
现在我正在做：
v0.2.13，我会更改 AssemblyInfo.cs 并设置该版本v0.2.13（手动）.zip 文件（并非所有时间）并将其命名为ProjectName v0.2.13
我做错了吗？
我可以轻松地创建一个脚本来自动执行最后一步，但我想知道是否有关于自动化另一部分的好习惯？
【问题讨论】：
标签： .net git versioning
我在 MSBuild 中有一个构建脚本，它会自动检索当前签出的 git 提交，然后在构建时将这样的属性添加到程序集：
[assembly: AssemblyInformationalVersion("0.2.13+e3a6f2c1")]
[assembly: AssemblyVersion("0.2")]
[assembly: AssemblyFileVersion("0.2.13")]
版本的数字部分来自我的构建脚本读取的 version.txt 文件。
程序集版本缺少第 3 个八位字节，因为它在您增加内部版本号时避免了绑定重定向要求。 AssemblyFileVersion 包含该属性允许的所有数据，AssemblyInformationVersion 可以是您想要的任何字符串，因此使用semantic versioning 包含 git commit id 可以让您准确指示构建此项目的源版本。
然后在构建成功后，如果您愿意，可以添加 v0.2.13 标签。就个人而言，一旦我构建了最终版本，我就会增加 version.txt 文件，以便所有后续构建都具有下一个更高的版本号。之后的每个构建都会有这个，直到我发布那个版本，标记提交，再次增加 version.txt 文件，然后重复。
顺便说一句，AssemblyInformationalVersion 字符串出现在 Windows 资源管理器的文件属性中，因此这提供了从任意构建的二进制文件到匹配的原始源代码的有保证的方法。
此外，不幸的是，这种方法会导致 csc.exe 报告 AL????构建警告，因为语义版本格式不符合 x.y.z 语法。但这并不意味着任何东西都坏了，我只是忽略了警告。
我从不明确压缩源代码，因为这对于源代码控制的责任来说是多余的。至少如果你的源代码是由一些在线服务托管的（甚至是在你的私有 Intranet 上），大多数 git 主机已经为给定的提交 ID 提供了即时下载为 zip 的功能。
【讨论】：
pathFilters 属性来配置它。
我对提交后的所有内容都使用Makefiles。
根据您的构建系统的工作方式，您可能能够添加一个目标“发布”，它标记当前分支并推送此标记。 您还可以添加一个依赖于“构建”和“发布”目标的“包”目标。
如果这不起作用，只需创建您自己的 Makefile。您可能需要也可能不需要以不同的方式命名您的“Makefile”。
【讨论】：
如果您没有使用构建服务器的能力，那可能是最好的手动方式。但是，如果您有时间，我强烈建议您安装某种类型的构建服务器。我们在TeamCity 方面取得了很大的成功。如果您设置它来跟踪您的存储库，则可以使用assembly info patching、tagging 和构建后部署的方法（有很多可能的链接，我建议您只需点击documentation）。
我发现this post 在设置我们的版本控制时非常有用；你几乎可以排除 NuGet 位，它应该有一些不错的信息。就设置 TeamCity 而言，只需快速搜索“TeamCity 设置教程”，您就会拥有大量资源。祝你好运！
【讨论】：
我已成功使用以下步骤来完成类似的事情：
您可以使用提交后挂钩来标记您的分支并推送到您的 TeamCity 服务器。
【讨论】：
Nant 满足您的需求！检查这个：NAnt tasks reference
它易于使用并与 git 存储库结合 :-)
【讨论】：