Perforce和功能分支

Question

在我们公司，我们使用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中的内容），执行您的工作（代码，同行评审，QA），同时不断将RC中的任何更改合并到您的工作分支（每天至少一次，可能更多时候根据需要），当你完成后，你将更改复制到RC。

这有效，但这意味着我们（此时）有300个工作分支进行管理。我们希望以更合理的方式实现功能分支，我们将使用分支映射，例如根据需要创建分支，以它的用途命名，然后一旦我们将它合并回RC，我们希望它不再出现在永远的仓库（至少，不是每个开发商）。基本上我们希望只看到那些具有活动开发的分支作为特征分支，隐藏我们已完成的分支。

最佳做法是什么？这可以通过使用分支或流的perforce来完成吗？我们是否遗漏了具有分支规范的内容？我们是否应该不担心并允许数千或数万个功能分支堆积在RC下的仓库视图中？我们现在采取的方式是我们所希望的最佳方式吗？

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

Answer 1

任务流专为此而设计。

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

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

常见任务流陷阱：

1. 不要试图重复使用或重新使用它们。每个任务一个流！如果您尝试重用任务流，那么它们的有益功能大多不起作用，但您仍然可以获得所有限制。
2. 卸载任务流后，修改后的depot文件仍然存在。调整心智模型以使用流列表作为流活动的真实来源，而不是库中树中的文件夹。

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