develop分支。实际上，GitHub Flow指南也没有提及。据我了解，master应该始终完全稳定并能反映生产情况。如果开发人员正在开发功能分支，然后在完成后将其合并到master中，则意味着一段时间内功能/修复程序已合并到master中，而master分支实际上比生产版本新。让团队从
develop创建功能/修复分支，合并回去，然后在下一个版本完全准备发布时，将develop合并到master中，这会更有意义创建了吗？想象一下，如果人们直接合并到master中，并且由于master分支代码库已发生重大变化，则在生产中报告了一个难以修复的错误。然后，开发人员只需告诉用户要等到下一个版本才能看到问题已解决。编辑：这个问题不同于“分支或不分支”。它专门解决了人们不再使用开发分支的问题以及造成这种情况的原因，因为长期以来，人们一直认为这是最佳实践。
#1 楼
它来自CI的心态，每天要进行几次集成。两者都有优点和缺点。
在我们的团队中，我们也放弃了development分支，因为我们认为它没有提供额外的好处，但有一些缺点。我们已经配置了CI软件（Teamcity）来弥补以下缺点：
启用特定提交的部署。换句话说：我们不部署分支。我们部署一个提交。
我们可以部署以修补程序/前缀开头的主分支或分支。
之所以起作用，是因为所有拉请求都包含潜在的可释放代码，但这并不意味着我们将所有提交部署在master中。如果我们过早地部署了某些内容，我们将分支出一个修补程序分支并直接进行部署。
评论
与发展分支合作了一年或两年，只是为了不时地将它合并成大师，我可以说：阿们，放弃那件事：]
–stijn
16 Mar 7 '16 at 21:06
有趣。因此，我假设例如当您发布1.3版时，您在master上标记了一个特定的提交，因此，如果稍后当master处于flux状态时出现错误，您可以轻松地从1.3标记分支出一个修补程序吗？
–ffxsam
16 Mar 7 '16 at 22:06
我想说“开发”的收益在很大程度上取决于您所制作的软件类型，其部署方式以及是否需要支持多个实时版本。
–axl
16 Mar 8 '16 at 0:30
@ffxsam我们甚至不需要标记，因为我们正在跟踪当前部署的git id。这将在TeamCity中登录，并分支到已部署的dll和Azure管理门户中。因此，除了TeamCity进行的自动标记之外，我们没有其他标记的需要。如果您觉得标签适合您，那么您的工作流程会更好，那也可以很好地解决它。但是可以，原则上直接从当前部署的更改分支到一个修补程序分支。
– Esben Skov Pedersen
16 Mar 8 '16 at 7:05
#2 楼
如果发布过程很复杂，并且需要认真的发布候选者，那么开发分支的重要性就更大。例如，假设您正在编写汽车固件的软件。这是不容易修复的，很可能任何发行版都可以在真实硬件上运行全面的非CI /集成测试。在非主分支（例如“开发”）中隔离“候选发布”。这样一来，您的团队就可以在运行这些测试的分支中合并功能。Webapp或其他易于更新的软件没有此约束。
但是，请注意：
github上的许多项目（大多数？）都没有这种约束
主要的“主人”具有相同的目的
“制作PR vs master”比“针对您在此仓库中不立即知道的分支机构进行公关”要普遍得多。
评论
这不是仅使用标签来解决的吗？不必始终使用master的负责人，您可以部署使用最新版本标记的提交（静态v x.x.x标签和/或您将移动到master上最新的“批准的”提交的最新标签）。基本上，这就是程序包管理器的工作方式。
– booshong
20年9月4日下午1:00
#3 楼
我在项目中见过两种理念，我认为选择只是个口味问题：将“ master”指定为生产版本，并在“ develop”中进行开发分支。
在“ master”中进行开发，并拥有一个不同名称的分支来稳定生产版本。如果您的项目一次具有多个发行分支（例如，当前首选的发行分支是Release-1.8，但您仍在维护Release-1.7），则这更有意义。 ，各有利弊。
评论
我同意你的看法。我们更喜欢拥有发布分支，并保持这些分支直到下一个正式发布。如果我们必须进行任何热修复，我们将签出最后一个发行分支并进行处理，然后将这些热修复合并到master / develop分支中
–约翰尼
18年8月30日在18:27
究竟。 “主人”应该做的主要是语义。正确的基本做法是避免必须保持多个永久存在的分支双向同步，除非您有充分的理由这样做。 Git Flow中的“ master”分支只是“ develop”的一个滞后副本，因此它实际上并不重要。反模式允许主开发分支保留从未发布的更改，这是我所见过的令人震惊的普遍做法。上面提到的两种模型都可以防止这种情况，这就是它们起作用的原因。
–约翰·米歇尔（John Michelau）
19 Mar 26 '19在21:29
#4 楼
如果开发人员正在处理功能分支，然后在完成功能后将其合并到母版中，则意味着在一段时间内，功能/修复将被合并到
master中，而master分支实际上比生产版本新。 ...
想象一下，如果人们直接与master合并，并且在生产中报告了一个bug，由于master分支代码库已发生重大变化，因此该bug很难修复。 br />
这不是Github Flow。
这是Github Flow部署/合并过程，根据您的链接：
部署
审核您的拉取请求并且分支机构通过您的
测试后，您可以部署更改以在生产中进行验证。如果您的分支机构导致问题，则可以通过将现有的主服务器部署到生产中来回滚它。
经过生产验证，是时候将您的代码合并到master分支中了。
（强调我的）
换句话说，
master将永远不要超前生产。同样，master将始终处于稳定，可发布的状态（除了未发现的错误），因为在合并到master之前，所有内容都经过了检查，测试和推出并投入生产。评论
真好！这具有很大的直观意义-如果您推送到生产中的功能分支失败，那么主节点始终是您的回滚位置。如果不是，它将合并到master中并成为新的后备。我喜欢。
–比尔·霍瓦斯（Bill Horvath）
19年7月12日在19:06
在投入生产之前，我一直都合并为大师，读完这篇文章后我意识到这是一个错误。
– AyexeM
19年11月9日在4:23
这总是让我对git / hub流感到困惑。哪个先到？合并提交到母版还是发布版？释放（释放分支），然后在master上进行任何类型的合并（merge commit，squash commit），意味着master上的提交与实际释放的提交不同。 Rebase合并是一个不同的问题，因为master上的提交可能不在发行分支中，然后不包含在发行版中，而是基于master提交。如果没有对合并进行过多关注，就很难说您发布的内容完全由master代表。
–rjminchuk
1月3日19:38
@rjminchuk与master的所有合并都应该可以作为快进合并来执行，这意味着master最终将具有与发布时完全相同的提交。您可以选择强制非快进合并来创建标记提交，但是合并提交与已释放提交之间的差异应为空。如果diff是非空的，则意味着您同时发布了多个版本，并且/或者您的发布是随机删除的功能。无论哪种方式，我都认为有些严重错误，或者Github Flow不适合您的需求。
– 8bittree
1月4日18:48
我非常确定，主要的git提供程序都可以让您在MR / PR上强制进行快速合并。感谢@ 8bittree的清晰度！我认为在GitHub流中需要提及的是，没有仅进行快进合并，就必须采用另一种形式的发行版本控制，例如长期发行分支或标记。我更喜欢基于Trunk的开发和标记:)
–rjminchuk
2天前
#5 楼
可以标记生产版本，因此可以始终复制已释放的情况，而无需为此专门花费整个分支。如果在主服务器无法执行的同时发现生产中的关键错误，被释放，那么很容易签出标签并从那里开始一个新的“ hotfixes-for-release-1.2.0”分支。但这应该是相当罕见的。
大多数时候，在我们的Web应用程序中，master自上一发行版以来就发生了变化，但变化不大，因此我们可以简单地从master上制作一个具有修复功能的新发行版。 。无论如何，它有助于频繁发布。
#6 楼
我看到的问题是，Git / Hub流的部署/合并假定一次正在开发/测试/合并/部署一项功能，而根据我的经验，事实并非如此。如果我们一次合并一个功能，则出现回归问题的机会更大-仅在将这些功能合并到母版后才可能在生产中发现。 ，合并多个功能并部署相同的功能。我一直在使用“捆绑分支”（从master创建的分支，已将测试就绪功能分支合并到其中），该分支已部署到qa / uat。 uat期间的更正仅在功能分支上进行，而这些更正将重新合并到bundle分支中。捆绑包分支的一个子部分获得批准后，仅捆绑包内那些已批准的功能部件才被请求拉取至母版，并且该循环是连续的。我将它与Gitflow一起使用，但正在考虑将其用于GitHub流。一次发布QA / UAT的许多功能似乎很重要。 GitHub流的另一个问题是它假定所有sr开发人员都可以使用，但并非总是如此。
由于其简化性，我宁愿使用GitHub流。有了捆绑之类的功能，我认为它会更好。捆绑包可能与发布版本相似；但是，我仍然在考虑这一问题。
另一个问题是在合并到master之前，请求请求过程最终会发生。但是，有时您希望在业务质量测试之前进行代码审查-因此在合并之前就很容易
评论
git启用了许多可能的工作流程。人们不应该期望gitflow或github flow被用于所有项目。我讨厌大师是生产中记录的概念。如果我们需要知道生产中有什么，我们应该只查询生产，而不要依赖master来准确反映生产中有什么。
@JimV如果您的分支都不反映生产，那么您如何创建修补程序分支？依靠生产服务器作为开发的权威来源似乎是个坏主意。您的服务器可能损坏了文件，或者黑客可以插入后门，您的存储库将被感染。如果它不在仓库中，那么它也可能不存在。
通过反映生产的提交中的@AyexeM，创建修补程序分支。
@Dzamo Norton-您是否能够从已部署的人工制品中派生出的已编译人工制品中捕获并发布对提交的引用？例如。页脚中的版本，发布版本的端点或日志中的语句。我建议在git分支中查询您的实际部署与簿记。正如AyexeM所指出的那样，如果部署过程失败，则master不再是所部署内容的准确反映。