【发布时间】：2009-08-25 22:13:25
【问题描述】：
我们通过 Assembla 和 CI Team City 设置了 svn。我了解源代码控制，我的团队是新手吗？我们应该如何进行工作？目前，我们的环境并没有按照应有的方式进行组织。我也在努力让 Trac 为我们的团队工作。我们应该怎么做每个人在自己的分支机构工作？完成后将更改合并回主干？还是让他们在 Trunk 上工作，希望 Teamcity 能抓住坏东西？
【问题讨论】：
【发布时间】：2009-08-25 22:13:25
【问题描述】：
1.我们应该如何进行工作？ 如果团队不熟悉配置管理，您的短期目标应该是让他们以受控的方式工作，对他们的工作造成最小的干扰。这意味着您需要将您的个人配置目标分为短期和长期目标。准备好随着团队的学习重新定义您的长期目标！
2。目前，我们的环境并没有按照应有的方式进行组织。 一个好的配置管理器总是会这样想。您要做的最后一件事是给人一种感觉，即您更喜欢过程而不是“实际工作”，因此请继续前进并在这里思考进化，而不是革命。就像软件一样，定义团队流程需要一个“计划”和良好的沟通。
3.我也在努力让 Trac 为我们的团队工作。 好动。最初，TRAC 将允许您的开发人员查看正在发生的事情。但是，它也有票证、里程碑、修订、优先级和一堆其他可能会让您的开发人员感到困惑的令人困惑的工具。所以，首先，使用 trac 作为 svn 时间线的视图和一个方便的 diffing 工具。当他们对工具集本身感到满意时，介绍工单/里程碑等，并准备好在他们不需要/不需要时永远不要使用这些。
4.我们应该怎么做每个人在自己的分支机构工作？完成后将更改合并回主干吗？ 最终，也许。但是您是否定义了分支/合并将为您解决的问题？请记住，您的团队可能永远不会遇到此类问题。我在这里的建议是等到你遇到问题，然后在你的指导下作为一个团队解决它。
5.还是让他们在 Trunk 上工作，希望 Teamcity 能抓住坏东西？ 起初，是的。然后在你遇到问题时介绍你所知道的关于 CM 的所有好东西，而不是之前。
请记住 - 您正在构建一个软件产品，而不是一个出色的配置管理系统。所以，保持简单，只使用可以让您作为一个团队构建更好产品的工具/流程。您显然已经在此过程中学到了配置管理的价值，所以让您的开发人员也学习一下。引导他们，不要强迫他们处理。从显而易见的东西开始（“SVN 让我们以受控方式共享代码”），然后利用您的经验从那里开始。祝你好运！
【讨论】：
每个人在自己的分支机构工作应该怎么做？完成后将更改合并回主干吗？
我通常不赞成这样做，因为每个开发人员的分支很笨拙，并且给定的开发人员很难通过查看单个分支来了解其他所有人正在以这种方式工作的内容。您可以通过要求每个人在每次提交时合并回主干来缓解这种情况，但是为什么还要有一个分支呢？
或者让他们在 Trunk 上工作，希望 Teamcity 能抓住坏东西？
我的建议是让开发人员参与制定团队规则：每个人都从主干更新并提交到主干，并在提交之前在本地运行（所有）测试。 Subversion 中的分支更有效地用于功能集，例如与即将发布的版本相对应的功能集，而不是单独的功能测试场。
我认为您的 CI 应该是一个安全网，可以提醒您事情未处于您期望的状态。但是，如果您的开发人员明白他们不应该签入一开始就没有通过的代码，这会有所帮助。
【讨论】：
1 - 更新
2 - 代码
3 - 测试
4 - 更新合并
5 - 测试
6 - 提交
【讨论】：
-
循环 4 和 5 直到存储库中没有更改。
-
我不确定你在说什么？你介意重述一遍吗？
-
如果不是绝对必要，不要分支。在进行更改之前在本地更新。做你的改变。在运行代码和测试时，从存储库更新并合并可能的冲突，重新运行测试并提交。如果您正在处理大型任务并且很难定期（例如，至少每天）提交运行代码，请定期更新以防止出现重大意外并最终合并。
SVN 中的分支不像 git 中那样容易处理。因此我认为大部分日常工作都应该在主干中完成，只有大的破坏性变化才应该发生在分支中。
注意：这就是我们公司的做法，而且效果很好。
【讨论】：
我发现自己处于类似情况，我们是一个由三人组成的团队，我一直在推动源代码控制，尽管我在这方面的经验有限并且我正在学习中。我发现这篇文章特别有用：http://www.ericsink.com/scm/source_control.html
如果您的团队还没有阅读它，他们绝对应该阅读它 - 这是一个很好的起点。
在他们自己的分支中尝试了每个人，然后合并到主干方法，我可以从我们的错误中告诉你，至少可以说是痛苦和混乱的。如果您是最有经验的人并且他们是新手，那么您很可能是必须承担将所有这些分支合并在一起的责任的人……这不好玩。
到目前为止，每个人从树干上逃跑都是最不痛苦的方式，到目前为止，我想说的是，与我们之前的运营方式相比，这几乎是一种快乐。你们都可以从彼此对单独文件所做的改进中受益，差异将自动更新和合并（除非存在冲突）。它还将让您的团队习惯于修订控制的工作方式，慢慢地，你们都会对它的机制更加熟悉，然后值得探索分支和合并。
简而言之：婴儿步 :-)
从长远来看，它会得到回报。
【讨论】：
这就是我们使用它的方式：
- 所有更改都发生在
trunk - 有什么实验性的吗？分支它，使用它直到你满意为止。合并回
trunk。 - 标记所有主要版本
【讨论】：
我就是这样使用 svn 的，从来没有抱怨过。我认为您的策略取决于您正在开发的软件类型。在我的例子中，它是许多不同客户使用的产品，可用于关键环境（工厂自动化）中的多个不同版本。
- 主干必须始终编译。
- 每个版本都有一个标签
- 所有修复和次要开发都必须在主干上完成。
- 主要版本的每个版本都有一个分支。
- 所有主要开发都在一个专门的分支上完成。它们在 QA 之后合并。
- 所有修复也在支持版本的每个分支上完成。
它可能看起来很重，但运行良好，并且可以为许多用户提供服务。对于这种关键软件，每个人都想确定新版本里面有什么。
如果你没有这种约束，1 到 3 可能就足够了。使用分支有时会很痛苦。
如果您需要并行运行多个主要项目，您可能必须考虑使用 DVCS，例如 mercurial 或 git。
【讨论】：