“开发”分支的趋势逐渐消失

82

我注意到最近在GitHub上一些受欢迎的项目中发现了一些东西，没有develop分支。实际上，GitHub Flow指南也没有提及。根据我的理解，master应该始终保持完全稳定并反映生产。如果开发人员正在研究功能分支，然后master在完成后将其合并到一起，则意味着在一段时间内功能/修复将被合并到其中master，而master分支实际上比生产版本要新。

让团队从中创建功能/修复分支develop，并合并回该分支，然后在下一个版本完全准备发布时，develop将其合并master并创建标签，是否更有意义？想象一下，如果人们直接进入master，并且在生产中报告了一个错误，该错误由于master分支代码库已发生重大变化而变得难以修复。然后，开发人员只需告诉用户要等到下一个版本才能看到问题已解决。

编辑：此问题不同于“分支或不分支”。它专门解决了人们不再使用开发分支的问题以及造成这种情况的原因，因为长期以来，人们一直认为这是最佳实践。

git github

— x
source

11

git启用了许多可能的工作流程。人们不应该期望gitflow或github flow被用于所有项目。

非常有趣的问题。我在nvie.com/posts/a-successful-git-branching-model上工作了多年，不得不说我喜欢它。我最喜欢的是a）主版本是生产中的东西，并且也适用于版本； b）修补程序和功能之间有明显的区别，它们分别在主版本和开发版本上启动和合并。但是，在进行了讨论之后，我开始怀疑它是否使事情变得过于复杂。有什么意见吗？

— Aspasia

1

我讨厌大师是记录生产中东西的概念。如果我们需要知道生产中有什么，我们应该只查询生产，而不要依赖master来准确反映生产中有什么。

— Jim V

52

它来自CI的心态，每天要进行几次集成。

两者都有优点和缺点。

在我们的团队中，我们也放弃了开发分支，因为我们认为它没有提供额外的好处，但有一些缺点。我们已经配置了CI软件（Teamcity）来弥补以下缺点：

启用特定提交的部署。换句话说：我们不部署分支。我们部署一个提交。
我们可以部署主服务器或分支（以修补程序/前缀开头）。

之所以起作用，是因为所有拉取请求都包含潜在的可释放代码，但这并不意味着我们将所有提交都部署在master中。

我们放弃开发分支的主要原因是因为它往往变得太大且太耗时才能看到它实际包含的内容。如果我们过早地部署了某些内容，我们将分支出一个修补程序分支并直接进行部署。

— 埃斯本·斯科夫·佩德森
source

10

与发展分支合作了一年或两年，只是

— 不时

有趣。因此，我假设例如当您发布1.3版时，您在上标记了一个特定的commit master，那么如果您以后在master处于流通状态时出现错误，则可以轻松地从1.3标记中分支出一个修补程序吗？

— ffxsam

5

我想说“开发”的好处在很大程度上取决于您制作的软件类型，部署方式以及是否需要支持多个实时版本。

— axl

1

@ffxsam我们甚至不需要标记，因为我们正在跟踪当前部署的git id。这将在TeamCity中登录，并分支到已部署的dll和Azure管理门户中。因此，除了TeamCity进行的自动标记外，我们没有其他标记的需要。如果您觉得标签适合您，那么您的工作流程会更好，那也可以很好地解决它。但是可以，原则上直接从当前部署的更改分支到一个修补程序分支。

— Esben Skov Pedersen

25

如果您的发布过程很复杂，并且需要认真的发布候选者，那么develop分支的重要性就更大。

例如，假设您正在编写汽车固件的软件。这不是很简单的修复，很可能任何发行版都会在真实硬件上运行全面的非CI /集成测试集。

在这种情况下，在非主分支（例如“开发”）中隔离“发行候选”可能更有意义。这样一来，运行这些测试的团队就可以拥有一个分支来合并功能。

Webapp或其他易于更新的软件没有此限制。

但是，请注意：

github上的许多（大多数？）项目没有这种约束
一个主要的“主人”具有相同的目的
“制作PR与主文件”的工作流程比“针对您在此仓库中不立即知道的分支进行PR”要普遍得多。

— 恩德兰
source

18

我在项目中见过两种哲学，我认为选择只是一个品味问题：

将“ master”指定为生产版本，并在“ develop”分支中进行开发。
在“ master”中进行开发，并拥有一个不同名称的分支来稳定生产版本。如果您的项目一次具有多个发行分支（例如，当前的首选分支是Release-1.8，但您仍在维护Release-1.7），则这更有意义。

两者都是通用的方法，各有利弊。

— 拉里·格里兹（Larry Gritz）
source

我同意你的看法。我们更喜欢拥有发布分支并将其保留到下一个正式发布。如果我们做任何补丁程序，我们签的最后一个版本分支和工作对，然后合并这些补丁程序到主/开发分支

— 约翰尼

究竟。“主人”应该做的主要是语义。正确的基本方法是避免必须保持多个永久存在的分支双向同步，除非您有充分的理由这样做。Git Flow中的“ master”分支只是“ develop”的一个滞后副本，因此它实际上并不重要。反模式允许主开发分支保留从未发布的更改，这是我所见过的令人震惊的普遍做法。上面提到的两种模型都可以防止这种情况，这就是它们起作用的原因。

— John Michelau

7

可以标记生产发布，因此可以始终复制已发布的情况，而无需为此花费整个分支。

如果在无法发布master的瞬间发现了一个严重的bug，那么很容易检出该标签并从那里开始一个新的“ hotfixes-for-release-1.2.0”分支。但这应该很少见。

在我们的Web应用程序中，大多数时候，master都自上一发行版以来发生了变化，但变化不大，因此我们可以简单地从具有此修复程序的master发行新版本。无论如何，它有助于频繁发布。

— 伦科·格里奇
source

5

如果开发人员正在研究功能分支，然后在完成功能后将其合并到母版中，则意味着在一段时间内功能/修复将被合并到其中master，而master分支实际上比生产版本新。

...

想象一下，如果人们直接合并到master中，并且在生产中报告了一个错误，该错误由于master分支代码库已发生重大变化而变得难以修复。

那不是Github Flow。

根据您的链接，这是Github Flow部署/合并过程：

部署

审核拉取请求并且分支机构通过测试后，您可以部署更改以在生产中进行验证。如果您的分支机构引起问题，则可以通过将现有的主服务器部署到生产中来回滚它。

合并

现在您的更改已在生产环境中得到验证，是时候将您的代码合并到master分支中了。

（强调我的）

换句话说，master永远不会超前生产。同样，master由于所有内容在合并到之前都经过审查，测试和部署到生产环境，因此将始终处于稳定，可发布的状态（除了未发现的错误）master。

— 8位树
source

真好！这很有直观意义- master如果推送到生产中的功能分支失败，则始终是您的回滚位置。如果不是，它将合并master并成为新的后备。我喜欢。

— Bill Horvath

1

我看到的问题是，Git / Hub流部署/合并假定一次正在开发/测试/合并/部署一项功能，而根据我的经验，事实并非如此。如果我们一次合并一个功能，则出现回归问题的机会更大-仅在将这些功能合并到母版中并且可能在生产中后才能发现。

需要一种测试多个功能，合并多个功能并部署它们的方法。我一直在使用“捆绑分支”（从master创建的分支，已将可测试的功能分支合并到其中）部署到qa / uat。uat期间的更正仅在功能分支上进行，而这些更正将重新合并到bundle分支中。捆绑包分支的一个子部分获得批准后，只有捆绑包内那些已批准的功能部件才被请求拉至母版，并且该循环是连续的。

我将它与Gitflow一起使用，但正在考虑将其用于GitHub流。一次发布QA / UAT的许多功能似乎很重要。GitHub flow的另一个问题是它假定所有sr开发人员都可以，但并非总是如此。

由于其简化性，我宁愿使用GitHub流。有了类似捆绑的功能，我认为它会更好。捆绑包可能与发布版本相似；但是，我仍然在考虑这一点。

另一个问题是拉取请求过程在合并到主服务器之前最后发生。但是，有时您希望在业务质量检查之前进行代码审查-因此在合并之前

— 戴维·拉蒂
source