最好的方法的Git版本控制时结合.NET [英] Best way to combine Git with .NET when versioning

查看:177
本文介绍了最好的方法的Git版本控制时结合.NET的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前工作的一个项目(只是我),我已经知道如何处理版本就可以了。我使用的是经典的<大><轻微><建立或补丁>

I'm currently working on a project (just me), and I already know how to handle versioning on it. I'm using the classic <major>.<minor>.<build or patch>.

我的问题是,我想拥有的标签的我的一些的提交的指向相应的版本,但我不想做手工。

The problem I have is that I want to have tags in some of my commits pointing to the corresponding versions, but I don't want to do it manually.

现在我正在做的:

  • 如果我要发布 v0.2.13 ,我改变了的AssemblyInfo.cs ,并设置版本
  • 在提交上的Git的变化
  • 添加标签 v0.2.13 (手动)上的Git
  • 生成项目
  • 创建一个的.zip 文件(不是所有的时间的时间),并将其命名为像项目名v0.2.13
  • If I'm going to release the v0.2.13, I change the AssemblyInfo.cs and set that version
  • Commit the changes on Git
  • Add tag v0.2.13 (manually) on Git
  • Build the project
  • Create a .zip file (not all time time) and name it like ProjectName v0.2.13

我是不是做错了?

我可以很容易地创建一个脚本来自动完成的最后一步,但我不知道是否有关于自动另一部分一个好的做法呢?

I could easily create an script to do the last step automatically, but I'm wondering if there is a good practice about automating the other part?

推荐答案

我在MSBuild的构建脚本可以自动检索git的承诺目前已签出,然后将这样的属性在构建时向大会:

I have a build script in MSBuild that automatically retrieves the git commit currently checked out, and then adds an attribute like this at build time to the assembly:

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

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

The numerical part of the version comes from a version.txt file that my build script reads.

该程序集的版本缺少第三个字节,因为它避免了绑定重定向时增加版本号的要求。该AssemblyFileVersion包含了所有由该属性所允许的数据,AssemblyInformationVersion可以是任何你想要的字符串,因此使用语义版本以包括git的承诺ID允许您指明到底是哪代码版本建立了这个项目。

The assembly version lacks the 3rd octet because it avoids binding redirect requirements when you increment the build number. The AssemblyFileVersion includes all the data allowed by that attribute, and AssemblyInformationVersion can be any string you want, so using semantic versioning to include the git commit id allows you to indicate exactly which source version built this project.

再经过一个构建成功,你可以,如果你想添加一个v0.2.13标签。就个人而言,当我建立一个最终版本,我增加version.txt文件,使所有的后续版本有下一个更高的版本号。每建立后,将有一个直到我释放版本,标注的承诺,再次递增的version.txt文件,并重复。

Then after a build is successful, you can add a v0.2.13 tag if you wish. Personally, as soon as I build a final release, I increment the version.txt file so that all subsequent builds have the next higher version number. Each build after that will have that until I release that version, tagging the commit, increment the version.txt file again, and repeat.

顺便说一句,在 AssemblyInformationalVersion 字符串出现在从Windows资源管理器的文件属性,因此这提供了一个保证的方式,从构建的二进制到匹配的原始来源$任意去C $℃。 此外,遗憾的是这种方法会导致csc.exe的报告的AL ????警告在建立,因为语义版本格式不符合某某语法。这并不意味着什么,虽然是破的,我只是忽略了警告。

By the way, the AssemblyInformationalVersion string appears in file properties from Windows Explorer, so this provides a guaranteed way to go from an arbitrary built binary to the matching original source code. Also, unfortunately this approach causes csc.exe to report an AL???? warning on builds because the semantic version format doesn't conform to x.y.z syntax. It doesn't mean anything is broken though, and I just ignore the warning.

我从来没有明确的拉链拉上来源,因为那是多余的源代码控制的责任。至少,如果你的源是由一些在线服务(即使在您的专用Intranet)主办,大多数git的主机对于给定的提交ID已经提供的即时下载的拉链功能。

I never explicitly zip up sources because that is redundant with source control's responsibility. At least if your source is hosted by some online service (even on your private intranet), most git hosts offer on-the-fly download-as-zip capability for a given commit id already.

这篇关于最好的方法的Git版本控制时结合.NET的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆