我是一个小型开发团队（一个4人）的一部分。
我们每个人都不具备版本控制方面的丰富经验，但是根据我们公司的政策，我们必须使用Perforce。在大多数情况下，它都很棒，但是我们一直遵循着我们之间达成的一个简单的过程，而这个过程开始变得不那么理想了。我想知道人们是否可以分享他们顺利有效地进行版本控制的经验。
我们最初的设置是这样的：
以前这很好用，因为我们的项目很小而且非常分散。但是现在，我们都在同一个大型dev分支上工作。自从创建dev分支以来，已发布了更改，并且将在完成之前进行更多更改。
我们还需要在开发的各个阶段部署用于测试的代码，并且此代码需要与开发更改以及对生产所做的任何更改保持最新。
在此阶段，我们决定将与dev分支同时创建release分支，每次需要测试版本时，我们将合并当前Trunk（production）和当前dev分支，以使其完全启动迄今为止。但是，这种合并需要整个团队花费大量时间，而且效果还不是很好。
有人告诉我，不同的团队有不同的处理方式，所以我不是在寻找适合自己的过程的解决方案，但我很想听听您愿意分享的设置
如果您对版本控制和最佳实践不是特别熟悉，我建议您在Perforce中使用Streams。在功能上，流和分支非常相似。与Streams的区别在于Perforce利用基于流类型的预先建立的关系并提供基本的管理（即，除非合并，否则您不能将这些文件复制到另一个流中）。
管理员可以覆盖所有命令。
一旦利用流，您可以通过几种不同的方式来做事。您可以使用三种类型的流，即Release（最稳定），Main（稳定）和Development（最不稳定）。您可以创建自己喜欢的任何层次结构。
我想在您的情况下，我将有一个Mainline，一个集成开发流，然后是一个供每个开发人员使用的开发流。这样，每个人都有自己的游乐场，一旦完成更改，就可以将您的更改移到集成流中。然后，可以将那些完成的更改合并到其他开发人员流中。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句