Git-flow和主分支与多个平行发布分支

Question

我们正试图采用git-flow实现的Git分支模型。现在，我们正在至少两个发布分支上工作，一个是最新稳定版的发布分支，另一个是下一个（“预览”）版本的发布分支。我不明白的是为什么所有版本似乎都要“线性化”到master，并在那里标记。为什么不在它们的发布分支中标记版本？为什么要使用master？或者为什么要有一个develop分支而不使用master？

- Mot

Answer 1

在git-flow模型中，你的“最新发布”版本实际上映射到master，而你的“预览发布”则映射到git-flow的release分支。它是从develop分支派生出来的，并在实际发布时合并到master分支中。然后这将成为您的“最新发布”，通常只会使用git-flow的hotfix分支修复该发布版的错误。通过这种方式，你的master分支始终表示你的最新发布版本的最稳定状态。

如果你想要为旧版本修复错误或进行其他开发工作，你可以从master中的适当提交派生一个support分支（在那里你将拥有所有已创建的版本）。根据文档（见链接），support分支仍处于实验阶段，文档也不够完善。但是，正如你可以从命令行帮助中看到的那样：

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

这些分支只是刚开始，并且不打算合并回master或develop。这通常没有问题，因为修复“古老”的版本或实现客户要求在“古老”的版本中的功能时，不能或不应该返回到master。如果你仍然想将一个修复移植到你的主开发分支（由master和develop表示），只需要开始一个hotfix，挑选你的更改并完成hotfix。

- mstrap

---

这并不涉及从测试到QA再到生产过程中的缓慢流程。可能会有两个（甚至更多，但现在我们只说两个）发布分支处于开放状态，每个都处于不同阶段的管道中，并且每个都需要允许修复在测试中发现的错误。 develop 分支将是功能累积的地方，用于尚未创建分支的发布。 在这种情况下，发布 n-2 上的修复最终将合并到 develop 中，但至少按照标准的 Git 流程，它将跳过发布 n-1。这将导致 n-1 上的回归，在发布 n 上得到修复。 - Brendan

为什么不保留发行分支，一旦创建了更新的版本分支，较旧的分支就会演变成“支持”分支？ - lkanab

为什么发布分支要从develop“fork”，而不是仅仅从develop“分支”出来？ - Sandra K

gitflow-avh 看起来是原始 gitflow 的一个维护（即非死亡）分支。git flow support 没有标记为实验性。 - Timo Verhoeven

Answer 2

看起来这主要是一个心智模型，但分支有些强调过多。我同意，你可以只标记发布的提交而不将它们合并回主分支。

不过图片还是很漂亮的。将所有内容合并回主分支，清晰地显示了按时间顺序发布的版本，而不是在图形中散布版本标签。

我认为这个模型对于旧版本的错误修复不适用，它会破坏整齐的排序。

1. 假设我们发布了版本1.0.1，然后添加了新功能并发布了1.1.0。
2. 我们发现1.0.1中存在一个错误，并希望在两个版本中修复它
3. 我们必须在主分支中将1.0.2添加到1.1.0之后，然后直接添加（或之前）1.1.1。

回答你的问题：我认为这是一组规则，在某些情况下可以构建出简单的心智模型。虽然并非所有规则从纯技术角度来看都有意义，但那并不代表它们不好。心智模型对人类有益。

- Sarien

---

“支持”分支是为较旧版本中的错误修复而设计的，虽然仍被标记为“实验性”。 - mstrap

Answer 3

完全同意@Mot的观点。

听到相同的问题很好。

我们的团队也在寻找比Successfull更通用的分支模型。 即如@Mot上面提到的-主要思想是避免在单独的*.git repo中为支持release-*分支引入额外的存储库，正如kernel.org为稳定版本所做的那样。但我想kernel.org这样做是为了最小化下载大小。

对我来说，将master作为develop的主线更加清晰。

此外，在发布-*合并模型中，与master的冲突以及后续标记存在一些问题，

使用Git hook脚本，每次在主分支上提交时自动构建和部署我们的软件到生产服务器

由于完成（合并和标记）不是原子事务：

$ 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 钩子启动自动版本控制支持的构建：

$git describe --tags --long >.ver

然后，可能会出现错误的版本：

$ git merge --no-ff release-1.2

我知道在成功的版本控制中，会引入一些版本升级流程，但这不是自动的。

因此，总结一下我们为发布-*合并和标记引入的分支模型的关键差异： - 在创建其分支时标记发布 - 保留发布的分支以便将来维护

- mdn

Answer 4

在我的情况下，我有同一软件的两个版本，基础是相同的，但每个版本都有一些不同的功能。因此，我创建了两个"工作树"，也就是在主分支旁创建了两个相关的长期运行的分支。

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

希望这可以帮助到您。

- vaheeds

Answer 5

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

如果您使用GitHub，请尝试GitHub flow（由Scott Chacon描述）。

它特别适用于多个功能的协作，代码审查，并且您可以使用Commit Status API将其与您的持续集成解决方案相结合。 更新：有一个新的The GitHub Flow™ 官方网站。 更新2：The GitHub Flow™ 有一个新的官方（简化版）GitHub指南：https://guides.github.com/introduction/flow/。

- Haralan Dobrev

---

GitHub工作流仅适用于非以发布为中心的情境： git-flow工作流程主要围绕“发布”设计，但我们没有真正的“发布”，因为我们每天部署到生产环境——通常一天会有几次。 - Remi Mélisson

我想补充一点，git-flow在有维护版本的以发布为中心的情境中并不是很适用。例如，在1.3.0发布之后会发生1.2.1发布的情况，这时会出现工作时间顺序的异常，它似乎无法合并到'master'分支。 - Ken Williams

正如mstrap的回答所述，@KenWilliams，这就是“support”分支的作用。但你说得对，这确实是一个异常情况，这样的发布应该合并回“master”，而“master”应该包含所有生产发布版本，这是我理解的。 - beatngu13

Answer 6

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

标记用于“记住”进入生产发布的确切代码，以便稍后可以分析代码（如果出现问题）。

理论上，如果您在发布分支或合并回主分支后在主分支上标记代码，这都不重要。我个人更喜欢在发布分支上标记代码，因为这正是进入构建/发布的代码（假设合并可能出现问题）。

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

- Bernie Lenz

---

如果您同时维护多个版本，例如v1.0、v1.1、v1.5，那么“生产代码库”是什么？ - Thomas S.

我正在谈论维护多个发布版本，而不是未来的版本。 - Thomas S.

我猜你想看看之前发布的代码，比如v0.9版本？在这种情况下，你需要查看用于该发布的分支。我发现在部署到生产环境时给代码库打标签也很有帮助，这样你就可以使用标签来查看以前的版本。你可以在发布分支上或合并后的主分支上打标签。 - Bernie Lenz

你好像不理解我的意思。你能不能想象在一些公司里会维护多个发布版本？比如微软，他们也会为Windows 7、8、8.1和10提供更新，那为什么其他公司不行呢？ - Thomas S.

这是正确的，Thomas。该模型适用于在特定时间点具有单个生产发布的产品，例如网站等。我还将此模型用于移动构建，例如Android和iPhone，其中构建被参数化以生成Android或iPhone构建（或两者），并使用相同的版本号。 我很想知道您对如何为在任何给定时间点都具有多个实时版本的产品进行构建模型结构的看法，可能会共享一些组件并且某些组件不同。请告诉我们... - Bernie Lenz