140

我目前正在通过阅读Pro Git学习使用Git。现在，我正在学习分支和标签。我的问题是什么时候应该使用分支，什么时候应该使用标签？

例如，假设我为项目的1.1版创建了一个分支。完成并发布此版本后，是否应该离开分支以标记发布版本？还是应该添加标签？如果添加标签，是否应该删除版本分支（假设它已合并到master或其他分支中）？

— 编码大师
source

161

简而言之：最佳实践是分支，经常合并并始终保持同步。

关于将代码保持在与master分支不同的分支中，有非常明确的约定：

您即将实施重大或颠覆性变更
您将要进行一些可能无法使用的更改
您想尝试一些不确定会起作用的东西
当您被告知要分支时，其他人可能需要在母带中做一些事情

经验法则是分支出来之后，您应该与master分支保持同步。因为最终您需要将其合并回主服务器。为了避免合并时发生巨大的复杂冲突，您应该经常提交，合并。

遵循的良好做法

一个成功的Git分支模型由文森特Driessen的好的建议。如果此分支模型吸引您，请考虑将流扩展到git。其他人则对流量发表了评论。

标记惯例

如您所知，Git为您提供了诸如1.0-2-g1ab3183之类的提交标识符，但它们不是标签！标记是使用git标记完成的，并且使用git标记创建的标记是git describe创建的提交标识符的基础。换句话说，在Git中，您不标记分支。您正在标记提交。正确地说，标记只是指向提交的带注释的指针。

让我们看一下证明它的实际例子，

                        /-[v1.0]
                       v
---.---.---.--- S ---.--- A <-主
                         \ 
                           \ -.--- B <-测试

让我们提交“ S”，即由标签“ v1.0”指向的提交。此提交既在分支“ master”上，也在分支“ test”上。如果在提交“ A”（“ master”分支的顶部）上运行“ git describe ”，则会得到类似的信息v1.0-2-g9c116e9。如果在提交“ A”（也称为“测试”分支）的顶部运行“ git describe”，则将得到类似的东西v1.0-2-g3f55e41，默认的git-describe配置就是这种情况。请注意，此结果略有不同。 v1.0-2-g9c116e9表示我们正在提交，SHA-1 id为已排序9c116e9，tag之后为2次提交v1.0。没有标签v1.0-2！

如果您希望标记仅出现在分支“ master”上，则可以在“ test”分支的分支点之后创建新的提交（例如，仅更新GIT-VERSION-FILE中的默认/后备版本信息）。如果使用“ v1.0.3”标记“测试”分支上的提交，则仅在“测试”中可见。

参考文献

我发现了很多有用的博客和帖子可供学习。但是，经过专业说明的是罕见的。因此，我想推荐一个帖子- @nvie 成功的Git分支模型。我借用了他的插图：）

在此处输入图片说明

— 尤苏波夫
source

4

1.0-2-g1ab3183是一个由git describe从git可用信息中构造的标识符，但是称它为git标识符有点太多。Git通过SHA哈希识别；标签和分支是git有助于跟踪的人为构造。这样，当您认为某人将来某天希望找到提交的便捷书签时，请做一个标签。

— mabraham 2014年

2

git宇宙中多维性的绝妙例证。美丽。谢谢

— Tope

值得注意的是，许多项目不需要此图中所示的某些通道。有些项目只需要这里所谓的开发和功能。对于可以随意部署的Web应用程序通常是这样。

— usr

37

如果您同时具有2个不同版本的存储库，则使用分支。标签是一种在存储库中标记时间点的方法。

您应该添加标签来标记已发布的版本。如果随后需要对该版本进行错误修复，则可以在标签处创建一个分支。

您只想删除已经合并回HEAD [或其他分支]的分支。

— gam3
source

3

哦...我假设您的意思是分支已合并到另一个分支，例如master。每次结帐时HEAD都会移动，对吗？

— Code-Guru 2012年

HEAD通常指向分支（除非您处于分离的HEAD模式），因此HEAD随它指向的分支一起移动

— LoicAG

Git分支和标记最佳实践

遵循的良好做法

标记惯例

参考文献