我已经做了很多阅读，并且一直在试用GIT，GIT Tortoise，Tortoise SVN和PlasticSCM，为我们的小团队（5-10名用户）找到合适的源代码控制。
我们团队的一些背景：6位复制作家/编辑（2位远程），2位开发人员，2位图形设计师。我们并不总是在一起开展项目，有时我们中有5个人可能正在处理某个项目。我对DVCS的开发人员并不关心，我主要关注的是其他角色（以最好的方式），他们的技术能力有限。我们的一些复制编写器将多个源文件（HTML，PDF和添加概念图形）更新为实时的，无版本的构建目录（备份为build.23.06.11.new.new.final.zip！）。副本和GD团队没有时间，或者说是粗暴地说，合并/解决冲突的倾向，或者甚至记得切换分支。
一些SO问题已经阐明了什么似乎是一个相当一致的方法 - 主干（主干中没有垃圾！），团队有自己的分支，并有发布分支等。
每次我重新阅读链接......
...而且谷歌一般来说，我最后仍然问自己同样的问题：
不幸的是，复制团队在更新文件方面发挥着至关重要的作用，而这些文件又会在开发期间不断地影响布局和各种事物。它不像我可以让它们保持泡沫直到项目结束并放弃它们的工作。
...好消息是希望，经过多年的努力，我已经准备好强迫每个人转向版本控制了！我们还因其直观的GUI和Windows集成而选择了PlasticSCM。
这个问题的最佳答案是尝试回答上述4点 - 如果你愿意，可以解决第5点 - 如果可能的话解释弱点，并提供建议，得到等等。
喝彩！
答案 0 :(得分：1)
所以基本上你想知道如何让不同技能水平的团队成员使用SCM并且彼此玩得很好。
从您的团队购买优先级＃1。如果你不能使他们学习它，那么你就会留下一条阻力最小的路径。所以你真的需要灵活。可能有错误方式和右向使用该工具，但如果用户不接受正确方式 ，那么错误方式比没有使用它的人好。每个团队如何实现这种平衡将会有所不同。
为“故障点”（复制团队）创建特定于角色的分支是不是一个坏主意，他们可以将其推送到仓库，然后我们的开发人员会将他们的工作合并到实际的项目分支中？
不，也许它不是最优的，但是如果这对复制团队来说很容易，那就是你剩下的东西。您可能会更进一步，并使用自己的分支设置每个用户。然后他们永远不必担心合并其他人的变化。
我是否还应该尝试为其他人强制执行每个分支任务？
每个开发人员都应该有一个唯一的“本地”分支，即不跟踪上游分支。例如，使用像mydev这样的通用名称。这使他们可以轻松地在本地代码和当前上游分支之间切换。
你不一定需要强迫每个人为每个任务创建一个本地分支，最终，你会希望他们只是将他们的工作分支重新绑定到上游分支，然后提交它就会变成快进（即线性提交）。
现在，对于多个开发人员正在处理的任务，或者它是涉及较小提交组的功能，那么是强制他们创建新的特定任务分支是有意义的。当他们合并时，他们可以确保强制合并提交，然后很明显，一组提交被组合在一起，并且所有提交都是特定任务的一部分。合并提交将显示为merged branch feature-X。
我是否应该为每个人执行每个分支任务，但让复制团队创建非常广泛的任务？
这取决于您可以从复制团队获得多少买入。我认为如果他们真的对DVCS工具感到困惑，那么你必须缩减，直到找到一些不会造成太大影响的东西。
一个解决方案是让你的一个开发人员帮助将Copy Teams更改集成到其他人将要查看的另一个分支中。这将有助于将工具的学习曲线卸载到复制团队之外的人身上。
对于执行重要合并的回购，通常会有一个团队/团队/人员被视为“管理员”角色吗？
是的，这是有道理的。然而，关于SCM的好处是，每个人都可以返回并对合并进行代码审查。因此，如果合并破坏了代码，您可以在合并后附加更正，或者删除合并，然后执行此操作。
（是否存在其他建议的工作流程，其中复制编写者不接触源？）
嗯，一种可能的技术是Integration Manager模型。开发人员会将更改提交给他们自己的共享存储库，但需要更改为集成管理器，以便将更改合并到 blessed 存储库中。
我确信还有其他方法可能对您的用户有用，但这个问题有些含糊不清。