1

情况：我们公司创建了使用 Hudson 从 git 存储库中的代码构建的软件版本。有时，由于试用期已过，我们需要重现以前版本的构建。这带来了一个问题，因为我们需要找到与该软件版本对应的代码版本。我们的开发人员不使用标签或分支工作，因为它不符合我们的工作风格。

作为这个问题的解决方案，我认为我们应该在每次构建成功时包含一个自动标记系统。

我想到的工作流程如下（在我们的构建机器上执行）：

  1. 如果进行了任何本地更改，则丢弃所有本地更改：git checkout . git clean -df
  2. 获取最新版本：git pull
  3. 转到所需的版本git checkout .或git checkout <tag>
  4. 构建软件
  5. 如果成功：标记当前版本，并将标记推送到存储库：git tag -m "automated tag" versionXXX git push --tags

关于这种工作方式，我有 3 个问题：

  1. 这种工作方式有什么明显的缺陷吗？（含糊，我知道 - 对不起）
  2. 对于这个用例，使用带注释的标签比轻量级标签有什么优势吗？大多数帖子都推荐带注释的标签，但我并没有真正看到附加值，尤其是对于这个用例。
  3. 我们的软件由多个模块组成，每个模块都有自己的 git 存储库。其中一些模块几乎没有更新。有很多标签指向同一个提交有什么缺点吗？
4

1 回答 1

2

1）这种工作方式有什么明显的缺陷吗？（含糊，我知道 - 对不起）

没有。

2）对于这个用例，使用带注释的标签比轻量级标签有什么优势吗？

不，如果您没有在标签消息中添加任何有意义的内容，那么一开始就创建一个没有任何意义。没有真正的缺点（它们几乎不会占用任何空间）。如果你从构建中得到任何结果，你可以把它们放在标签注释中（除非你有其他的日志机制，无论如何都要检查），例如警告的数量，或者类似的东西。

3）有很多标签指向同一个提交有什么缺点吗？

不，除了可能会弄乱标签名称空间（标签名称必须对 repo 唯一）之外，没有问题。如前所述，它们几乎不使用任何空间。如果冗余标签有任何问题，您可以实施如下策略：如果先前构建的标签指向我现在要标记的同一提交，则不要标记它。如果您查找特定版本的标签，请在您指定的版本之前使用最新版本的标签。（这只有在查找是自动化的情况下才可行；否则只需重新标记提交。）

于 2013-01-08T15:23:06.830 回答