如何将 "git describe" 与 dev 和 main（带标签）分支一起使用
How to use "git describe" with dev and main (with tags) branches
我正在尝试设置一个存储库，好像将来会有协作，但现在只有我在使用它。
我打算使用三个分支层
- main：一个始终工作的发布分支，其中每个提交都是来自拉取请求（受保护）的标记合并提交。
- dev：开发发生的地方，包括小的变化。
- feature分支：针对larger/grouped变化，合并到dev
当需要发布时，我计划让开发人员进入该版本存储库所需的状态，然后拉取请求 dev -> master 并使用 GitHub 操作进行构建检查和根据某些规则确保状态有效。然后当拉取请求合并时，另一个工作流将根据更多规则（即 v1.0.0 等）标记发布。
到目前为止还不错，看起来像这样：
------------------D (main: v1.0.2)
-----A------B---C/ (dev, C is commit that was used for pull request)
\E---F/ (my-feature, example feature branch)
问题是在我的构建系统中有几个地方我想使用：
git describe --match v*.* --dirty --always
目的是在 D 之后进行的下一次提交类似于：
v1.0.2-1-g7259g4f
如果一切都在 main 上完成，情况就会如此；但是，由于此分支设置和下一次提交可能发生在 dev（或新功能分支）上，因为它没有直接返回 D 的路径，describe 将根据 [=69= 之间的先前共同祖先进行报告]，如果这在历史上足够早，它也可能什么都不是（如果使用 --always 则只给出一个提交散列）。这意味着 describe 仅当 运行 仅在 main 上时才会产生有意义的结果（在我的用例中），而我需要它对所有分支“工作”以便在发布后发生的每个提交version 合并到 main 中并在 main 中标记是相对于最后一个标记描述的。
这种方式有一种普遍的进步感：
- 对于 dev/feature 分支构建：哦，这个构建是基于版本 1.0.2，它的 24 次提交使用这个最新的哈希值，本地仓库有未提交的更改，无论哪个确切的分支它打开，因为它可以单独添加或从提交哈希中辨别出来）。
- 对于主要构建：这是发布版本 v1.0.2、v1.0.3 等的构建
到目前为止，我想到了两个解决方法：
在main（此处为D）中的pull request merge commit被标记后，立即将其合并回dev中，为describe:[=20=建立共同的祖先和向后路径]
------------------D (main: v1.0.2)
-----A------B---C/\G--(dev, G merge back, will describe like v1.0.2-1-g723...)
\E---F/ (my-feature, example feature branch)
它有效，但感觉很尴尬，因为合并本质上只是针对标签。
将 dev 中用于拉取请求的每个提交标记为 dv1.0.2 之类的内容。这样，在 dev 和派生分支上提交的所有后代将按照我的意愿做出反应，只用 'dv' 代替，而 main 中的合并提交仍然只是 'v'。实际上，这将起作用并允许轻松地识别构建，它只是添加了一个额外的标签 step/more 工作流作业并且看起来不那么干净。
是否有更好的方法来实现 git describe 的这种用法，或者我是否无法使用上述方法之一？
为了后代，我会将 joanis 的评论变成答案。
虽然有很多方法可以管理 git 历史记录，但最终对我有用的（为了能够如上所述使用 git describe）是处理我的分支，这样当发布准备就绪，由合并到 main 表示，dev 和任何派生分支都汇聚到同一点，这样 dev 和 main 的负责人之后立即指向同一个提交。
这可以通过执行以下操作来完成（假设 dev 是源分支）：
git checkout maingit pull（如果需要）git merge dev --no-ffgit tag vX.Y.Z（任何你想要的标签，如果有的话）- 'git 结帐开发`
git merge main --ff-only
当然，main 可以替换为您想要的任何分支（例如 release、staging、2.01 等）。
在 next 合并到 main 之后，这创建了一个主观上不错的 git 历史视图，每个开发周期都有明确的界限，如 joanis 所述：
在下一次合并之前，dev 上的以下更改将出现在与 main 相同的“轨道”上。
我正在尝试设置一个存储库，好像将来会有协作，但现在只有我在使用它。
我打算使用三个分支层
- main：一个始终工作的发布分支，其中每个提交都是来自拉取请求（受保护）的标记合并提交。
- dev：开发发生的地方，包括小的变化。
- feature分支：针对larger/grouped变化，合并到dev
当需要发布时，我计划让开发人员进入该版本存储库所需的状态，然后拉取请求 dev -> master 并使用 GitHub 操作进行构建检查和根据某些规则确保状态有效。然后当拉取请求合并时，另一个工作流将根据更多规则（即 v1.0.0 等）标记发布。
到目前为止还不错，看起来像这样：
------------------D (main: v1.0.2)
-----A------B---C/ (dev, C is commit that was used for pull request)
\E---F/ (my-feature, example feature branch)
问题是在我的构建系统中有几个地方我想使用：
git describe --match v*.* --dirty --always
目的是在 D 之后进行的下一次提交类似于：
v1.0.2-1-g7259g4f
如果一切都在 main 上完成，情况就会如此；但是，由于此分支设置和下一次提交可能发生在 dev（或新功能分支）上，因为它没有直接返回 D 的路径，describe 将根据 [=69= 之间的先前共同祖先进行报告]，如果这在历史上足够早，它也可能什么都不是（如果使用 --always 则只给出一个提交散列）。这意味着 describe 仅当 运行 仅在 main 上时才会产生有意义的结果（在我的用例中），而我需要它对所有分支“工作”以便在发布后发生的每个提交version 合并到 main 中并在 main 中标记是相对于最后一个标记描述的。
这种方式有一种普遍的进步感：
- 对于 dev/feature 分支构建：哦，这个构建是基于版本 1.0.2，它的 24 次提交使用这个最新的哈希值，本地仓库有未提交的更改，无论哪个确切的分支它打开，因为它可以单独添加或从提交哈希中辨别出来）。
- 对于主要构建：这是发布版本 v1.0.2、v1.0.3 等的构建
到目前为止，我想到了两个解决方法：
在main（此处为D）中的pull request merge commit被标记后，立即将其合并回dev中，为
describe:[=20=建立共同的祖先和向后路径]------------------D (main: v1.0.2) -----A------B---C/\G--(dev, G merge back, will describe like v1.0.2-1-g723...) \E---F/ (my-feature, example feature branch)它有效，但感觉很尴尬，因为合并本质上只是针对标签。
将 dev 中用于拉取请求的每个提交标记为
dv1.0.2之类的内容。这样，在 dev 和派生分支上提交的所有后代将按照我的意愿做出反应，只用 'dv' 代替，而 main 中的合并提交仍然只是 'v'。实际上，这将起作用并允许轻松地识别构建，它只是添加了一个额外的标签 step/more 工作流作业并且看起来不那么干净。
是否有更好的方法来实现 git describe 的这种用法，或者我是否无法使用上述方法之一？
为了后代，我会将 joanis 的评论变成答案。
虽然有很多方法可以管理 git 历史记录，但最终对我有用的（为了能够如上所述使用 git describe）是处理我的分支，这样当发布准备就绪，由合并到 main 表示，dev 和任何派生分支都汇聚到同一点，这样 dev 和 main 的负责人之后立即指向同一个提交。
这可以通过执行以下操作来完成（假设 dev 是源分支）：
git checkout maingit pull（如果需要）git merge dev --no-ffgit tag vX.Y.Z（任何你想要的标签，如果有的话）- 'git 结帐开发`
git merge main --ff-only
当然，main 可以替换为您想要的任何分支（例如 release、staging、2.01 等）。
在 next 合并到 main 之后，这创建了一个主观上不错的 git 历史视图，每个开发周期都有明确的界限，如 joanis 所述：
在下一次合并之前，dev 上的以下更改将出现在与 main 相同的“轨道”上。