传统团队使用分布式版本控制的头痛？

尽管我在个人项目中使用并喜欢DVCS，并且可以完全看出它如何使其他人对项目的贡献进行管理（例如，典型的Github方案），但对于“传统”团队而言，似乎存在一些问题。 TFS，Perforce等解决方案采用的集中式方法。（“传统”是指办公室中的一组开发人员在一个项目上工作，没有一个人“拥有”，可能每个人都在使用相同的代码。）

我已经预见了其中的几个问题，但请考虑其他因素。

在传统系统中，当您尝试将更改签入服务器时，如果以前有人签入了冲突的更改，则您将被迫合并，然后才能签入。在DVCS模型中，每个开发人员都会签入他们的证书。本地更改，并在某个时候推送到其他回购。然后，该仓库中有一个由2个人更改的文件分支。看来现在必须由某人负责处理这种情况。团队中的指定人员可能没有足够的整个代码库知识，无法处理所有冲突。因此，现在增加了一个额外的步骤，即有人必须与这些开发人员之一联系，告诉他进行合并并再次推送（或者您必须构建一个自动化该任务的基础结构）。

此外，由于DVCS倾向于使本地工作变得如此便捷，因此开发人员很可能会在推送之前在其本地存储库中积累一些更改，从而使此类冲突更加常见和更加复杂。

显然，如果团队中的每个人都只在代码的不同区域工作，这不是问题。但是我很好奇每个人都在使用相同代码的情况。集中式模型似乎迫使人们快速而频繁地处理冲突，从而最大程度地减少了进行大型痛苦合并或让任何人“警惕”主仓库的需求。

因此，对于与办公室中的团队一起使用DVCS的那些人，您将如何处理此类情况？您是否发现您的日常（或更可能是每周）工作流程受到负面影响？在工作场所推荐DVCS之前，我还有其他注意事项吗？

我们已经使用Mercurial大约一年了。尽管您提到的问题确实存在，但到目前为止，对我们而言，全面采用最大的挑战是进入本地存储库的DVCS心态（=经常提交）。“一旦精炼代码就提交”的旧心态可能很难让人接受。走。

你说：

在DVCS模型中，每个开发人员都在本地检查其更改，并在某个时候推送到其他回购。然后该回购包含该文件的一个分支，该分支已被2个人更改。看来现在必须由某人负责处理这种情况。

默认安装的Mercurial会阻止此行为。如果在没有额外确认的情况下在远程仓库中创建多个头部，则不允许推送。对于日常活动，我们避免这样做。（Git命名了头部，每个头部只有在完全合并了先前版本的情况下才可以更新，而无需额外确认，因此不会再次出现这种情况。其他DVCS也具有类似的保护。）

因此，在每个工作日结束时，需要预留一些时间进行提交，这实际上是这些活动：

1. 提交本地更改。
2. 从中央仓库中拉出。
3. 合并（和提交合并。）
4. 推送到中央仓库。

这样可以将合并活动保留在最近正在处理此代码的人员上，并且应该能够像其他任何人一样快速地集成他们的更改。

正如问题中指出的那样，这实际上只会在两个人在同一代码区工作时增加工作量。如果真是这样，那么使用DVCS仍然有更多好处，因此对于那些开发人员而言，收益是显而易见的。（其他好处包括，每个开发人员都可以分别提交代码并使用自己的存储库进行操作，而不会妨碍其他开发人员。）

您提到的另一个问题：

此外，由于DVCS倾向于使本地工作变得如此便捷，因此开发人员很可能会在推送之前在其本地存储库中积累一些更改，从而使此类冲突更加常见和更加复杂。

这不会为我们造成合并问题，但可能会产生其他问题：

DVCS的灵活性意味着可以实现许多不同的工作流程，但是其中一些工作是不负责任的。使用DVCS，对清晰的过程或程序的需求增加。保持本地更改的活动可能适当，也可能不适当，这取决于许多因素。

例如：开发人员可以在几周的空闲时间内从事宠物功能吗？在某些环境中，鼓励这样做，在某些情况下这是不合适的，所有更改应尽快集中。但是，如果开发人员将更改保留在本地，那么他们肯定会希望撤消任何相关更改，以确保他们的工作将在最新的通用版本中继续正常运行。

当遇到麻烦时，软件版本或部署通常来自中央存储库，因此开发人员需要在那里进行更改以进行测试和部署。

那是我的故事，我坚持了至少几分钟...

您的问题的前提似乎围绕“合并困难，必须避免合并”。DVCS系统消除了这一障碍，实际上它们做得更多，拥护着合并的思想-因此，您不应该害怕合并和合并冲突，因为与集中式工具不同，DVCS工具通过设计来支持它。

正如Jamie F的出色回答所指出的那样-定期（每天）完成的Commit-Pull-Merge-Push工作流程意味着，如果您在进行其他工作，则可以及早看到-只要它可见，就可以对其进行管理。

您描述的问题更多地与您如何选择使用工具有关。

在本地使用SVN和GIT几年之后，我们在6个月前从SVN切换到GIT。没有人会回去，痛苦的合并冲突已成为过去。“小而常”的口头禅是关键。

当我在使用git的团队工作时，经验法则是：在私有分支上工作，然后，当您准备将工作提供给团队的其他成员使用时，请在推送之前将分支重新建立为master。（然后验证您的分支。）

该策略意味着master是一系列线性提交，并且所有集成问题都在分支机构公开之前得到修复。

像SVN这样的工具强烈鼓励紧密集成的工作方式。

即频繁提交到共享分支（主干或开发分支）。

这对于我经历过的大多数公司开发环境都是可以的，通过广泛集成测试，回归测试和单元测试所支持的持续集成的使用，进一步促进和鼓励了这一工作（帮助单个开发人员获得信心，他们没有失败任何通过他们的更改）。

DVCS使您可以自由地进行更独立的工作，这在某些情况下确实是您所需要的，并且（倍受鼓吹的）改进的合并支持不会对您造成任何损害。

一直困扰着我的忧虑是：随着自由的来临，诱惑来使用这种自由。

当然，根据我（有限的）经验，与以前的职位（使用SVN，CVS和P4的职位）相比，我在目前的团队（使用Mercurial）中独立工作的时间要多得多。

这仅部分归因于该工具，但我认为这是一个合理的观察结果，因为没有令人信服的理由花费更多的精力进行沟通和协调，人们将趋向于孤立地工作。

这不一定是一件坏事，但我认为这是需要考虑的事情。

具有git / mercurial类型版本控制的事情是经常提交，并在代码良好时推送到集中式服务器。这样做的一大好处是，它会创建小的补丁程序，在发生冲突时很容易应用。另外，您的工作流程应符合以下方面：

1. 许多本地提交
2. 从服务器拉
3. 推送到服务器

从服务器的拉动可能会产生冲突，但是要解决此问题，很多时候所需要做的只是简单的重新设置基础，而不是合并。我认为，这将使主线历史记录保持整洁，并消除很多冲突。

当您从同事的本地存储库中提取数据时，也会发生这种情况，因为可能会发生两种情况。要么他先推送到服务器，这很好，因为您已经有了他的补丁程序，应该不会发生冲突，或者您先推送，这意味着他只有在拉动时才能得到您的补丁程序。

当然，有时合并是一个更好的解决方案，例如，如果您正在处理应合并到母版中的功能分支，则此示例为例。

在您的工作流程中，您所谈论的是人们必须明确地去找另一个开发人员并告诉他解决冲突，但这不是必须的。中央服务器是“老板”，您应该主要针对的是它。如果您的更改适用于中央存储库，那么您就可以了。如果不是这样，则解决冲突是您的工作，这可能需要与您冲突的开发人员来帮助您理解他/她的更改。当您尝试从服务器拉取/重新设置基准站时，会看到此内容。因此，当您从服务器中拉出时，请愉快地提交，并处理冲突。

使用非锁定的集中式或分布式系统时，使用集中式存储库的原理是相同的：

• 在集中式系统中，您：
  1. 从主线获取最新版本（subversion中的“ trunk”，git中的“ master”，...）
  2. 修改文件
  3. 使用“更新”命令从主线合并最新版本的修改
  4. 提交主线
• 在分布式系统中，您：
  1. 从主线获取最新版本
  2. 修改文件
  3. 本地提交
  4. 将修改与来自主线的最新版本合并，并在本地提交结果
  5. 推送至主线。

没有任何分布式版本将允许您推送不会完全合并先前的主要修订版本的修订版本（没有特殊的替代；有时会很有用），因此不执行合并步骤就不会通过（因此不会有人发布两个版本）您必须将其合并）。

现在注意，除了术语外，其中四个步骤相同，但是分布式系统增加了一个额外的步骤“ 3.本地提交”。此步骤的最大优点是，当更新/拉动产生冲突并且您不确定如何解决冲突或错误解决冲突时，您可以返回并查看所做的操作并重做合并。Subversion不会记住任何一个，因此，如果您在解决更新时犯了一个错误，那您就很费力。

至于累积变更，人们也倾向于使用集中式系统来完成。尤其是如果您必须经常在功能之间进行切换（例如中断一些较长的工作来修复错误或进行客户急需的一些调整），人们常常会因为未完成更改而需要将更改保留在本地。因此，最好是系统至少支持使其有意义。

无论哪种情况，都需要通过团队中适当的准则和沟通来解决这些问题，而不是通过工具来解决。使用更灵活的工具，准则会更重要，但是更灵活的工具可以更好地解决各种极端情况。