git分支别名？

我正在研究从starteam到git的转换

目前，在starteam中，我们使用带有特殊名称的“浮动视图”。这些浮动视图的工作原理与别名类似。因此，我们可以指定一个特定的别名来进行签出，我们将得到当前正在进行模型测试的分支

在git中如何实现这一点？ 我们的分支机构基本上就是这样组织的：

这些都是分支机构

master (stable view)
   |  - Branch 2012.05.01
   |          | - Project 1
   |          | - Project 2
   |          | - model [floating view / alias to Branch 2012.05.01]
   |
   |  - Branch 2012.07.11   (these would also have various child views for projects)
   |  - Branch 2012.10.17

（分支机构2012.05.01将在模型测试完成后合并为master）

在运行模型部署的自动化脚本（ant）中，我们只需从名为“模型”的分支进行签出。这样，我们就不必在更改模型测试的分支时更改脚本，而找出模型测试的视图就像找出“模型”分支引用的分支一样简单

在git中有没有类似的方法

编辑：人们在这里感到困惑

我想要一个分支的别名。分支，而不是提交

“Branch 2012.05.01”是指计划于2012.05.01装运的分支机构，但不是指2012.05.01时刻

我想要一个Branch 2012.05.01的别名。Branch 2012.05.01是一个集成分支，不断修改。但我不想将其称为Branch 2012.05.01，我想将其称为“model”。这样，我可以将别名更改为“Branch 2012.07.11”，它将从该分支获取最新的代码，而无需更改任何签出代码脚本

Git不支持分支的别名。 这意味着您必须依赖脚本中的变量来生成model=“branch.2012.10.17”或类似的内容。您的脚本将执行以下操作：

git checkout $model

---

我将剩下的答案留在这里，讨论我们从何而来：

关于分支策略的详细讨论可以在这里找到：

具体来说，请看一下集成分支和发布候选分支的角色。这可能就是你要找的

将git视为获取工作目录快照的东西，而不是文件夹的历史记录

org/book解释了存储历史的有向无环图。所有引用都只是指向其中节点的东西。这应该可以明确您想要如何构建您的工作流程

---

制作一个开始标记-版本2.1。从这里开始创建您的int-version2.1（为了简洁起见，使用numers而不是dates）。任何您开始的工作，都从版本2.1标签开始。将工作合并到int-version2.1中。其他人也会这样做。

如果您需要每个功能的分支，Adam Dymitruk的答案是正确的， 但是，如果您需要保存链接分支特定的状态（基于时间），在不更改它们的情况下，您可以使用git标记

我使用标记来表示每个产品发布的存储状态

请看这里：

您可以按照Greg的建议重命名主分支主干，或者 还可以创建一个主干，该主干是对主节点的符号引用 分支，以便git和svn用户都拥有他们需要的“主”分支 习惯了

git symbolic-ref refs/heads/trunk refs/heads/master

请注意，trunk不是一等公民。如果你结帐的话 执行一个git状态，您将实际处于master状态，但是您可以 在使用分支名称（log、， 合并等）

---

我根本不需要保存特定的状态。我只想通过引用Branch 2012.05.01而不是“Branch 2012.05.01”从Branch 2012.05.01进行签出，因此我的脚本不需要更改。git签出对分支和标记的作用相同。git不支持引用。所有引用都会导致提交。我想我必须找到一个创造性的解决方案。谢谢。：）如果是集成分支，那么我提供链接的工作流应该适合您。添加一个发行候选分支也会有所帮助。您将在那里跟踪已完成的任务或功能。您可以使用它来部署到测试或登台环境中。据我所知，git没有这样的东西，但您可以做的只是将一个“最年轻的”分支实际命名为“model”，然后将其分支用于测试releases@AdamDymitruk，该链接确实有帮助。除了在starteam中，这基本上就是我们正在做的事情，但它没有回答我关于如何为分支创建别名的问题。如上所述，您可以通过符号引用创建别名。谢谢@g_daniel。我不知道该用什么方法来解决这个问题，但我投票决定结束这个问题。这只是给像我一样挣扎的人的一个提示——小心“refs”和“heads”中的单数和复数。如果你漏掉了任何一个，你会得到完全不同的结果。另外，要注意论点的顺序。这与

ln-s

不同，如果你把它们放错了方向，git会很高兴（并且默默地）用一个不存在的符号引用（在这一点上，你最好希望很容易恢复该分支的正确提交散列）来重击真正分支的HEAD ref，不要试图用

git branch-d

删除符号ref。即使对于该操作，它也会被取消引用，因此您实际上会删除源分支，而将引用留在后面（如果您当前已签出该分支，它甚至会允许您这样做）。删除符号引用的唯一“接口”似乎是删除该文件。phils写道：“（在这一点上，您最好希望恢复该分支的正确提交哈希很容易）”恢复提交哈希总是很容易的：

git reflog

@phils“看起来删除符号引用的唯一“接口”是删除文件。”

git symbolic ref-d refs/heads/trunk

也可以正常工作