gpt4 book ai didi

git:可靠地切换到分离的 HEAD,然后稍后恢复 HEAD,全部来自脚本

转载 作者:太空狗 更新时间:2023-10-29 13:41:59 26 4
gpt4 key购买 nike

这就是场景。我有一个运行一些测试的脚本。我需要制作另一个接受 git 提交名称作为参数的脚本,然后执行以下操作:

  1. 保存当前提交状态 - 分支名称或未命名提交。
  2. 在指定提交时切换到分离的 HEAD
  3. 针对该提交运行测试脚本
  4. 切换回来,使 HEAD 与此业务之前相同

我需要确保这个脚本是健壮的,这样无论存储库的状态如何,它都不会造成破坏。它应该在从分离的 HEAD 或常规分支运行时工作,并且最好即使周围有未提交或未暂存的更改也应该工作。

我觉得这应该是一个容易回答的问题,因为针对之前的提交运行测试脚本似乎是一项非常常见的自动化任务。但我似乎找不到任何简单的系列命令来执行此操作。

(类似于 pushd / cd / popd 对当前工作目录所做的)。

最佳答案

如果它在脚本中,仅针对这一个用例,您不需要做任何 super 花哨的事情,只需存储 HEAD 之前的位置,然后再次检查:

# If HEAD is a sym-ref, the first assignment will work
# otherwise, it's detached, so get the SHA1 with rev-parse
if ! head=$(git symbolic-ref HEAD 2>&1); then
head=$(git rev-parse HEAD)
fi
# trim a refs/heads/ prefix; no-op otherwise
head=${head#refs/heads/}


# now go on and do your stuff, test, whatever you like

# then return to where you were
# This will ERASE ANY LOCAL CHANGES.
git checkout -f $head

这样做的好处是无论你在中间做什么 - 特别是你可以在那里做很多 git 操作 - 也许是测试 merge ,或者挑选一个提交进行测试(也许测试那个提交,也许它包含一些纯粹用于测试的构建配置设置)。由于这些操作会创建提交,因此它们会导致 HEAD@{1} 方法失败(您需要使用 HEAD@{2})。更好的是,如果您的测试实际上涉及创建临时分支,这仍然有效,而 @{-1} 方法则不会。

(另外,据我所知,HEAD@{1} 始终检查 HEAD 在此时引用的 commit,而不是检查的分支然后指向那个提交。这种说法是有道理的,因为从那时起分支可能已经发生了可以想象的改变。)

关于git:可靠地切换到分离的 HEAD,然后稍后恢复 HEAD,全部来自脚本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3466181/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com