3

我有一个项目，我使用了一种相当不常见的标签策略。我们最终的标签是叶子，所以我们的历史看起来像这样：

  0.3.0                        0.3.0
|/                               |
| 0.2.0      rather than       0.2.0
|/                               |
| 0.1.0                        0.1.0
|/                               |

我这样做的原因是我们的标签应该包含dist输出，而在开发过程中我们不想将这些文件提交到版本控制中。因此，当我运行构建时，构建工具会自动分支，dist使用生成的提交添加构建工件（文件夹），然后在那里创建标签。

乍一看，这个工作流程可能看起来很奇怪，但到目前为止，我发现它非常方便，因为我们需要dist在标签中包含该文件夹以进行下游部署过程。

现在的问题是，我想自动生成发行说明，只是问题是，在这种情况下我如何找出以前的标签？我知道这里给出的答案，但是标签是叶子，这不起作用。

4

5 回答 5

2

（编辑：下面的原始奖励答案，这是一种更简单的标签合并碱基的方法，因此git describe可以找到它们。

doit () 
{ 
    cleanup="`mktemp -t`";
    git for-each-ref refs/tags/"$1" --format='
           echo git tag -d base/%(refname:short) >> '"$cleanup"'
           git tag base/%(refname:short) $(git merge-base HEAD %(refname:short))
        ' | sh -x;
    result=`git describe --tags`;
    sh -x "$cleanup";
    rm "$cleanup"
    echo ${result#base/}
}
doit "0.*"

)

latest.awk以这种方式使用此答案：

doit ()
{
        git rev-list --topo-order --first-parent --children --tags --format=%d \
        | awk -f path/to/latest.awk \
        | sed -n /$1"/,$ { /"$1"/! {p;q} }"
}

测试：

~/sandbox/15$ git lgdo --topo-order --tags
* ecb363d (tag: tag4) tag4
* cd9f402 master
| * 26aa94b (tag: tag3) tag3
|/
* a1b6c1b master
| * 8866091(tag: tag2)tag2
|/
* b5d5283 master
| * 29a4e54(tag: tag1)tag1
|/
* cfcd7dc master
* 6120ab4 (tag: empty)
~/sandbox/15$ doit tag2
29a4e54debae973dfc3955d6663f14d6ade73df9 (tag: tag1)
~/sandbox/15$

（编辑：和

~/sandbox/15$ git checkout tag4
HEAD is now at ecb363d...  tag4
~/sandbox/15$ git describe --tags
tag4
~/sandbox/15$ doit `git describe --tags`
26aa94bad1e37602791c354823cb4a84ff6fc437  (tag: tag3)
~/sandbox/15$

)

（git lgdo作为 的别名git log --graph --decorate --oneline，并且其中的“master”是 make-me-some-commits 助手的提交消息工件）

于 2013-11-21T01:31:13.140 回答
1

你需要一个不同的方法，有多个 repos（毕竟，Git 是一个分布式VCS）：

  • 你描述的一个
  • 一种带有发布标签和发布分支的组合：

您的发布是您在为每个发布创建的发布分支上的最新提交：

0.3.0--(dist) 0.3.0-branch
  |
0.2.0--(dist) 0.2.0-branch
  |
0.1.0--(dist) 0.1.0-branch
  |

这使您可以：

  • 将标签保留在主分支上
  • 通过轻松找到标签之间的提交来推断发行说明（例如，git describe实际上在这里工作）
  • 有一个发布分支专门用于存储您的dist文件夹，但也准备好进行热修复
  • 当这些热修复出现时，在所述发布分支上标记更多提交 ( 0.1.1, 0.1.2, ...)

您需要做的就是在发布分支的顶部创建一个标签，然后将该标签（和分支）推送到一个发布存储库中，该存储库遵循您的部署系统的预期：

 0.3.0
|/
| 0.2.0
|/
| 0.1.0
|/
于 2013-11-16T23:04:49.543 回答
0

如果“叶子”标签只有 1 次来自主分支的提交：

git log --pretty=format:"%d %h %s" | grep '^ (' | grep -A2 '0.3.0' | tail -n1

你得到了包含以前版本标签的行，例如：

 (0.2.0) b5f4956 Commit message

使用 awk 抓取 () 中的标签或 () 之后的 sha1 以继续您的工作。

您grep -A2可以根据自己的情况-A1进行调整。-B2

于 2013-11-18T04:58:47.320 回答
0

如果我理解正确，当你当前的头打开时0.3.0，你想要得到0.2.0，当打开时0.2.0，你想要得到0.1.0，等等。您可以分两步执行此操作：

  1. 获取当前标签使用git describe --tags

  2. 获取按日期排序的标签列表，当前标签后面的行应该是前一个标签

例如：

current=$(git describe --tags)
git for-each-ref --sort=-authordate refs/tags --format '%(refname)' | \
  cut -d/ -f3 | grep -A1 -F $current | tail -n 1

如果这仍然不是您想要的，请告诉我。

于 2013-11-20T07:19:04.837 回答
0

这是迄今为止我能想到的最好的事情：

git tag | sort -n -t. -k1,1 -k2,2 -k3,3 | tail -1

排序只是按照此处所述以理智的方式对它们进行排序。

但是，这并没有真正考虑到您当前HEAD的位置。因此，如果您结帐0.2.0然后运行它，您仍然会得到0.3.0不完全正确的前一个标签。但是，对于我的用例来说，这不是一个大问题，但如果有人能想出一些实际上可以正常工作的东西，我仍然会感兴趣。

于 2013-11-12T10:19:18.840 回答