因此我通常使用的分支模型类似于以下内容：
http://nvie.com/posts/a-successful-git-branching-model/
但是，我目前正在为每个新版本创建一个新分支。例如，他们正在合并1.0的主人，此时主人员已经死了。当他们需要开始1.1开发时，他们将合并1.0中的1.1。当它们在1.0上完成时，它们会将它部署到生产中，并且该分支将基本上已经死亡。您可以正常执行并合并主要功能的发布分支，并在完成后合并回来。
我能想到的唯一一件事就是这个非常有用，如果你出于某种原因在以前版本之外的其他东西上做了一个修补程序。因为该分支始终存在，您可以返回它并进行更改并提交修补程序。 （或创建一个分支并将其合并回来）。他们正在标记发布等......
这似乎与git的设计方式非常不直观，因为你没有真正的主分支..你的主分支是你从前一个分支合并的最后一个版本。我认为这对于多行开发可能会更好。如果您正在同时处理3个版本。以这种方式使用git会有什么问题吗？
答案 0 :(得分：3)
在让你的发布分支悬空，并将它们合并回master并标记你的发布之间，功能上没有区别。分支和标记都只是指向单个提交的指针。将master分支中的各种提交标记为特定版本的好处是，您没有一堆分支混乱git branch的输出，而是您可以清楚地请求git tag的分支列表1}}。
我怀疑你的同事们认为分支是真实的东西，当它们基本上只是一种特定的标签时（或者更确切地说，标签和分支都只是参考）。
我能想到的唯一一件事就是这个非常有用，如果你出于某些原因在前一个版本之外的其他东西上做了一个修补程序。
您可以轻松签出代码并执行修复。
以这种方式使用git是否会出现任何问题？
不是真的，除了在git branch显示一百个分支时变得非常困惑。无论你如何管理你的分支机构，Git都会工作。
答案 1 :(得分：1)
我假设你有类似的东西：
master
`->1.0----(release)
| |
`-----.-->1.1----(release)
| |
`---->1.2(release)
|
`--->2.0
从技术上讲，它确实没问题。实际上，最新编号的分支是您的主人。但是，它确实打破了约定，它指定master通常是真实代码所在的位置。因此，您可能需要向您打电话的顾问或您外包的任何公司做一些解释。
只要您的分支机构以某种方式很好地合并到最新的分支机构，您就会很好。如果没有，如果有人删除了一个悬挂提交的分支，那么当git进行垃圾收集时，你就失去了这项工作。