我们通过与CI Team City的Assembla进行了svn设置。我了解源代码管理，我的团队是新手吗？我们应该如何进行工作？目前，我们的环境还没有得到应有的组织。我也试图让Trac为我们的团队工作。我们每个人应该在自己的分支机构做什么工作？完成更改后，将其合并回主干吗？还是让他们离开后备箱，希望Teamcity能够抓到坏东西？
最佳答案
1.我们应该如何进行工作？
如果团队不熟悉配置管理，那么您的短期目标应该是让他们以可控的方式工作，并且对他们的工作产生最小的影响。这意味着您需要将个人配置目标分为短期和长期目标。准备在团队学习时重新定义您的长期目标!
2.目前，我们的环境尚未按应有的方式组织。
一个好的配置经理会一直这样认为。您要做的最后一件事是给人一种感觉，即您更喜欢过程而不是“实际工作”，因此请继续前进，并在这里思考进化，而不是革命。就像软件一样，定义团队流程需要一个“计划”和良好的沟通。
3.我还试图让Trac为我们的小组工作。
好动最初，TRAC将使您的开发人员可以看到发生了什么。但是，它也具有票证，里程碑，修订，优先级以及大量其他令人困惑的工具，这些工具可能会使您的开发人员感到困惑。因此，首先，将Trac用作svn时间轴的 View 和方便的差异工具。在对工具集本身感到满意时介绍票证/里程碑等信息，并准备好在不需要时不使用它们。
4.我们每个人应该在自己的分支机构做什么工作？完成更改后，将其合并回主干吗？
最终，也许。但是，您是否定义了合并/合并将为您解决的问题？请记住，您的团队可能从未遇到过此类问题。我在这里的建议是等到遇到问题后再在您的指导下作为一个团队解决它。
5.还是允许他们离开后备箱，希望Teamcity能够抓到坏东西？
首先，是的。然后在遇到问题时(而不是以前)介绍您对CM的所有了解。
记住-您在构建软件产品，而不是出色的配置管理系统。因此，请保持简单，并且仅使用可让您以团队形式构建更好产品的工具/流程。您显然已经了解了配置管理的价值，因此也让您的开发人员学习。引导他们，不要强加于他们。从明显的内容开始(“SVN让我们以受控方式共享代码”)，然后根据您的经验从那里开始。祝好运!
关于svn - Subversion，由5个开发人员组成的小型团队的最佳实践？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1328143/