在git中为每个部署构建制作一个标签是一个好习惯吗？ [英] Is it a good practice to make a tag in git for every deployment build?

问题描述

我刚从Subversion切换到Git。 Subversion的集中式架构为我提供了一个有意义的版本号，用于构建基于Web的应用程序的更改日志，方便您登录并查看任何给定服务器上运行的版本。 Git没有友好的编号。相反，我看到它建议您从 git status 或 git标签的输出中解析出某些内容。

我不相信我们将永远为我们的分支机构使用客户友好的名称（有时我们将其命名为不想使用我们的系统公开的事实的个人客户）。所以我想我可以让build生成一个datestamp / timestamp标签，如 2012-11-21_08-40-23 ，并使用我以前使用Subversion的方式修订号。当我们构建用于部署的战争文件时，构建将只生成此标记并将其添加到Git，因此任何部署到任何服务器都将生成一个标签。

目前我们部署每隔几天进行一次测试，每月几次整合一次，每几个月进行一次生产。

解决方案

相反，我已经看到它建议您从git status或git标签的输出中解析出来。

它是丑的建议。真的很丑陋。 git描述规则在这里或多或少，阅读 man git描述将比状态或标签或日志或3方可用的脚本

Smth。像这样做好的命名任何版本的伎俩（你可以只标记一些变更集，而不是每个发布的）

git描述--tags - 长 - 匹配'SUBSTRING-OF-CLIENT_TAGFAMILY *'

I just switched from Subversion to Git. Subversion's centralized architecture gives it a meaningful revision number that I used to build into the change-log for our web-based application to make it easy to log in and see which version is running on any given server. Git doesn't have a friendly build number. Rather I've seen it suggested that you parse something from the output of git status or git tags.

I'm not convinced we will always use customer-friendly names for our branches (sometimes we name them for an individual customer who doesn't want the fact that they use our system publicized). So I'm thinking I could have the build generate a datestamp/timestamp tag like 2012-11-21_08-40-23 and use that the way I used to use the Subversion revision number. The build would only generate this tag and add it to Git when we build a war file for deployment, so any deploy to any server would generate a tag.

Currently we deploy to test every few days, integration a few times a month (in bursts), and production every couple months.

解决方案

Rather I've seen it suggested that you parse something from the output of git status or git tags.

It was ugly suggestions. Really ugly and lame. git describe rule here more or less, reading man git describe will be a lot more useful, than status or tag or log or 3-rd-party ready-to-use scripts

Smth. like this do the trick of good naming of any revision (and you can tag only some changeset, not every published)

git describe --tags --long --match 'SUBSTRING-OF-CLIENT_TAGFAMILY*'

这篇关于在git中为每个部署构建制作一个标签是一个好习惯吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！