Question

我们正在尝试采用git-flow实现的successful Git branching model。现在，我们正在开发至少两个发布分支，一个用于最新的稳定版本，另一个用于下一个（“预览”）版本。我不明白为什么所有版本似乎都“线性化”到 master 并在那里标记。为什么不在发布分支中标记发行版？为什么主人呢？或者为什么开发分支而不是使用 master ？

Answer 1

在git-flow模型中，“最新发布”版本实际上映射到master，而“预览版本”映射到git-flow release分支。它从develop分叉，最后在实际发布时合并到master。然后这将成为您的“最新版本”，您通常会使用git-flow hotfix分支修复该版本的错误。这样，您的master始终代表最新发布版本的最稳定状态。

如果你想修复旧版本的bug或者在那里开发任何其他版本，你将在support的适当提交中分叉master分支（你将全部那里创造的版本）。 support个分支仍然是实验性的（according to the docs）并且没有详细记录。但正如您可以从命令行帮助中看到的那样：

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

这些分支刚刚启动，不打算合并回master或develop。这通常很好，因为修复“古代”版本或客户要求在“古代”版本中实现的功能不能或不应该回到master。如果您仍然认为，您希望将修补程序移植到主开发线（由master和develop表示），只需启动hotfix，选择您的更改并完成{ {1}}。

Answer 2

看起来像一个心理模型，过于强调分支。我同意，你可以只标记你发布的提交，而不是将它们合并回主人。

但是，这幅画很漂亮。将所有内容合并回主服务器可以按时间顺序清楚地显示发布，而不是在整个图表中散布版本标记。

我认为这个模型不适用于旧版本中的错误修正。它弄乱了整齐的顺序。

假设我们已发布版本1.0.1及更高版本添加了功能并发布了1.1.0。
我们在1.0.1中发现了一个错误，并希望在两个版本
我们必须在1.1.0之后在master中添加1.0.2然后直接在（或之前）添加1.1.1。

回答你的问题：我认为这是一套规则，在某些情况下会产生一个简单的心理模型。从纯粹的技术角度来看，并非所有规则都有意义，但这并不会使它们变坏。心理模型对人类有益。

Answer 3

我个人认为提到的git-flow过于复杂。

如果您正在使用GitHub，请尝试GitHub flow（如Scott Chacon所述）。

对于多个功能的协作，代码审查尤其有用，您可以使用Commit Status API将其与持续集成解决方案相结合。

更新：有一个新的official website of The GitHub Flow™

更新2 ：GitHub Flow™有一个新的官方（简化）GitHub指南：https://guides.github.com/introduction/flow/

Answer 4

完全同意@Mot。

很高兴听到同样的问题。

我们的团队还被迫寻找比Successfull多的通用分支模型。即正如上面提到的@Mot一样-主要思想是避免引入额外的存储库来支持单独的* .git存储库中的release- *分支，例如，它由kernel.org完成，以实现稳定的发行版。但是kernel.org这样做是为了使下载的大小最小化。

对我来说，将 master 用作 develop 的主线似乎更干净。

在release-* merging model中，与 master 存在一些冲突，并在以后将其标记为

每当主服务器上有一次提交时，使用Git钩子脚本自动将我们的软件构建和推出到生产服务器中

因为finishing (merging and tagging)不是原子交易：

$ 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

我知道Successfull中的版本引入了一些bump-version process 但这不是自动的。

因此，总而言之，我们引入到分支模型以进行发布-*合并和标记的主要区别是： -在创建分支时标记发布 -保留release的分支，以便将来对其进行维护

Answer 5

在我的情况下，我有两个版本的相同软件，基本相同，但每个版本都有一些不同的功能。

所以我创建了两个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个单独的文件夹。并在master中做出共同的改变。然后将其与其他两个版本合并。

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不会混淆。

希望有所帮助。

Answer 6

主分支应始终代表您的生产代码库，因此您始终在生产发布后将代码合并回主数据库。

标记用于“记忆”生产版本中的确切代码，以便您可以稍后返回并在出现问题时分析代码。

理论上，在合并回master之后，如果在发布分支或主分支上标记代码，则无关紧要。我个人更喜欢在发布分支上标记代码，因为这正是构建/发布的代码（假设合并可能出错）。

开发分支概念的问题在于它是单线程的。 Brendan在这个帖子中提到了一个可以用于开发分支概念的策略。

Git-flow和master具有多个并行释放分支

6 个答案: