一个适合该描述的人的很好的例子可能是项目经理。

前几天我的老板问我：“这个Github东西是什么，为什么它很重要？” 他有一些专有项目，所以他需要私人托管，我发现自己无法尽力解释：VCS使协作变得微不足道，提供了所有数据的历史记录和“备份”，并允许您在代码库中记录基本更改。 。在我的脑海中，我想：“几乎就像您必须使用DRVS来真正理解它的好处一样”。

我最终将他指向BitBucket，因为它们为您提供了无限的私有存储库（我什至不得不解释什么是存储库）。

有没有人有一个非常好的具体示例，说明VCS如何节省了资产或使生活更轻松等-基本上，您如何将DVSC出售给不熟悉编程但又不是专业程序员的人？

版本控制非常适合（至少）三四个方面：备份，开发人员之间共享代码，查找+修复错误以及进度跟踪。

1. 备份。如果没有别的，它是类固醇的后备。您具有完整的开发历史记录，每次提交都是带有ID（修订号），描述，时间戳，用户信息的整个代码的快照。比较修订之间的文件很简单。如果没有其他问题，它比简单备份（仅发送和存储文件更改）要快，并且包含有用得多的元数据。为什么要重塑呢？

2. 在开发人员之间共享代码。如果您至少有两个开发人员同时在同一个产品上工作，那么我看不到任何其他可靠可靠地共享代码更改并将其合并的方法。通过邮件发送拉链？

3. 查找并修复错误。当您的客户报告特定产品版本的错误时，您可以快速获取实际的源快照以进行复制和修复。如果您的来源与客户不同，则很难重现错误。您是否要求他们发送可执行文件以便您可以对其进行反汇编？此外，如果在确定错误原因时遇到问题，则可以使用VCS查明引入错误的确切版本。

4. 进度跟踪。当您以快照形式提交工作时，它使您（和您的经理）可以跟踪功能实现的进度以及未解决错误的状态。VC系统也易于与跟踪系统和连续集成系统集成。除非您拥有VCS，否则几乎不可能保持除业余项目之外的其他任何项目的质量水平。

一旦你都同意，任何软件开发应该永远在VCS外完成（我不会错过它，即使是业余爱好项目），那么你可以讨论（稍微复杂）DVCS的功能（以下部分来自公然复制维基百科）：

• 每个用户都有自己的存储库本地副本（实际上是备份副本）
• 即使未连接到网络，也可以使用户高效地工作
• 由于不涉及网络，因此可以使大多数操作更快
• 允许参与项目而无需项目主管部门的许可
• 允许私人工作，因此用户甚至可以针对不想发布的早期草稿使用其版本控制系统
• 避免将单个物理机视为单点故障

“您发现“撤消”按钮有用吗？哦，您同意我们应该使用版本控制吗？”

当我开始使用版本控制时，我感兴趣的主要功能是能够“撤消”我的错误并返回到以前的版本。每个人都可以欣赏撤消按钮。授予版本控制权还可以做更多的事情。

从基础开始：

首先，VCS保护开发人员彼此之间和彼此之间的保护-如果它仅能使两个或多个开发人员相对安全地在同一代码库上工作，那么它将具有巨大的价值（而我曾在一个团队中天的工作已被一些粗心的复制所覆盖）。

其次，它提供了一个审计跟踪-历史记录-您可以返回并查看谁更改了内容和时间，还可以返回并检索已删除的代码，因为不再需要它，或者在以后发现需要它时就可以使用它。所有。

第三，它为您提供了一个参考点-明确的源代码是提交的代码（在现实世界中，它稍微复杂一点，尤其是对于DVCS，但为了便于讨论，它已经足够接近了）。如果正确备份了存储库，则应该保护公司的资产。

如果一位经理在上述时间内找不到足够的价值来寻找另一位经理，那这三件事应该是出售VCS的“条件”。

一旦出售了VCS（毕竟，这些VCS仅供开发人员数量大于零的开发团队使用），然后是DVCS为什么超过SVN或TFS的问题，以及是否工作的另一个问题内部使用或使用托管服务（例如Kiln或Bitbucket或Github（如果您付费则私有））则更深入，并且更依赖于上下文。

VCS

只需解释一下备份的概念即可。备份使您可以及时查看给定时刻的工作。告诉VCS程序员以前是如何强制性地复制他们的整个项目的，通常是为了保存他们拥有的每个良好而稳定的版本，因此，当情况变糟时，他们可以很好地参考何时工作，将它们与最新的东西进行比较，看看在哪里他们或其他人搞砸了，只需查看差异而不是整个项目的两个备份，就可以更轻松地解决它。

总结：VCS使您可以保存工作的备份，并使您能够仅查看备份之间的差异。

DVCS

至于分布式版本控制，请解释一下典型的版本控制过去是如何需要服务器和互联网连接的，每个人都对此感到厌倦，因为它速度较慢并且每个人都在一个备份上工作，如果一个人搞砸了，就会给每个人搞砸该项目，因此，有了分布式版本控制，每个人都可以在没有Internet连接的情况下在自己的计算机上进行自己的备份，并且每个人都很高兴，因为在工作时没有人会打扰他们的备份，他们担心以后会共享工作。

另一个不错的好处是，与只有一个备份的集中式VCS不同，如果带有备份的计算机着火了，那么还有其他完整的备份需要解决（每个开发人员至少要备份一个）。

总结：DVCS 使您可以在自己的备份中进行工作，而不必每个人都挤在单个服务器上，彼此烦恼，并且让您不必担心其他事情在完成工作之后就会发生变化。同样，如果主存储库机器着火了，也不会发生任何事情。

我主要与工程师合作（本质上不是开发人员，但是他们确实写代码）

当我向他们介绍版本控制时，主要要点是可以撤消和管理您的代码/文档/任何内容，并简化与其他开发人员/编写者/其他人员的协作...

那是一个很好的卖点-这也是我在整个工作中都使用VCS的主要原因，还有其他优点：拥有历史记录，可以轻松备份的回购...

他们中的大多数人都喜欢这个想法，并发现它非常有用，可以将其用于他们的项目中（特别是如果他们涉及与其他工程师的协作时）。

当试图说服任何人时，您总是需要尝试从他们的角度出发。

您的项目经理有一个简单的目标-按时，按预算完成项目。

如果您当前不使用版本控制，那么您的开发团队正在解决版本控制手动解决的问题。所有这些问题均已由其他答案很好地列举，因此在这里我将不再赘述。

您需要做的是向您的项目经理说明，团队X每周要花费几个小时来手动解决GIT可以自动解决的问题，例如花费0.1 * X开发人员的小时数。

不要以GIT使您的生活或开发人员的生活更轻松的原因来接近它，而是从GIT可以更快，更便宜地交付软件的角度来对待它。

我喜欢@ Buttons840将其描述为代码库的撤消按钮。将它与Word或InDesign的“跟踪更改”功能的（令人沮丧的）版本进行比较也可能会有所帮助。以我的经验，它绝对减少了一个人去告诉其他人在接下来的几个小时不要触摸文件X，Y和Z的需要，这对于完成任务很方便。

我还发现细粒度的版本信息对于修复/解决错误非常有用。我将SVN版本号（通过$ Id属性）存储在几乎所有生成的数据文件中。这样，如果（何时？）发现了一个错误，识别具有潜在问题的文件并重新生成它们或让其他代码补偿该错误就很简单了。

如果不使用版本控制，您如何知道如何重建生产环境？

1不同的人（测试人员，开发人员）将在不同的地方寻找相同的信息

导致DUPLICATE DATA不同步。
版本控制是消除重复数据的最简单方法。

2如果确实使用版本控制，则很容易确保生产环境与版本控制中的内容匹配。

这样可以很容易地检测出问题是由于错误的构建（产品与版本控制不匹配）还是设计或编码错误（产品与版本控制相匹配）引起的。

通过版本控制，可以轻松地为每个测试环境分配发行版号，并且您自然希望产品的发行版号比测试或开发的发行版低，并且测试的发行版号比开发或开发低。如果不是这种情况，则说明代码的某些部分没有经过正确的测试。

同样，如果您发布软件，则VCS的以下功能非常重要：假设您的客户发现了错误。该软件的当前开发状态​​可能与客户所拥有的版本完全不同。也许该错误已在当前修复，但可能尚未修复，但是无论如何，当前的软件都不处于可以直接将其交付给客户的状态。

使用VCS可以很轻松地返回到交付给客户的版本，修复他所请求的错误，进行构建并向他发送修订版。所有这些都不会干扰当前的开发，而不必向他提供一个版本，该版本具有未完成/不稳定的功能或由于未完成的新开发而引入的其他错误。

此外，如果该错误仍然存​​在，VCS可使您轻松地将此修补程序移植回新的开发分支。

通过严格的纪律，对于一支非常小的团队，您可能不需要VCS就能解决此问题，但是使用一个VCS可以节省您的时间，并最终节省金钱。最有可能还会帮助您留住客户。

如果您的公司有两个以上的人员，则您可能有一个Word文档或excel文档位于由多个人员编辑的某个地方。有时，这些人会在本地制作副本，以进行商务旅行等。或者每次更改后，都会通过电子邮件将文档发送出去。

如果您有这样的文件，则说明某些人的修改过去已经丢失，或者将来会丢失。或者人们认为他们已经丢失了更改，但无法证明这一点。或者他们想看看谁在何时何地做出了什么改变。这正是VCS解决的问题。

在选择开源软件/库时，拥有DVCS存储库绝对是选择标准中的一个优势。

1）我们可以克隆整个存储库，无需担心该项目或其网站已经关闭。

2）人们更愿意通过请求请求来提交错误修复，从而更快地解决紧急问题。