我真的很想了解分布式版本控制系统如何改变我们的工作方式。我看了 Linus Torvalds on git 的技术演讲，主要是关于分布式版本控制的力量，他声称它改变了我们的工作方式。
让我们考虑一下 git。喜欢和使用 git 有很多很好的理由，我知道这些很好的理由。我也确信去中心化模型的力量不仅仅扩展到效率和进行本地提交的能力。重要的一点是它允许开发人员同步他们的工作。假设工作还没有提交，我会假设代码(可能)不适合部署，可能会发生变化(如果我很难将我的依赖项耦合到它，那就不好了)，这对我来说听起来像是一个痛苦的世界等待展开。
我有一种感觉，在 Linus 所面对的设置中，去中心化模型工作得非常出色，但这在大多数设置或需求中通常并不常见，而集中式设置本质上是我们在统一网络(即大多数公司设置，尽管我承认这是我的假设)。我们都将东西推回一个中心位置，以便我们可以与他人共享，这种对中心化的需求构成了 github 的基础。我们都依赖中央位置的完整性来提供对我们工作的安全访问并为我们提供支持。
不要回头回答为什么 git 很可爱。它在具有本地提交奖励的集中式模型中表现出色，但我真的觉得我在某处错过了关于分散式工作流程的 Gist ......我可能不得不再次观看视频
更新:
感谢您提出问题，我认为我的观点并没有特别明显。基本上我面临的问题如下。许多公司都设置了中央工作流程。我们在一个统一的快速本地网络上工作。管理集中管理配置的物流稍微简单一些；我们都使用中央存储库，这是我们确保防止磁盘故障和火灾以及您可能担心的任何其他事情的蜜 jar 。将这种必要性纳入您的工作流程会增加您的工作(无论状态如何)最终到达此安全位置的机会。我们共享的几乎所有内容都依赖这个中心位置的网络连接和可用性。我首先想到，也许我们对中央工作流程的热爱只是我们无法掌握如何在微观尺度上使用 DVCS。现在说只使用 git，因为它是集中式变体的超集，我想是可以的。然而，鉴于在大多数情况下我仍然看不到去中心化模型的任何内在特征，我们可能会使用更复杂的工具来解决更简单的问题。可以执行我们已经在做的事情的集中式工具可能具有一定的值(value)。
最佳答案
Git 改进了工作流程，因为 merge 不再是痛苦的事情。
如果您曾经使用 SCM 与多个开发人员在一个项目上合作过，您应该知道 merge 是您必须处理的头号问题。假设您观看了该视频，您已经知道 Linus 竭尽全力详细说明了这个问题，以及为什么这是其他 SCM 的主要问题。
我将重申 Linus 在您说您看过的视频中制作的示例，但这里是:
假设有 3 位开发人员(包括您自己)从事一个包含 3 个部分的项目。就您正在处理的部分而言，你们都是专家。假设您已被指定为存储库的维护者，另外两个开发人员可能会要求您将代码 merge 到主分支中。但!你不是他们所做工作的专家，你也不一定需要了解他们的代码是如何工作的……但你相信他们所做的改变是可以的。使用 git，您可以将 merge 的责任(阅读:工作)转移给它们。一旦他们 pull 了您的代码，将他们的代码 merge 到其中并提交，他们就可以要求您 pull merge 后的代码。
为什么这么好？因为他们做了所有的工作，并且他们明白他们正在 merge 什么。如果没有 git，这个过程无疑会非常痛苦和耗时。
关于git - 去中心化版本控制系统如何改进工作流程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9525281/