2

我正在寻找最新的知识/最佳实践/建议。

我们正在考虑为我们的发展转向单一回购。我们将 Scrum 与 Stories/Epics/Sprint 一起使用（我对所有术语都没有完全了解……我老了，一些新东西看起来就像旧东西……只是名称不同）。

我们理解为开发人员定义小工作单元的必要性，但通常情况下，多个单元具有一定程度的相互依赖，但用于系统的不同部分。

开发人员可以同时处理多个，因为这样更有效（并且使任务更容易实现），但任务是分开的，每个任务都需要自己的审查。

我们想要的是能够“检查”当前功能分支的代码（我正在使用 git 术语，就像我们目前正在使用的那样），允许开发人员进行编码，运行在本地测试，如果满意，将特定更改提交到不同的分支。因此，例如，迁移更改转到迁移任务的分支，API 建模/映射更改转到相应任务的分支等。

每个任务都为故事设置了适当的阻塞，因此发布经理可以按正确的顺序发布所有内容（即，您不能发布数据存储中不存在的列的 UI 更改）。

用 git 实现这样的事情是非常麻烦的。

对我们来说，一个功能分支是一个故事（即客户希望能够让他们的客户能够更改预订的会话时间，假设存在可用性，如果需要，可以发出退款或要求进一步付款）。为了实现这个故事，需要完成各种任务（新数据、UI/UX 工作、API 工作等）。这些中的每一个都是为故事定义的任务。每个都有自己的分支。

有更好的选择吗？

如果没有，是否有更好的做法可供任何人推荐？

4

1 回答 1

0

您可能正在寻找gitflow（用于 git）或用于 Mercurial 的hgflow 。

这些分支工作流似乎旨在解决您提出的组织问题。

git流：

由 Vincent Driessen创建/倡导。尽管这个模型是在考虑 git 的情况下创建的，但在大多数情况下，它并不是真正特定于 git 的。

中央仓库拥有两个具有无限生命周期的主要分支：

主开发

我们认为 master 是 HEAD 的源代码始终反映生产就绪状态的主要分支。

我们认为开发是主要分支，它反映了具有最新交付的开发更改的状态。有人将其称为“集成分支”。

当开发分支中的源代码达到稳定点并准备发布时，应将所有更改合并回 master，然后用发布号标记。

在主要分支旁边，我们使用支持分支来帮助团队成员之间的并行开发，轻松跟踪功能，准备生产版本并帮助快速修复实时生产问题。

我们可能使用的不同类型的分支是：

功能分支 发布分支 修补程序分支

这些分支中的每一个都有特定的目的，并且受到严格的规则的约束......

（文字来源）

流量：

这是 gitflow 的 Mercurial 等价物。

hgflow 是 Hg 的开源扩展，灵感来自 git-flow，并围绕 Vincent Driessen 流行的分支模型构建。从本质上讲，它形式化了围绕 Driessen 模型的工作流，并提供了用于在该模型中分支和合并功能、版本和修补程序的命令。

...

Hgflow 不应该对标准源代码控制工作流程进行任何根本性的改变，它只是引入了一个更正式的词汇来描述分支，并将一个很好的模型应用于流程。最重要的是，它增加了一点自动化，使与 Hg 的合作更加愉快。

hgflow 主页。

（文字来源）

此外，如果您还没有研究过github之类的网站如何允许您使用诸如拉取请求之类的东西来管理功能，那么考虑一下这可能会很有用。据我了解，github 提供了基本的工具来帮助制定/管理工作流程，例如 Driesen 分支模型。

于 2018-11-19T13:41:17.290 回答