所有建议的错误是什么(Matthew Brett 解释除外,此答案是最新的)?
当您在 不同的历史点 时,只需在 jQuery Git 历史记录上运行其他人提供的任何命令,并使用 visual tagging history representation 检查结果(我 did 这就是你看到这篇文章的原因):
$ git log --graph --all --decorate --oneline --simplify-by-decoration
今天许多项目在主线的单独分支中执行发布(以及标记)。
这有强有力的理由。只要看看任何完善的 JS/CSS 项目。对于用户约定,它们在 DVCS 中携带二进制/缩小版本文件。作为项目维护者,您自然不希望用无用的二进制 blob 将您的主线 diff 历史弄得一团糟,并在主线之外执行构建工件的提交。
因为 Git 使用 DAG 而不是线性历史 - 很难定义距离度量,所以我们可以说 - 哦,rev 最接近我的 HEAD!
我开始了自己的旅程(看看里面,我没有将精美的证明图片复制到这篇长篇文章中):
What is nearest tag in the past with respect to branching in Git?
目前我对标签和修订之间的距离有4个合理的定义,随着有用性的降低:
-
最短路径长度从
HEAD到合并基数与标签
-
合并基数在
HEAD和标签之间的日期
-
转数可从 HEAD 访问但无法从标签访问
-
标记的日期,无论合并基数
我不知道如何计算最短路径的长度。
根据HEAD和标签之间合并基数的日期对标签进行排序的脚本:
$ git tag \
| while read t; do \
b=`git merge-base HEAD $t`; \
echo `git log -n 1 $b --format=%ai` $t; \
done | sort
它可用于大多数项目。
根据转数对标签进行排序的脚本,可以从 HEAD 访问但不能从标签访问:
$ git tag \
| while read t; do echo `git rev-list --count $t..HEAD` $t; done \
| sort -n
如果您的项目历史在提交时有奇怪的日期(因为 rebase 或其他历史重写或某些白痴忘记更换 BIOS 电池或您对历史执行的其他魔法),请使用上述脚本。
对于标签的最后一个选项(标签的日期,无论合并基数),以获取按日期排序的标签列表:
$ git log --tags --simplify-by-decoration --pretty="format:%ci %d" | sort -r
要知道当前的修订日期,请使用:
$ git log --max-count=1
请注意,git describe --tags 有其自身的用途,但不能用于查找项目历史中人类预期的最近标记。
注意您可以在任何修订版中使用上述配方,只需将 HEAD 替换为您想要的!