version-control - 使用集中版本控制的正确/最佳/最有效方法是什么？

我是一个小型开发团队（4人）的一员。

我们都不具备版本控制方面的丰富经验，但我们必须根据公司的政策使用Perforce。在大多数情况下，它一直都很棒，但我们已经保持了一个简单的过程，我们之间已达成一致并开始变得不那么理想。我想知道人们是否可以分享他们在版本控制方面的工作顺利有效地工作。

我们的原始设置是：

我们有一个主干，它现在保存生产代码。
每位用户都像我们一样为他们的工作创建了一个开发分支总是在不相互影响的不同区域工作。
我们在Redhat Linux机器上开发，代码从/ var / www / html运行。因此，我们同步到工作区并将这些文件复制到此路径，更改权限，然后在那里执行更改。当我们想要签到时，我们检查工作区中的文件，用我们更改的内容覆盖它们并提交（我认为这可能是我们最薄弱的部分）
如果干线的任何更改会影响相关功能，则会对其进行更改。然后部署代码进行测试。
测试完成后，我们将分支合并到主干，然后从当前主干创建一个发布分支，再次进行测试，然后发布到生产中。

之前这项工作很好，因为我们的项目规模很小且非常分散。但是，现在我们都在开发同一个大开发分支。自创建分支以来已经发布了更改，并且在完成之前将进行更多更改。

我们还需要在开发的各个阶段部署用于测试的代码，并且此代码需要与开发更改以及对生产所做的任何更改保持同步。

我们已经决定在这个阶段我们将在dev分支的同时创建发布分支，每当我们需要测试版本时，我们将合并当前的Trunk（生产）和当前的dev分支，以便它完全是最新的。但是，这种合并需要整个团队花费大量时间，而且效果不是很好。

我被告知不同的团队有不同的处理方式，所以我不是要找我的流程修复，但我很想听听你愿意分享的设置

如果您不熟悉版本控制和最佳实践，我建议在Perforce中使用Streams。功能流和分支非常相似。与Streams的不同之处在于Perforce利用基于流类型的预构建关系并提供基本治理（即，在合并之前，您无法将这些文件复制到其他流）。

管理员可以覆盖所有命令。

一旦您使用流，您可以通过几种不同的方式做事。您有三种类型的流，Release（最稳定），Main（稳定）和Development（最不稳定）。您可以创建任何您喜欢的层次结构。

我想在我的情况下，我会有一个Mainline，一个集成开发流，然后是每个开发人员要使用的开发流。这样，您每个人都有自己的游乐场，并且可以在完成后将更改移动到集成流。然后，可以将完成的更改合并到其他开发人员流中。