Perforce 和特征分支答案

【问题标题】：Perforce and Feature BranchingPerforce 和特征分支
【发布时间】：2017-10-31 05:28:24
【问题描述】：

在我们公司，我们使用 Perforce 进行源代码控制和版本管理。目前我们使用以下“树”实现特征分支

  Hotfix01 - Hotfix branch
  Hotfix02 - Hotfix branch
  HotfixNN - Hotfix branch
Main (continuous trunk)      
  RC - Release Candidate branch (next release)
    Working01 - Working branch, feature branch.
    Working02 - Working branch, feature branch.
    Working03 - Working branch, feature branch.
    WorkingNN - Working branch, feature branch.

我们提前设置了分支机构。并不是说这真的很重要。 RC 的分支是功能分支。目前，我们有超过 50 名开发人员、分析师和 QA 团队成员，他们单独或作为一个团队参与各种项目、缺陷修复等工作。当工作进入时，您会找到一个免费分支（我们单独跟踪），声明该分支（例如，Working56），从 RC 到该分支进行强制合并/同步（以确保它正是当时 RC 中的内容），完成您的工作（代码、同行评审、质量保证），同时不断将 RC 的任何更改合并到您的工作中分支（每天至少一次，可能根据需要更频繁），完成后将更改复制到 RC。

这可行，但这意味着我们（此时）有 300 个工作分支需要管理。我们希望以更合理的方式实现功能分支，我们将使用分支映射等根据需要创建一个分支，以它的用途命名，然后一旦我们将它合并回 RC，我们希望它不再出现在永远的仓库（至少，不是每个开发人员）。基本上，我们只想将那些正在积极开发的分支视为功能分支，隐藏我们完成的分支。

最佳做法是什么？这可以通过 perforce 使用分支或流来完成吗？我们是否缺少允许这样做的分支规范？我们应该不用担心，让成千上万的功能分支堆积在 RC 下的 depot 视图中吗？我们现在的做法是我们所希望的最好的吗？

我们已经使用 Perforce 10 年了，这仍然是一个每天都困扰着我们的问题。

【问题讨论】：

目前尚不清楚多个开发人员在同一个功能分支上协作的频率，但您可能会调查的一件事是 Perforce DVCS 功能。如果开发人员在他们自己的 DVCS 存储库中创建自己的分支，他们并不会因为临时分支而污染共享服务器。
开发团队中的个人和团队工作很好地结合在一起。我会期望执行的任何工作单元都可能需要至少 3 人访问（甚至只是一个错误修复 - 开发人员、同行评审、QA）才能合并到任何父分支。除此之外，任何规模的许多项目都有多个开发人员合作。

标签： version-control branch perforce

【解决方案1】：

任务流就是为此而设计的。

https://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html

创建任务流，在其中完成工作，合并/复制回父级，然后unload 任务流。

常见的任务流陷阱：

不要尝试重复使用或重新设置它们。每个任务一个流！如果您尝试重用任务流，它们的有益功能大多不起作用，但您仍然会遇到所有限制。
在卸载任务流后，修改后的 depot 文件仍然存在。调整您的思维模型，使用流列表作为激活流的事实来源，而不是库树中的文件夹。

如果你能处理这些，任务流将非常有用。

【讨论】：

我对 Streams 的有限理解是它们分层在分支之上（Perforce 将它们描述为带大脑的分支）。创建流是否还会创建一个将存在于仓库中的分支，还是将其隐藏，以便一旦流完成它就不会弄乱界面？我在文档中没有看到任何定义，不幸的是我无法快速设置测试环境，而且我们当前的 Perforce 服务器版本不支持流。
我认为我无法在评论空间中完全解释有关流的所有内容，但您所谈论的是我所说的“问题 #2”。获得流的好处需要稍微调整您的工作流程，我通常建议如果您使用流，则不要使用界面的 depot 选项卡部分，因为它避开了流提供的 depot 的简化视图。