在版本控制时将Git与.NET结合的最佳方法

Question

我正在研究一个项目(只有我),我已经知道如何处理它的版本控制.我正在使用经典<major>.<minor>.<build or patch>.

我遇到的问题是我希望在我的一些提交中有标记指向相应的版本,但我不想手动执行.

现在我正在做:

• 如果我要发布v0.2.13,我改变AssemblyInfo.cs并设置该版本
• 在Git上提交更改
• v0.2.13在Git上添加标签(手动)
• 建立项目
• 创建一个.zip文件(不是所有时间)并命名为ProjectName v0.2.13

我做错了吗？

我可以轻松地创建一个脚本来自动完成最后一步,但我想知道是否有一个关于自动化其他部分的良好实践？

Answer 1

我在MSBuild中有一个构建脚本,它自动检索当前检出的git提交,然后在构建时将这样的属性添加到程序集中:

[assembly: AssemblyInformationalVersion("0.2.13+e3a6f2c1")]
[assembly: AssemblyVersion("0.2")]
[assembly: AssemblyFileVersion("0.2.13")]

该版本的数字部分来自我的构建脚本读取的version.txt文件.

程序集版本缺少第3个八位字节,因为它可以在增加构建号时避免绑定重定向要求.AssemblyFileVersion包含该属性允许的所有数据,AssemblyInformationVersion可以是您想要的任何字符串,因此使用语义版本控制来包含git commit id可以准确指出构建此项目的源版本.

然后,在构建成功后,您可以根据需要添加v0.2.13标记.就个人而言,只要我构建最终版本,我就会增加version.txt文件,以便所有后续版本都具有下一个更高版本号.之后的每个构建都将具有该版本,直到我发布该版本,标记提交,再次递增version.txt文件,然后重复.

顺便说一句,该AssemblyInformationalVersion字符串出现在Windows资源管理器的文件属性中,因此这提供了从任意构建的二进制文件到匹配的原始源代码的保证方式.此外,不幸的是,这种方法导致csc.exe报告AL ???? 构建警告,因为语义版本格式不符合xyz语法.这并不意味着任何事情都被打破了,我只是忽略了警告.

我从来没有明确压缩源代码,因为这对源代码管理的责任是多余的.至少如果您的源是由某些在线服务托管的(甚至在您的专用Intranet上),大多数git主机已经为给定的提交ID提供了即时下载-as-zip功能.

Answer 2

我已成功地使用以下步骤来完成类似的事情：

• 将新提交推送到共享 git 存储库
• TeamCity 服务器检查代码、运行测试并构建项目
• 如果成功，TeamCity 还会移动/删除/打包部署包的文件
• 然后它将 zip 文件通过 FTP 传输到部署暂存区域，可以在其中手动部署（这可以完全自动化，但我们的设置很奇怪）

您可以使用提交后挂钩来标记您的分支并推送到 TeamCity 服务器。