如何使用VCS正确管理提交，防止功能冲突以及管理依赖关系？

与大型团队合作已成为一个烦人的因素：如何管理签入，防止功能冲突以及通过源代码管理正确管理依赖项？

目前，在我的工作场所中，我们使用TFS 2008，并将在12月初迁移到TFS 2010。首先，任何源代码控制总比没有源代码要好，但是有人发现有什么方法可以防止源代码控制历史中的多次签入和回滚？在实现新功能时，一旦您很高兴地重新合并到中继线中，易失性中继线是最好的解决方法吗？

我真的很想听听其他人的经验，也许还有一些管理源代码管理的最佳实践。

TFS？跑山！尽快移开。它可以做很多不同的事情，但没有一个能比现有的最佳工具好。

不过实话说：

一旦有了一个不错的版本控制系统（SVN，GIT等），我建议为分支机构管理设置规则，例如何时创建分支机构，何时创建分支机构，何时合并，谁以及更多。

直到最近，我们只使用一个分支进行新开发（“ trunk”）。对于发行版，我们将创建一个主干分支。最终质量检查将在该分支机构中完成，一旦完成，我们将发布（我们按月发布）。

我们已改用“后备箱中没有垃圾”的概念，以降低计划风险。这个概念基本上包含一个规则，通过该规则，您可以创建与主干分开的开发工作分支。例如，您可以为某个功能，一个小型开发团队或类似人员建立一个单独的分支。我们使用“史诗”来描述某个小功能或该功能的可释放部分，并为每个史诗创建一个分支。每天至少一次将所有来自主干的更改合并到史诗般的分支中。关键是通过版本控制或单独的工具（例如三向合并）提供良好的合并支持。史诗的质量检查将在史诗分支上进行。一旦通过，史诗般的分支将合并到主干中，并运行集成测试。我们仍然有发布分支。

有了史诗般的分支机构，我们现在可以从主干中释放出来，并包括所有成功合并到主干中的史诗，从而大大降低了计划风险。未完成的史诗将错过公共汽车，并将在下一个版本（下个月）发布。

当然，这可能仅在我们的环境中有效。您很有可能会遇到与我们不同的因素，这些因素会影响分支机构管理的最佳选择。

例如，如果您的团队中有很多人在远程工作，而不总是连接到版本控制服务器，那么您将要使用支持分布式模型的版本控制系统。GIT和其他一些将属于此类。据我所知，TFS需要连接到服务器才能使文件可写（在2010版中已修复？）。

我希望我能够证明没有“一刀切”的东西。从特定分支机构的流程开始，确定需求，最后选择最适合您需求的工具。也许是TFS，也许不是。

我建议每个功能一个分支，因为它在决定要发布和推迟哪些功能时具有很大的灵活性。

在您所处的情况下，效果如何取决于您的VCS处理分支的能力以及更重要的是合并。像Git和Mercurial这样的DVCS使这项工作相对琐碎。SVN更少。尽管我已经阅读了很多有关TFS的文章，但我设法避免了TFS，恐怕大多数情况下都是免费的。如果您对TFS感到困惑，请根据每个分支的一项功能进行一次小型试用版发布，并查看合并的效果如何。

首先，免责声明。很难说什么是管理您的源的最佳方法，因为我们不了解您的团队每天的工作方式。

通常，最好在后备箱上工作。对于每个主要发行版，请对其进行分支-以便该分支版本的错误修复在分支上，可以将其合并回主干。所有开发人员都在主干上工作并定期提交代码（每天最少一次）。

定期合并新代码可以最大程度地减少在大规模集成阶段合并大量代码的痛苦。通过散布疼痛，您会感觉减轻。您的团队成员提交代码的次数越多，合并的次数就越少-因为他们将始终处于最新消息源中。

我从未使用过TFS 2008/2010，但是从我在各个论坛上所读到的内容来看，使用TFS进行版本控制存在很多负面影响。到目前为止，这使我对TFS保持清醒。

我目前正在使用SVN和Git，我发现它们都适合小型团队或单人团队，但个人不会为大型团队推荐SVN。

我一直在关注PlasticSCM，并将在不久的将来尝试这样做。

很抱歉没有回答您的特定问题，如果我的特权允许我会发表评论。

我认为git使所有其他源代码控制软件过时了。分支和合并很容易，并且如果有问题，它将得到控制，但是通过鼓励频繁的提交，分支和合并，可以避免很多问题。每个用户都会得到一份完整的回购副本（可以删除它，但是我使用的是相当庞大的代码库，这不是问题），因此有一些自动备份功能。提交/推送/拉动很快，最重要的事情之一是它打破了文件名和跟踪之间的耦合。文件数据（包括名称和路径）是树节点引用的数据blob，与路径无关。这不仅更安全，而且诸如SVN之类的某些“永不这样做”问题也不成问题。它可以用作传统的集线器配置或对等网络，并且可以在同一设置中自由混合使用。从密码学上讲，它可以防止未记录的插入。而且速度非常快。

我发现我现在一直在家里使用它，只是为了跟踪文档并在计算机之间同步它们，因为与将其备份到服务器或保存在文件服务器上相比，它更易于提交和推送到文件服务器。

缺点是学习曲线有点陡峭，因为它以微妙的方式破坏了人们习惯使用源代码控制的所有规则，但是学习曲线却很短。

我们真正遵循并为我们提供了很多帮助的一些良好做法：

1）确保您在本地没有该文件的可写副本，并且始终要签出进行编辑。（如果有时您必须在本地工作，请尝试在EOD之前将其合并到源代码管理中。）

2）在任何重要的里程碑之后，定期为文件添加标签。

3）提供良好的结帐或签到注释。这在您查看时会有所帮助，有时您不必打开并在版本之间进行比较。

您如何管理签到并防止功能冲突并通过源代码管理正确管理依赖项？

从我的观点来看，这是两个因素的任务：您必须从技术（良好，轻松和防弹的分支等）和管理（行之有效的策略“什么”，“何时”，“如何”）方面来做。ALM中的两层甚至三层分离代码：类似“稳定”（通过单元测试），“不稳定”（每个包含的功能均已完成，但是作为产品的应用有集成后问题/是的，可能会发生 /）和“工作正在进行中”。这样，适当的项目经理可以减少共同开发人员对单独工作的干扰。

TFS（我不使用，不会使用和不会使用）在其源代码管理管理方面存在一些AFAIK基本问题。我只在这里链接到詹姆斯·麦凯的一些文章：

• Team Foundation Server是版本控制工具的Lotus Notes
• Team Foundation服务器中的无基础合并–为什么？

这里有一篇非常不错的近期文章，它简洁明了地比较和对比了使用源代码管理的几种不同方式：Source Control Done Right。

我认为使用源代码管理没有任何一种策略/最佳实践。长期合作的成熟团队在该领域的“痛苦”要小得多，即使他们没有完全遵循流行的“最佳实践”。

至于哪些工具...几乎没有关系。真正重要的是，让团队中的每个人都在使用方面保持一致。这意味着每个人都需要了解代码行的管理方式以及期望执行的操作。而且，实际上，您通常没有选择使用哪种工具的选择。充分利用您正在使用的任何内容。