问题标签 [branching-strategy]

我正在处理的一个项目 (C++11) 涉及一段代码，该代码块将在某处运行数万亿次。我在 [1,N] 中有一个整数参数 B 和点 1 = b1 < b2 < ... < bk = N 代码根据哪个区间 [bi, b(i+1) 执行不同的小代码块) B 在于。在整个执行过程中唯一变化的值是 B。但是，虽然 bi 的值是固定的，但它们仅在运行时确定。

天真的事情是写一堆 if 和 else if 语句，在最坏的情况下涉及 k 次比较。然而，可以在恒定时间内做到这一点：构造一个大小为 N 的向量 myGotos，并在每个区间 [bi, b(i+1)) 上存储相应代码块的位置。然后你只需执行 goto myGotos[B]。

在我看来，上面的解决方案平均起来会更快，但代码会非常难看。我想知道是否有更好的方法来做到这一点。

这里是分支概念的新手。

我们在 TFS 2013 下有一个没有分支的解决方案。解决方案中的某些文件（用于编组第三方模块的方法）可能与以前的版本不兼容，我们必须根据新提供的解决方案更新我们的解决方案中的用法。这些文件往往会在几个主要版本中更改一次（它们不会在每个版本中都更改）。

我们希望能够访问我们以前的版本并在必要时应用热修复。

为每个主要版本创建一个分支（以及标记它们）是否足以实现这一目标？

我们目前正在尝试将我们的 mercurial（在这种情况下是 Kiln 的古老版本）迁移到 BitBucket，我们立即遇到了大小问题（如果您不知道，BitBucket 施加了相当大的 2gb 回购限制 - 我们碰巧吹过）。

无论如何，我已经清理了过去的罪过：

• 使用带有文件映射的转换（删除不应该在 repo 中的二进制文件/静态文件）
• 为其他不应该在主仓库中的东西创建单独的仓库
• 尝试使用 generaldelta 来减小大小（根据 https://www.mercurial-scm.org/wiki/ScaleMercurial）
• 使用分支图尝试合并旧分支及其关联的变更集

即使有了这些步骤，我仍然有一个非常大的清单文件，尽管为存储库存储的“数据”缩小到“可管理”的大小（~600mb），但我的清单文件接近 700mb。

一些附加信息：通常，我们练习每个功能的分支并有两个分支跟踪环境：

• 发布分支（部署到 staging 然后到 prod）
• 默认分支（最初关闭发布，所有功能先在这里合并然后发布。此分支每两周死亡并重生）

这个工作流程的一个区别是默认本身永远不会被合并到发布（a la gitflow/hgflow）。这种单向流入默认会导致问题吗？

我们“只有”有 120 个开放的分支负责人，所以这似乎是可以管理的？

我显然在这里遗漏了一些步骤（否则回购完全被冲洗掉了）。

我们将使用 GIT 实验室作为我们的 SCM，在最初的 POC 中我们遇到过这样的情况。与典型的 GITLab 流程（如图所示）一样，我们根据需要拥有 Master、development 和并行功能分支。当属于特定 sprint 的所有功能都完成并合并到开发分支时，我们从开发分支分支发布分支，然后对其进行 QA（发布分支）。在将所有错误修复应用到发布分支之后（当它准备好生产时），它应该合并到开发分支和主分支中。

问题是有时，可能会在最后一刻做出决定，例如说功能 A、B、C 中的功能“B”这次不会生产，因此应该保留。

为了处理上述情况，我想我们可以使用 git 命令，如 Rebase/Cherry Pick/Reset 等。

处理上述情况的最佳方法是什么？您能否详细解释一下，因为我仍然是 GIT 世界的新手。

这与尝试处理未完成的用户故事有关。一个例子：

在 sprint 1 中，有一个用户故事 #100。因此，我们创建了一个 sprint 分支 (sprint-1)，然后在该分支上创建一个用户故事分支 (us-100)。在冲刺结束时，用户故事还没有完成。正常流程是用户故事使用拉取请求合并到 sprint 分支中，经过审核后，将 sprint 分支合并到开发中（使用拉取请求）。然后删除 sprint 分支。由于 us-100 没有完成，它没有合并到 sprint-1 中，当 sprint-1 被删除时，我不确定 us-100 发生了什么。

我想做的是将us-100 分支“移动”到另一个sprint，例如sprint-2 分支。这可能吗？如何？或者，还有更好的方法？

在内部讨论 TFS 合并和分支指南时，一些团队成员建议只留下一个发布分支，并通过在那里实施修补程序和服务包来“使其与生产保持一致”。我的想法是创建多个发布分支，基本上每个发布分支都映射到一个开发分支并合并到主分支，基本上主要与生产对齐。有人可以建议我们应该走哪条路线吗？

我们在项目中使用 git 和git 流分支模型。在我们的代码库中有一些与调试相关的代码，我们在非生产代码中默认打开（调试输出/调试标志）。

我们当前将发布部署到生产（主分支）的工作流程是从我们的开发代码库（开发分支）创建一个发布分支。在发布分支上，我们禁用调试功能（调试标志），测试，最终在测试后进行更改，提交，将发布推送到 master，合并 master 以开发并手动更改调试标志。

在发布和合并回开发时，是否有比手动打开和关闭调试标志更好的工作流程？

24/01/16 编辑：回复@Lazureus 评论：使用的语言是：Python（后端）。和 Javascript（前端）。没有使用 makefile，因为没有要构建的东西。我们用于 python 的 IDE 是 pycharm。

我在这里阅读有关 git 分支策略的信息。在哪里分配补丁？补丁应该有自己的分支吗？如果是，补丁应该从哪里分支？从主分支？

我们公司（内部项目）使用版本控制（TFS，现为 2015 年）来简单地保留已发布代码的审计跟踪 - 我引入了分支和合并的使用，它完全改变了我们看待开发管道中瓶颈的方式和普遍受到好评，但现在我正在寻找下一步。

我们的代码由一个大型软件和其他几个附带的业务应用程序组成。

我们有四个始终保持不变的环境，我们的“管道”就是这样。

• 开发人员在本地工作。
• 将代码推送到“开发”环境（因此我们都可以查看代码，了解它在环境中的集成情况等）
• 当测试准备好时，我们推送到“测试”——这是已被批准向上移动的代码，因此环境比“开发”稳定得多。
• 接下来，我们将它传递给 UAT 服务器，它本质上是对实时服务器的模仿，以尽可能稳定并代表实时发布。批准移到这里的代码并不常见。
• 最后，生产环境。

现在我只是简单地为每个环境建立一个分支，以便于比较，让人们快速获取源代码和诸如此类的东西，并查看代码库在链上的进展。

主要 -> 阶段 -> 测试 -> 开发

这是一条直线，我们可以简单地查看 MAIN 分支的历史，以查看所有不同的发布版本。

我们从 dev 分支分裂到本地分支，任何修补程序都直接来自 UAT 分支。

这对我们有用——但它在程序程序可以工作的意义上是有效的——它可能不是最有效的方法。我只是很好奇是否有更好的方法可以做到这一点，在网上阅读了大量内容后，我觉得人们不会按环境划分分支，但我真的不明白如何更好地工作？尽管合并四次以发布一些代码很痛苦（尽管大多数时候它是一个相当慢的管道，但我们每周发布一次）。

非常感谢任何帮助。

设想

我有一个解决方案，克隆到我的本地机器上，并且我对 master 分支做了一些更改（但我还没有提交它们）。

问题

工作还没有完成，所以我想暂时将这些更改提交到他们自己的分支中，但是我一直在 master 中工作。

如何将 master 中的更改提交到他们自己的分支？