使用GIT进行软件版本控制
本文关键字:软件 版本控制 GIT 使用 | 更新日期: 2023-09-27 18:06:38
我正在编写C#
中的软件应用程序,目前我正在遵循(可能是最常见的)方案:
Major
。Minor
。Patch
。Revision
,例如1.0.5.36182
。
为了定义应用程序是否处于测试版,我只需检查Patch
整数。是偶数吗?释放。是奇数吗?β。
现在我从SVN切换到Git,并想在我的版本编号中使用提交。最最好是:
Major
。Minor
。Patch
—commit hash
,例如1.0.5-47ad38f
。
问题(s)
- 将我的应用程序定义为beta或只是继续使用我目前的方法最好的方法是什么?
- 是否有一种方法来检查基于GIT散列的应用程序的新版本?
这个问题众说纷纭,但我会试着帮你解决。
将我的应用程序定义为beta或只是继续使用我目前的方法最好的方法是什么?
我建议只标记非测试版,并使用git describe
生成版本,例如git describe HEAD
或git describe some-branch
。该命令的输出类似于
-
some-tag
,在这种情况下,您要求描述的内容(本例中为HEAD
或some-branch
)与标签some-tag
完全对应,或 -
some-tag-<n>-g<hash>
,其中<n>
对应于some-tag
后的提交数量,<hash>
对应于被描述的提交的哈希值。例如,
1.2.3-12-gabcd123
的输出表示所描述的提交是在标签1.2.3
之后的12次提交,并且具有abcd123
的哈希值。
在这个方案下,输出一个简单标签(如1.2.3
)的版本可以被认为是稳定的,而输出一个标签(如1.2.4-12-gabcd1234
)的版本可以被认为是不稳定的。
如果您需要手动标记非稳定版本的能力,您当前使用偶数补丁级别表示稳定版本,奇数补丁级别表示不稳定版本的技术应该可以很好地工作,但是您可能希望按照语义版本控制的建议,使用alpha
和beta
(或其他任意字符串)的组合来标记这些版本。在这种情况下,排序规则是严格定义的:
优先级指的是版本在排序时如何相互比较。优先级必须通过按顺序将版本划分为主要、次要、补丁和预发布标识符来计算(构建元数据不计入优先级)。优先级由从左到右比较每个标识符时的第一个差异决定,如下所示:主要、次要和补丁版本总是用数字来比较。示例:1.0.0 <2.0.0 & lt;2.1.0 & lt;2.1.1. 当major、minor和patch相同时,预发布版本的优先级低于正常版本。示例:1.0.0-alpha <1.0.0. 具有相同major, minor和patch版本的两个预发布版本的优先级必须通过从左到右比较每个点分隔的标识符来确定,直到发现如下差异:仅由数字组成的标识符以数字方式进行比较,由字母或连字符组成的标识符以ASCII排序顺序按词法进行比较。数字标识符的优先级总是低于非数字标识符。如果前面所有的标识符相等,那么较大的预发布字段集比较小的字段集具有更高的优先级。示例:1.0.0-alpha <1.0.0-alpha。1 & lt;1.0.0-alpha。β& lt;1.0.0-beta & lt;1.0.0-beta。2 & lt;1.0.0-beta。11 & lt;1.0.0-rc。1 & lt;1.0.0 .
是否有一种方法来检查基于GIT散列的应用程序的新版本?
只要标记以相同的方式命名,git describe
的输出就具有按字母数字排序的优点。对于语义版本控制,版本比较的定义如上所述。
如果您手动标记不稳定的补丁级别并依赖于奇数/偶数区分符,则比较变得棘手。语义版本控制在这里可能是更好的选择,因为它有良好定义的顺序。
"检查新版本"是一个棘手的问题;你想查询类似GitHub的新标签,并将它们与你当前的标签进行比较吗?