我目前正在开发一个项目（只有我），我已经知道如何处理它的版本控制。我正在使用经典的<major>.<minor>.<build or patch>。
我遇到的问题是我希望在某些指向相应版本的提交中有标记，但我不想手动执行。
现在我正在做：
v0.2.13，我会更改AssemblyInfo.cs并设置该版本v0.2.13（手动）
.zip文件（并非所有时间），并将其命名为ProjectName v0.2.13 我做错了吗？
我可以轻松地创建一个脚本来自动完成最后一步，但我想知道是否有关于自动化其他部分的良好做法？
答案 0 :(得分：8)
我在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语法。但这并不意味着任何事情都会被打破，我只是忽略了警告。
我从不明确压缩源代码，因为这对源代码管理负有责任。至少如果您的源是由某些在线服务托管的（甚至在您的私有内部网上），大多数git主机已经为给定的提交ID提供了即时下载 - 压缩功能。
答案 1 :(得分：1)
我在提交后使用Makefiles作为一切。
根据构建系统的工作方式，您可以添加标记当前分支并推送此标记的目标“release”。 您还可以添加一个“包”目标，该目标取决于“构建”和“发布”目标。
如果这不起作用，只需创建自己的Makefile。您可能也可能不必以不同方式命名“Makefile”。
答案 2 :(得分：1)
如果您无法使用构建服务器，那么这可能是手动执行此操作的最佳方式。但是，如果您有时间，我强烈建议您使用某种类型的构建服务器。我们在TeamCity取得了很大的成功。如果你设置它来跟踪你的存储库，有办法assembly info patching，tagging和后期构建部署（有很多可能的链接，我建议只是点击{ {3}}）。
我在设置版本时发现documentation非常有用;你几乎可以排除NuGet位，它应该有一些不错的信息。就设置TeamCity而言，只需快速搜索“TeamCity设置教程”，您应该拥有大量资源。祝你好运！
答案 3 :(得分：0)
我已成功使用以下步骤来完成类似的操作：
您可以使用提交后挂钩来标记您的分支并推送到您的TeamCity服务器。
答案 4 :(得分：0)
Nant符合您的需求！检查一下：NAnt tasks reference
它易于使用并与git存储库结合使用： - ）