我们正在尝试采用由git-flow实现的成功的Git分支模型。现在，我们至少在两个分支上工作，一个用于最新的稳定版本，另一个用于下一个（“预览”）版本。我不明白的是为什么所有发行版似乎都对母版“线性化”并在那里标记。为什么不在发行分支中标记发行？为什么要高手呢？还是为什么要开发分支而不使用master？
我们正在尝试采用由git-flow实现的成功的Git分支模型。现在，我们至少在两个分支上工作，一个用于最新的稳定版本，另一个用于下一个（“预览”）版本。我不明白的是为什么所有发行版似乎都对母版“线性化”并在那里标记。为什么不在发行分支中标记发行？为什么要高手呢？还是为什么要开发分支而不使用master？
Answers:
在git-flow模型中，“最新发布”版本实际上映射到master，而“预览版本”则映射到git-flowrelease分支。它是在实际发布发生时从其中分叉develop并最终合并到master其中的。然后，这将成为您的“最新版本”，并且通常您将使用git-flowhotfix分支仅修复该版本的错误。这样，您master始终代表着最新发行版本的最稳定状态。
如果要修复较旧版本的错误或在此处进行任何其他开发，则应support从相应的提交派生一个分支master（您将在此创建所有版本）。support分支机构仍处于试验阶段（根据docs），并且记录不充分。但是从命令行帮助中可以看到：
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
这些分支只是开始而不是打算合并到masternor develop。这通常很好，因为不能或不应该使用“古老”版本的修复程序或客户要求在“古老”版本中实现的功能master。如果您仍然认为，您想将修补程序移植到您的主要开发线（由master和表示develop），只需开始a hotfix，选择您的更改并完成hotfix。
git flow support未标记为实验性。
看起来主要是一种心理模型，对分支机构的重视程度过高。我同意，您可以标记发布的提交，而不是将它们重新合并到主提交中。
图片很漂亮。将所有内容合并回master可以按时间顺序清楚地指示发布，而不是在整个图上散布版本标签。
我认为该模型不适用于较早版本中的错误修复。它弄乱了整洁的顺序。
回答您的问题：我认为在某些情况下，这是一组规则，可以简化心理模型。从纯粹的技术角度来看，并非所有规则都有意义，但这并不会使它们不好。心理模型对人类有益。
support分支专为旧版本中的错误修复而设计，尽管仍被标记为“实验性”。
我个人认为上述git-flow过于复杂。
如果您使用的是GitHub，请尝试GitHub flow（如Scott Chacon所述）。
这对于在多个功能上进行协作，进行代码审阅特别有用，并且您可以使用将其与持续集成解决方案结合使用Commit Status API。
更新：GitHub Flow™有一个新的官方网站
更新2：针对GitHub Flow™有一个新的官方（简化版）GitHub指南：https : //guides.github.com/introduction/flow/
master，这是工作时间顺序的异常。
就我而言，我有两个版本的同一软件，其基本知识是相同的，但是每个版本都有一些不同的功能。
因此，我创建了两个worktree，这意味着在主数据库旁边创建两个相关的长期运行分支。
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
然后我有：
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
有一个存储库，但是对于上面的每个分支，我都有3个单独的文件夹。并进行主人的共同变更。然后将其与其他两个版本合并。
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
每个版本的特定更改也将放在相应的文件夹中，每个项目的工作都被隔离，并且不会混淆IDE。
希望能有所帮助。
完全同意@Mot。
很高兴听到相同的问题。
我们的团队还被寻求比成功一号更通用的分支模型。例如，上面提到的@Mot-主要思想是避免引入额外的存储库来支持单独的* .git存储库中的release-分支，例如，它是由kernel.org完成的，用于稳定发行版。但是kernel.org这样做是为了使下载大小最小化。
对我来说，将主人作为开发的主线似乎更干净。
在release- *合并模型中要掌握和随后对其进行标记的想法也存在一些冲突
每当主服务器上有提交时，使用Git钩子脚本自动将我们的软件构建和推出到生产服务器
原因完成（合并和标记）不是原子事务：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
如果git hook开始使用自动版本控制来构建：
$git describe --tags --long >.ver
那么可能会为以下内容构建错误的版本：
$ git merge --no-ff release-1.2
我知道，成功版中的版本控制引入了一些凹凸版本处理， 但这不是自动的。
因此，总而言之-我们引入的分支模型的主要区别在于-*合并和标记：-在创建其分支时标记发行版-保留发行版的分支以便将来维护它们
master分支应始终代表您的生产代码库，因此，您始终在生产发布后立即将代码合并回master。
标记用于“记住”生产版本中的确切代码，因此您稍后可以返回并分析代码，以防出现问题。
从理论上讲，合并回master之后，在发布分支还是master分支上标记代码都没关系。我个人更喜欢在release分支上标记代码，因为这恰好是构建/发行版中使用的代码（假设合并可能会出错）。
开发分支概念的问题在于它是单线程的。Brendan在此主题中提到了可以用于开发分支概念的策略。