在git中，创建与已删除分支同名的标记是个坏主意吗？

我有一个带有git分支模型的项目，该模型大致遵循nvie的git-flow的模型。

我们的发行分支以SemVer格式命名，例如v1.5.2

一旦发布分支允许生产，我们就关闭该分支，方法是将其合并到master中，应用标签，然后删除该分支。

当我们立即删除发布分支时，我们一直在使用相同的标识符来标记分支，例如 v1.5.2

这是我们用于关闭发布分支的命令：

$ git checkout master
$ git merge v1.5.2
$ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc"
$ git branch -d v1.5.2
$ git branch -dr origin/v1.5.2
$ git push origin :v1.5.2
$ git push
$ git push --tags

这似乎在大多数情况下都可行，但是在git repo的另一个实例（例如，另一个开发机器或暂存环境）具有v1.5.2分支的本地检出的情况下，这会引起问题。

该git push origin :v1.5.2命令将删除远程分支中的分支，但不会在所有存储库中删除分支的本地版本（如果存在）。

v1.5.2在这些存储库中尝试签出时，这会导致模棱两可的引用：

$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.

如果不对分支使用不同的语法（例如release-v1.5.2或），是否可以避免这种情况v1.5.2-rc？

还是不可避免，因此创建与已删除分支同名的标签从根本上是一个坏主意？

如果您绝对希望保留此命名方案，则可以：

确定您不在乎这些警告

也就是说，如果您对以下事实感到满意：

• git checkout <ref>将检查refs/heads/<ref>过refs/tags/<ref>（见git的结帐）
• 其他命令将使用refs/tags/<ref>over refs/heads/<ref>（请参阅gitrevisions）

例如，在此测试存储库中，v1.5.2分支指向提交B，但是v1.5.2标记指向提交A。

% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A

git checkout 首选分支名称：

% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B

但git log将使用标签名称：

% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A

这可能会造成混淆。

训练人们在看到新标签时删除其本地分支

这可能很难/尴尬，具体取决于组织的规模。

围绕“ git pull”和“ git fetch”编写一个包装器

也就是说，编写一个包装程序，以检查是否有任何标签遮盖了分支名称，并警告（或删除）这些分支。这听起来很痛苦，并且如果当前检出阴影分支，这可能是不希望的。

不幸的是，听起来这是解决此问题的最简单方法，可能是更改命名分支的方式。您发布的链接对标签和分支使用了不同的命名方案：如果您已经大部分遵循该方法，则采用其命名方案可能是最简单的解决方案。

您可以使用全名来明确指定要分支还是标记：

 git checkout refs/heads/v1.5.2

要么

git checkout refs/tags/v1.5.2