每次 git Push 完成后都会更新版本吗?

发布于 2024-10-09 04:08:14 字数 499 浏览 7 评论 0原文

我们如何在每次推送时使用 git 更改版本(每个+1)?

例如,我每个标题上都有一个 2 php 文件,

libs/lib1.php
libs/lib2.php

通常会有一些信息,例如

/**
 * LIB1.PHP
 * this libs does something like this
 * and that this is a doc for you
 * @version 145
 * @todo something todo
 * @author DAMS
 */

/**
 * LIB2.PHP
 * this libs does something like this
 * and that this is a doc for you
 * @version 445
 * @todo something todo
 * @author DAMS
 */

我们可以在每次推送时搜索并添加 +1 do 版本吗?

how do we do like changing version ( each +1 ) using git on each push?

example i have a 2 php file

libs/lib1.php
libs/lib2.php

on each header usually there is some information like

/**
 * LIB1.PHP
 * this libs does something like this
 * and that this is a doc for you
 * @version 145
 * @todo something todo
 * @author DAMS
 */

/**
 * LIB2.PHP
 * this libs does something like this
 * and that this is a doc for you
 * @version 445
 * @todo something todo
 * @author DAMS
 */

can we search and add +1 do version every time we push?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

顾铮苏瑾 2024-10-16 04:08:14

您所要求的本质上是关键字扩展。首先,请查看 Git 常见问题解答问题“git 是否有关键字扩展?”。它说:

不建议扩展关键字。关键字扩展会导致各种奇怪的问题,并且实际上并没有什么用处,尤其是在 SCM 的上下文中。您可以使用自定义脚本在 git 之外执行关键字扩展。 Linux 内核导出脚本执行此操作是为了在 Makefile 中设置 EXTRA_VERSION 变量。

如果您确实想这样做,请参阅gitattributes(5)。如果您的翻译是不可逆的(例如 SCCS 关键字扩展),这可能会出现问题。 (提示:提供的 $Id$-expansion 放置 40 个字符的十六进制 blob 对象name 到 id 中;您可以使用类似 this 的脚本找出哪些提交包含此 blob .)

请参阅此处讨论,以及这里介绍 GIT 如何提供帮助< /a>.


所以 git 确实有类似关键字扩展的功能,尽管不推荐。 Git 也没有“文件修订版”的概念(这就是您的 @version 编号),因此这无法准确地提供您所要求的内容为了。

您也可以创建一个挂钩(可能是预接收挂钩?),这将为您增加版本。这只是一个可执行文件(因此它可以是 shell/Python/Perl/Ruby/任何您喜欢的脚本),当您执行推送时,它会自动执行。请参阅 githooks 手册页

您的挂钩脚本将:

  • 识别将要修改的文件。
  • 其中,找到包含模式 @version \d+ 的版本
  • 以增加版本。您想要增加父提交中的值,而不是文件中当前的值!

请注意,这至少与使用 Git FAQ 建议反对的关键字扩展一样糟糕,甚至可能更糟糕。这可能会导致恼人的合并冲突。您也可能很容易在代码中出现误导性的版本号,特别是如果您必须向旧版本提交错误修复,尽管每当您合并来自多个存储库/分支的更改时也可能会发生这种情况(这对于大多数人来说很常见) git 工作流程)如果你不小心的话。

What you're asking for is essentially keyword expansion. To start, take a look at the Git FAQ question "Does git have keyword expansion?". It says:

Keyword expansion is not recommended. Keyword expansion causes all sorts of strange problems and isn't really useful anyway, especially within the context of an SCM. You can perform keyword expansion outside of git using a custom script. The Linux kernel export script does this to set the EXTRA_VERSION variable in the Makefile.

See gitattributes(5) if you really want to do this. If your translation is not reversible (eg SCCS keyword expansion) this may be problematic. (Hint: the supplied $Id$-expansion puts the 40-character hexadecimal blob object name into the id; you can figure out which commits include this blob by using a script like this.)

See here for a discussion, and here on how GIT may help anyway.

So git does have something like keyword expansion, though it's not recommended. Git also doesn't have the concept of a "file revision" (which is what your @version number appears to be), so this wouldn't be able to give you exactly what you're asking for.

You could alternatively create a hook (probably a pre-receive hook?), that would increment the version for you. This is just an executable (so it can be a shell/ Python/ Perl/ Ruby/ whatever-you're-comfortable-with script) that'll get executed automatically when you do a push. See the githooks man page.

Your hook script would:

  • Identify files that are about to be modified.
  • Of those, find ones that contain the pattern @version \d+
  • Increment the version. You want to increment the value in the parent commit, not the value that's currently in the file!

Note that this is at least as bad as using the keyword expansion that the Git FAQ recommends against, and possibly much worse. This will likely to lead to annoying merge conflicts. You could also easily end up with misleading version numbers in your code, especially if you ever have to commit a bugfix to an older version, though it will probably also happen whenever you merge changes from multiple repos/branches (which is pretty common with most git workflows) if you aren't careful.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文