问题标签 [branching-strategy]

之前已经发布过这个问题，最近收到了一些非常好的遮阳篷，尽管我还没有完全解决这个问题。我现在有一些可行的代码，虽然这个网站上的某个人可能能够修复，或者告诉我如何修复大声笑。

好吧，基本上是关于我的目标是什么，因为我被多次告知我正在做的事情是无用的，或者我没有提供足够的信息，我会在这里尽力而为。我有一个程序可以在 PDF 文件上创建发票并将其打印出来。python 脚本来自所有必要的客户/服务信息等的 CSV 文件。

现在，到目前为止，我的代码中的问题是我拥有的服务数量，以及在 Python Reportlabs 中，您必须选择在页面上绘制字符串的位置。一个命令示例是：

通常的做法是从第 1 串到第 6 串，一根一根地拉到它上面的一根。在接下来的三个示例中，您将看到第一个是在对所有服务收费时函数将如何输出。第二个（中间）是不向客户收取某些服务费用的输出。final(RightMost) 示例是我希望它如何输出的代码。

不幸的是，基于布尔逻辑，并且有 6 种可能的服务，并且每种服务都可以收费或不收费，空的或满的，如果您愿意，那么有 64 种可能的方式来编写相同的函数以实现完美的输出。

如果我们为每个服务创建一个布尔值，0 为空，1 为满，那么我们将不得不测试从 000000 到 111111 的所有可能性。那是64。编码出来是完全合理的。

但是，我需要的服务远不止六项，而且所需的功能数量呈指数级增长。我没有编写每个函数，而是编写了一个程序，该程序将采用 0 和 1 集的文件，即：

并测试每一行中的每一位。然后，此函数将根据行中的位为文件中的每一行写出一个函数。现在，它会产生不正确的输出。我将首先向您展示我的脚本：

目前，只要仅缺少一项服务，此代码就会在此处生成像这样的正确输出：

但是，我的代码中的逻辑因多个缺失的服务而中断，如下所示：

如果有人可以修复此问题，以便文件中所有行的输出看起来像下一位，我会为你投票赞成 **** 大声笑：

和往常一样，如果你写到我的帖子的结尾，我会印象深刻，哈哈。感谢任何为此付出哪怕一丁点努力的人，感谢所有帮助我走到这一步的人。

我在这里发帖询问是否有办法交替不同的分支策略。让我解释一下，我有一个有效的分支策略，我们称之为策略A。最大的问题是策略A不能经常使用。所以当我不能使用策略A时，我会使用另一种策略，我将其称为策略B，它的效率较低。

文档说：

分支订单。创建分支器会将其注册到其主空间。空间维护其分支器的队列，因为首先注册的分支器也首先用于分支。分支队列中的第一个分支称为当前分支。

所以，我想如果我发布分支 A 然后分支B，分支Astatus将具有优先级，并且每次A说没有分支要做，分支B将被使用。似乎我错了，因为当status分支返回false时，它再也不会被调用。这是一个“最小示例”：

在此示例中，如果要分配的下一个变量位于偶数索引上并且该变量可以采用( else )的值，status则分支器A的 如果下一个要分配的变量位于奇数索引上并且该变量可以取( else)的值，则分支器B返回。使用该代码，我希望获得解决方案和（以及其他组合，例如），但是由于分支在返回时被处理，因此只分配了前两个变量。true1false statustrue2false[1, 2, 1, 2, ...][!1, !2, !1, !2, ...][!1, 2, 1, !2, ...]statusfalse

有没有一种好方法可以使分支器在status返回后不被处理false（或交替使用两种不同的分支策略），还是应该将两个分支器合并为一个？

所以我加入了一个最近（去年）从 TFS 转移到 GIT 的团队。分支策略是这样的。开发 -> 发布 -> 主控。Dev 准备好后，合并到 Release。从 Release 构建并部署到各种环境。一旦它到达第一个生产环境，就合并到 Master，因此 master 始终是一个保留的生产状态。如果需要修补程序，请在 Dev 中进行更改，Cherry-pick 到 Release，一旦部署到 prod，cherry-pick 到 master。永远不要从 Master 到 Release 或 Release 到 Dev 向后合并，始终将代码流向一个方向......如果我们确实需要向后合并，它要么是另一个樱桃选择（如果你能找到它），要么是与大量的巨大合并冲突。

优点：

• 简单的

缺点：

• 提交历史在分支之间是无用的，因为它们不会匹配。
• 不小心直接对 Release 或 Master 而没有 Dev 进行的更改，永远不会回到 Dev，直到有人在覆盖后再次注意到错误或合并冲突提醒某人（不太可能，因为这主要是盲目的合并，人们会训练忽略合并冲突。）

因此，这是一种非常 TFS 集中的做事方式，我正在推动一个两个分支系统。开发者和大师。当我们准备好发布时，将 Master 合并回 Dev 以确保一切同步，然后 Dev 到 Master 标记提交以便在需要时方便参考。如果出现修补程序，则从 master 分支，根据需要进行修复，根据需要进行部署并合并回 master。如果在 Dev 中需要，则将 Master 合并回 dev，或者等待下一个版本。

优点：

• 只有当有人从 HF 分支部署并忘记合并回 Release 时，提交才会丢失（我认为仅从 Master 部署到 prod 以强制合并......但构建需要很长时间，所以这是一个症结......）
• 提交历史将在分支之间匹配，因此您知道事情是同步的
• 合并冲突应该被大大减少和/或由进行更改的人处理，以便他们更好地知道如何处理它们。

缺点：

• 更复杂，特别是如果你来自 TFS ......我以前去过那里
• 如果同时进行多个修补程序，这可能会变得混乱。

因此，团队中的另一位开发人员同意 Cherry-pick 分支策略存在一些问题，但认为它的简单性应该意味着几乎不会发生没有返回到 dev 的更改，并且仅提交历史不值得 git 的努力战略。

问题是，我对此没有回应。从根本上说，不是 100% 积极的代码要生产的想法是你在 dev 中测试的东西让我无休止......但我可以看到其他人可能会因为不合并而在 Hotfix 分支中忘记某些东西的风险更高它回到大师。另外，我喜欢 Git，虽然我不是专家，但 git 分支策略对我来说很有意义....然而，在几年前我自己从 TFS 过渡到 GIT 之后，我可以看到事情看起来多么复杂，而且那里在它成为每个人的第二天性之前会有很多错误。

我的问题是，是否有更令人信服的理由使用获取分支策略？我已经搜索了很多“樱桃采摘分支策略”和其他变体，但没有提出任何建议，所以我希望我在这里遗漏了一些重要的东西。

以下是我们工作方式的一些背景

我工作的团队使用 SVN 来签入代码。为每个发布人员正在处理的版本创建一个分支。主干是生产代码，没有人接触它。Release 上线后，Release 分支就会合并到主干中。

在任何时候，来自多个发布分支的代码都被部署在一个单一的测试环境中，因为我们没有足够的测试环境。在某些情况下，两个不同的 AP 在两个不同的分支下更改脚本。当我们将这两个分支部署到 1 个测试环境中时，代码会被覆盖。

问题

识别在一个时间点在多个分支中更改的所有脚本的最佳方法是什么？

在 MiniZinc 中可以使用搜索注解效果，官网解释如下：

注释影响

在搜索过程中选择迄今为止影响最大的变量

这在实践中意味着什么？最大的影响是什么？这是如何计算的？

我们的开发过程与此问题中描述的类似，需要创建许多小功能。通常每天 4-8 个功能。所有功能都应该部署到同一个测试环境，所以应该有一个test分支。

我们应该采用哪种分支策略？创建单独的功能分支似乎是一个很大的开销，同时基于主干的开发缺乏灵活性。混合这些方法是否可以（对于小功能直接提交，test对于相对大的功能单独分支）。

我们对 Git 和常见的分支策略（如 git-flow）完全陌生，并试图找到最适合小频繁功能的策略。

我们将非常感谢任何帮助或指出正确的方向，因为没有很多文章描述小功能的分支。谢谢！

我正在尝试在 PIC16 等低级微控制器中实现 BTB。我不知道这是否可行。所以想要你的建议。

谢谢。

我有一个工作流程，其中我需要将一些功能交付给开发人员进行测试，然后再将它们推送到生产环境。问题是其中一些功能需要无限期地保留在开发服务器上，并且永远不会被推送到生产服务器，所以我不能直接将 dev 分支与 prod 分支同步。这意味着我不能使用只有一个主分支通过标签发布到产品的模型。我可能需要为每个功能请求创建一个分支，并且总是从 prod 分支分支出来，以免从 dev 推送任何不应该在 prod 上的东西。我想知道用 git 管理这样的事情的最佳方法是什么。

目前的思路如下：

这种方法足够可靠吗？

谢谢！

我正在关注一个 git 分支模型，它有两个长期运行的分支（dev、master），其中功能分支主要基于 master（或有时是 dev）并合并到 dev，然后 dev 在几个特性后合并到 master（所有合并都是no-ff 合并）。

现在经过 5 次 dev 与 master 的合并

给人的印象是 master 中有一些 dev 中没有的变化。

在将 dev 合并到 master 之后，我一直在通过 ff-ing dev 解决这个问题。运行中的分支将基于 ff 合并到 master 之前的 dev （下面是 391355d 而不是 ca386a7）。还有比这更好的方法吗？

是否可以在 Github 的组织级别启用分支保护规则，以便该组织的所有存储库都为应用的分支继承这些规则。现在，在每个回购的基础上为同一组分支启用这些相同的规则集确实很麻烦。