为什么git describe会选择它所做的标记

m2xkgtsf  于 2023-01-28  发布在  Git
关注(0)|答案(2)|浏览(142)

我正在为一家公司开发一个内部的web应用程序,它托管在一个私人的github存储库中,但是我的大部分开发工作都是在家里的linux桌面上完成的,而这个web服务器托管在公司办公室的一个小型raspberry pi上,它本质上是nginx前端将/api url代理到一个pm2支持的nodejs应用程序。
我通过git push ing从我的家部署到github存储库,通过git pull ing部署到服务器中的生产分支。git hookpost-commit脚本在临时停止生产api服务器之前,在build目录中运行npm安装。在节点上复制_modules目录并运行脚本,该脚本本质上执行git describe --abbrev=0 --tags以获取版本号并将其存储在.env文件中,以便生产服务器向其通告其版本客户。
如果我在家里运行git describe,它给出的版本是v4.2.2,但是在诊所里我得到的是v4.1.17,我不明白为什么
在下面的图像中,左手部分是gitk --all在我的主存储库中的输出,在诊所中只有终端访问权限,您可以从右手部分看到使用git log的几乎相同的图形-缺少与masterproduction分支无关的提交。v4.2.2只有两个提交,而v4.1.17至少还有10个。
为什么git describe会有这样的行为呢?
编辑:我大概知道答案了--在服务器上有一个post-commit钩子,它最终在分支上进行了一次提交,尽管它不应该这样做--它只应该在开发机器上进行。

wf82jlnq

wf82jlnq1#

  • @TTT在评论中回答:*

也许问题的原因是你想让服务器本地生产分支和你的主分支一样,但是它不是。所以每次它拉的时候,它都会做一个新的合并提交。也许服务器应该推出它的版本(如果你想保留的话),或者服务器应该用git fetch && git reset --hard @{u}而不是git pull来获取最新的提交(如果服务器不应该自己提交的话)。

xdyibdwo

xdyibdwo2#

Git 2.40(Q1 2023),阐明了当钩子被调用时,你必须为环境变量做些什么。
这将有助于git describe在钩子中的行为符合预期。
参见Eric Sunshine ( sunshineco )(2023年1月9日)。
(由Junio C Hamano -- gitster --合并至commit fc2735f,2023年1月21日)

githooks:讨论国外仓库中的Git操作

签署人:埃里克·桑森
确认人:Jeff King
当钩子调用本地存储库以外的存储库中的Git命令时,钩子的作者经常会因为难以诊断的错误而措手不及。
特别是,引用本地仓库的Git环境变量,如GIT_DIRGIT_WORK_TREE,,会导致Git命令在本地仓库上操作,而不是在作者想要的仓库上操作。
无论环境变量是由用户手动设置还是由Git自己自动设置,都是如此。
当钩子在同一个存储库的不同工作树中调用Git命令时,也会出现同样的问题。
建议避免这个问题的最佳实践$是钩子在调用外部仓库或其他工作树中的Git命令之前确保Git变量是未设置的:

unset $(git rev-parse --local-env-vars)

然而,这一建议在任何地方都没有记录。
通过在githooks.txt文档中提及来纠正此缺陷。
另见:

githooks现在在其手册页中包括:
导出环境变量,如GIT_DIRGIT_WORK_TREE等,以便钩子运行的Git命令可以正确定位仓库。
如果钩子需要调用外部仓库或同一仓库的不同工作树中的Git命令,那么它应该清除这些环境变量,这样它们就不会干扰外部位置的Git操作。
例如:

local_desc=$(git describe)
foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)

相关问题