Git-如何在新的发布标签/版本下绑定多个MRs的更改？

我当前在GitLab中处理和解决问题的工作流如下（我将在之后定义问题）：

通过发布API使用连接的发布标签创建里程碑

将问题与里程碑联系起来

通过GitLab UI自动创建连接到问题的MRs和分支（用于一致命名）

作出改变

合并MR并自动关闭问题

这里的问题是如何处理标签。它绝对不是更新工作流程的一部分，因为当我创建它时，它会在我进行更改之前获得最新的主文件

但是如何将所有更改绑定到发布版本下呢？

---

一个想法是将所有更改合并到一个发布分支中，并将该分支连接到标记，但问题是GitLab没有关闭问题，无论是它们的MRs与发布分支合并，还是在发布分支合并时。这是一个问题，因为里程碑概述将变得多余。

标记实际上并不打算以这种方式工作。通常，它们用于标记回购历史上具有特定功能的一个点。这通常是发布名称/编号或版本号

在将MR合并到master之后，如果您将标记移到末尾，那么看起来您的工作流程也会起作用

---

您可以阅读git文档中的标记。

好的，这让您现在更清楚标记的意义，谢谢。这是我第一次用GitLab创建工作流。你对我以前写的想法有什么看法？标记里程碑更新的最后一次提交意味着我已经将所有新更改合并到主节点中。我想有一些工作流程，其中主版本在合并后生成，生产版本得到更新。在这之后创建一个标签听起来不是很流畅。或者这是一种常用的方法？是的，这与我在团队中所做的非常接近。我们的工作是在功能分支中完成的，然后当我们决定哪些分支/用户故事将成为下一版本的一部分时，我们将功能分支合并到一个“发布”分支中，我们的QA将对其进行批准/拒绝。如果批准，我们将发布分支合并到master中，然后标记它。对我们来说效果很好。这样，说明中与MRs相关的

关闭#1

问题将不会自动关闭，或者不会自动关闭？我想你应该手动关闭它们以获得正确的里程碑概述？该功能不应该改变。您可以在合并请求中以这种方式关闭问题，无论您使用何种工作流，或者是否使用标记和里程碑。