我正在尝试确定在git中完成发布分支的最佳方法。我想接受它，以便我们可以在需要时轻松返回。因此，当我合并到开发分支时，我创建了一个标签并将其推送到遥控器，如下所示：
Tag this release
$ git tag -a "v1.6" -m "Release v1.6"
Push to remote
$ git push origin develop --follow-tags
这似乎很有效。但是，我还需要合并到主人，并希望以同样的理由把它带到那里。当我尝试在发布时创建标记时，我显然会遇到冲突。所以，到目前为止，我一直在创建一个像这样的标签：
$ git tag -a "v1.6-master" -m "Release v1.6"
这很好但似乎应该有一种方法来创建一个标签，并能够在你碰巧遇到的任何分支上检查该标签。我觉得我错过了必不可少的东西。
答案 0 :(得分：8)
但似乎应该有一种方法来创建一个标签，并能够在你碰巧遇到的任何分支上检查该标签。我觉得我错过了必不可少的东西。
如果你的意思是你认为你错过了让标签表现得像你描述的那样的方式......你不是。没有一个。所以我想缺少的是完全理解git中标签，分支和提交的关系。
标记是ref - 指向特定提交的指针。分支也一个引用，但它恰好是一个预期以特定方式移动的引用。
人们经常想谈论在特定分支“上”的提交或标签;这在git中并不是真正的东西（与其他版本控制系统不同）。一个分支指向一个提交，并且其他提交可以从该提交到达（通过父指针），并且标记可能指向可以从分支ref到达的提交...但是就这一点而言。如果您的提交拓扑符合某些假设，那么您可以通过说标记指向可从分支到达的提交并且不可从父分支到达来近似“分支上的标记”的概念 - 但你会使用git不关心的概念束（包括“父分支”的概念）。
事实上，当你签出一个标签时，你会把自己置于独立的头状态 - 这意味着你不再在任何一个分支上。
我猜git 可以定义一个指向每个分支一次提交的数据结构，但事实并非如此。
因此，如果您希望在多次提交中使用“version x”标记，那么您正在做的事情（使用命名约定来保持多个标记笔直）是您可以做的最好的。但我也会回应那些暗示“发展中的发布标签”并不像你预期的那样有用的人的观点。
答案 1 :(得分：4)
在开发和主分支上标记发布分支
没有。仅在master上标记版本。 develop分支用于开发，它不稳定。
只有1个提交哈希字符串的1个标记映射，如果一个，两个或更多个分支具有提交哈希字符串，则标记将位于这些分支中。
答案 2 :(得分：2)
使用Git，它是一个提交，而不是分支，被标记。根据您的工作流程， master 和 develop 中可能存在相同的提交。但是，如果您拥有这两个分支，则 master 的（合并）提交可能表示发布。在这种情况下，正确的做法是将合并提交标记为 master 。
答案 3 :(得分：0)
听起来与git flow非常相似。你有没看过它？
前两个是原始分支模型。最后一个是您可以在您最喜欢的Linux存储库中找到的当前开发。它为旧版本添加了支持分支，显然需要支持。
答案 4 :(得分：-1)
Git标签和分支是非常轻量级的概念，唯一的（仅）（ 仅 ）模型应该具有git历史记录祖先dag和引用（标签，分支，你有什么）到当前特定的提交。
为什么还要标记一个提交，你可以在没有标记的情况下（更多，实际上）可靠地找到提交？您是在从开发合并到v1.6的最后一次提交之后：
merge=`git rev-list v1.6 --grep="Merge branch 'develop'" --merges -1`
会让你合并，
git log -1 $merge^2
将为您提供合并提交。