混合角色小团队的 DVCS 策略？

Question

我已经阅读了很多资料，并且一直在试用 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 问题揭示了似乎相当一致的方法 - 主干（干中没有垃圾！）团队拥有自己的分支，并拥有发布分支等。

每次我重新阅读链接...

• https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team
• Getting started with Version Control
• http://svn-ref.assembla.com/subversion-how-tos.html

...和一般的谷歌，我最终还是会问自己同样的问题：

1. 为“问题点”（副本团队）创建角色特定的分支，他们可以推送到存储库，然后我们的开发人员会将他们的工作合并到实际的项目分支中，这是一个坏主意吗？
2. 我是否仍应尝试为其他所有人强制执行每个分支的任务？
3. 我应该为每个人执行每个分支的任务，但让复制团队创建非常广泛的任务吗？
4. 通常是否有一个团队/组/个人被视为执行关键合并的存储库的“管理员”角色？
5. （是否有其他建议的工作流程让文案作者不接触源代码？）

不幸的是，文案团队在更新文件方面发挥着至关重要的作用，这反过来又会在开发过程中持续影响布局和各种事情。这不像我可以让他们在项目结束之前一直待在泡沫中，然后把他们的工作扔进去。

...好消息是，希望在多年之后，我已经准备好强迫每个人都转向版本控制！我们还选择了 PlasticSCM，因为它具有直观的 GUI 和 Windows 集成。

此问题的最佳答案是尝试回答上述 4 点 - 如果您愿意，请解决第 5 点 - 如果可能，请解释弱点，并提供建议、问题等。

干杯！

Answer 1

所以基本上你想知道如何让不同技能水平的团队成员使用 SCM 并相互配合。

团队的支持是第一要务。如果您不能让他们学习它，那么您就只能提供一条阻力最小的路径。所以你真的需要灵活。可能有一个错误的方式和一个正确的方式来使用该工具，但是如果用户不接受正确的方式 ，那么 wrong-way 比他们根本不使用它要好。对于每个团队来说，实现这种平衡的方式会有所不同。

为“问题点”（复制团队）创建角色特定的分支，他们可以推送到 repo，然后我们的开发人员会将他们的工作合并到实际的项目分支中，这是一个坏主意吗？

不，也许它不是最佳的，但如果这对文案团队来说很容易，那么这就是你剩下的。您可能更进一步，为每个用户设置自己的分支。这样他们就不必担心合并其他人的更改。

我是否仍应尝试为其他所有人强制执行每个分支的任务？

每个开发人员都应该有一个唯一的“本地”分支，即不跟踪上游分支。例如，使用像mydev 这样的通用名称。这使他们可以轻松地在本地代码和当前上游分支之间切换。

您不一定需要强迫每个人为每个任务创建一个本地分支，因为最后，您会希望他们只是将他们的工作分支重新定位到上游分支，然后提交，这样它就变成了快进（即线性提交）。

现在对于多个开发人员正在处理的任务，或者它是一个涉及较小提交组的功能，那么是的强制他们创建一个新的特定任务分支确实有意义。当他们合并时，他们可以确保强制合并提交，那么很明显一组提交被组合在一起，并且都是特定任务的一部分。合并提交将显示为merged branch feature-X。

我是否应该为每个人执行每个分支的任务，但让文案团队创建非常广泛的任务？

这完全取决于您可以从文案团队获得多少支持。我认为，如果他们真的对 DVCS 工具感到困惑，那么您必须缩减规模，直到找到不会造成太大影响的东西。

一个解决方案是让您的一位开发人员帮助将 Copy Teams 更改集成到其他人都会查看的另一个分支中。这将有助于将工具的学习曲线转移到文案团队之外的人身上。

通常是否有一个团队/组/人被视为执行关键合并的存储库的“管理员”角色？

是的，这是有道理的。然而，SCM 的伟大之处在于，每个人都可以返回并在合并时进行代码审查。因此，如果合并破坏了代码，您可以在合并后追加更正，或者删除合并，然后重新执行。

（是否有其他建议的工作流程，文案作者不接触源代码？）

嗯，一种可能的技术是Integration Manager 模型。开发人员将更改提交到他们自己的共享存储库，但这取决于集成管理器，以将更改合并到 blessed 存储库。

我确信还有其他方法可能对您的用户有用，但这个问题有点模棱两可。