我们通过 Assembla 和 CI Team City 设置了 svn。我了解源代码管理，我的团队是新手吗？我们应该如何开展工作？现在我们的环境没有按应有的方式组织。我也在努力让 Trac 为我们的团队工作。我们每个人在自己的分支机构工作应该做什么？完成后将更改合并回主干？还是让他们在 Trunk 上工作，希望 Teamcity 能抓到坏东西？
最佳答案
<强>1。我们应该如何开展工作？ 如果团队是配置管理的新手，您的短期目标应该是让他们以受控的方式工作，对他们的工作的干扰最小。这意味着您需要将您的个人配置目标分成短期和长期目标。准备好随着团队的学习重新定义您的长期目标!
<强>2。现在我们的环境没有按应有的方式组织。 一个好的配置管理器总是会这样想。你最不想做的就是给人一种你更喜欢过程而不是“实际工作”的感觉，所以继续前进并在这里思考进化，而不是革命。就像软件一样，定义团队流程需要一个“计划”和良好的沟通。
<强>3。我也在努力让 Trac 为我们的团队工作。 好举动。最初，TRAC 将允许您的开发人员查看正在发生的事情。但是，它也有门票、里程碑、修订、优先级和一大堆其他可能让您的开发人员感到困惑的工具。因此，首先，使用 trac 作为 svn 时间线的 View 和方便的 diffing 工具。在他们对工具集本身感到满意时介绍工单/里程碑等，并准备好在他们不了解/不需要时永远不要使用它们。
<强>4。我们每个人在自己的分支机构工作应该做什么？完成后将更改合并回主干？ 最终，也许。但是您是否定义了分支/合并将为您解决的问题？请记住，您的团队可能永远不会遇到此类问题。我在这里的建议是等到你遇到问题，然后在你的指导下作为一个团队来解决它。
<强>5。还是让他们在 Trunk 上工作，希望 Teamcity 能抓到坏东西？ 起初，是的。然后在遇到问题时介绍您所知道的关于 CM 的所有好东西，而不是之前。
请记住 - 您是在构建软件产品，而不是出色的配置管理系统。所以，保持简单，只使用能让你作为一个团队构建更好产品的工具/流程。您显然已经了解到配置管理的值(value)，所以让您的开发人员也学习。引导他们，不要把过程强加于他们。从显而易见的东西开始(“SVN 让我们以可控的方式共享代码”)，然后从那里开始使用您的经验。祝你好运!
关于svn - 颠覆，5 名开发人员小团队的最佳实践？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1328143/