为什么每个人都集中使用Git？

我过去的两家公司都使用Git进行版本控制。据我所知，似乎有90％的公司使用Git而不是其他版本控制系统。

Git的最大卖点之一就是它是去中心化的，即所有存储库都是平等的。没有中央资料库/真相来源。这是Linus Torvalds所倡导的功能。

但是似乎每个公司都以集中方式使用Git，就像一个公司会使用SVN或CVS。人们总是从服务器上（通常是在GitHub上）获得一个中央存储库。我从未见过或听说过（以我有限的经验）人们以真正去中心化的方式使用Git，即按自己认为合适的方式推和拉到其他同事的存储库。

我的问题是：

1. 人们为什么在实践中不使用分布式工作流程？
2. 以分布式方式工作的能力对现代版本控制是否甚至很重要，还是听起来不错？

编辑

我意识到我在最初的问题中没有理解正确的语气。听起来好像我在问，当分布式版本控制系统（DVCS）如此明显地优越时，为什么有人会集中工作。实际上，我想说的是，我对DVCS完全没有任何好处。然而，我经常听到人们鼓吹它的优越性，而现实世界似乎同意我的观点。

啊，但是实际上您正在以分散方式使用git！

让我们比较一下git的前身svn。颠覆只有一种“回购”，一种真理的来源。当您进行提交时，它是到一个其他所有开发人员也要提交的中央集中存储库。

这种工作奏效了，但是却导致了许多问题，最大的问题是可怕的合并冲突。事实证明，这些问题从烦人到噩梦无处不在。由于有一个事实来源，他们有一个令人讨厌的习惯，那就是使每个人的工作陷入停顿，直到他们解决。git确实存在合并冲突，但它们不是停止工作的事件，并且更容易，更快速地解决；它们通常只影响涉及冲突更改的开发人员，而不影响所有人。

然后就是整个单点故障，以及随之而来的问题。如果您的中央svn回购以某种方式失效，那么您将全被搞砸，直到可以从备份中还原它为止；如果没有备份，那么您全都被搞砸了。但是，如果“中央” git存储库丢失，则可以从备份，甚至从CI服务器，开发人员的工作站等上的存储库的其他副本之一恢复。您可以这样做是因为它们是分布式的，每个开发人员都有一份一流的回购副本。

另一方面，由于您的git repo 本身就是一流的repo，因此当您提交时，您的提交将转到您的本地repo。如果要与他人共享或作为真理的主要来源，则必须通过推向遥控器来明确地做到这一点。然后，其他开发人员可以在方便的时候撤消这些更改，而不必经常检查svn来查看是否有人做了将其破坏的事情。

您无需通过直接推给其他开发人员，而是通过另一个远程回购间接向他们推销更改，这一事实无关紧要。从我们的角度来看，重要的部分是您本地的回购副本本身就是一个回购。在svn中，真理的主要来源是通过系统的设计来实现的。在git中，系统甚至没有这个概念。如果有真相的来源，则由外部决定。

当构建服务器（您正在使用CI，对吗？）创建构建时，它从何处提取？当然，您可以争辩的集成构建不需要“一个真正的仓库”，但是分发构建（即您提供给客户的东西）肯定需要。

换句话说：碎片化。如果您指定一个存储库为“该”存储库并任命负责审核请求的监护人，则您可以轻松地满足“给我一个软件版本”或“我是团队的新手，代码在哪里？”的要求。

DVCS的优势与其说是对等方面，不如说是分层的。我修改我的工作区，然后提交到本地。功能完成后，我将合并提交并将其推送到远程。这样，在创建拉取请求并将项目管理员将其合并到One True存储库中之前，任何人都可以看到我的暂定代码，提供反馈等。

使用传统的CVCS，您要么提交，要么不提交。这对于某些工作流程是很好的（我将两种VCS类型用于不同的项目），但对于公共或OSS项目却一无所获。关键是DVCS包含多个步骤，这些步骤需要做更多的工作，但是提供了一种更好的方法，可以通过内置过程集成陌生人的代码，从而可以更好地查看正在检查的内容。以集中方式使用意味着您仍然可以具有项目当前状态的黄金标准，同时还提供了更好的代码共享机制。

我不知道你是怎么定义“每个人”，但我的团队和“服务器上的中央回购” 还时不时我们从其他同事的回购拉不经由中央回购打算。当我们这样做时，我们仍然会通过服务器，因为我们选择不通过电子邮件发送有关该地点的补丁，而不是通过中央存储库。通常，当一个小组正在就某个特定功能进行协作并希望彼此保持最新状态时，通常会发生这种情况，但是到目前为止，仍然没有兴趣向所有人发布该功能。自然，由于我们不是秘密仓库工作人员，因此这种情况不会持续很长时间，但是DVCS可以灵活地执行最方便的事情。我们可以根据喜好发布功能分支，也可以不发布。

但是，肯定的是，有90％以上的时间我们通过中央存储库。当我不关心任何特定更改或特定同事的工作时，它更方便且扩展性更好，它可以提取“已在中央仓库中审核的所有同事的更改”，而不是分别从N中提取更改。同事。DVCS并不试图阻止“从主仓库中提取”是最常见的工作流程，而是试图阻止它成为唯一可用的工作流程。

“分布式”意味着就git软件而言，所有存储库在技术上都是等效的，但并不能因此就开发人员和我们的工作流程而言，它们都具有同等重要的意义。当我们向客户或生产服务器发布产品时，我们使用的存储库与仅由一名开发人员在其笔记本电脑上使用的存储库具有不同的意义。

如果“真正去中心化”的意思是“没有特殊的回购协议”，那么我认为那不是Linus拥护的意思，因为事实上，他确实保留了特殊的回购协议，而这在大事务中比我昨天制作了一些Linux的随机克隆，计划仅用于开发一些小补丁，然后在他接受补丁后将其删除。git不会让他的仓库比我的仓库特权，但是Linus会给它一个特权。他的“是Linux的当前状态”，不是。所以自然而然地倾向于改变通过莱纳斯。DVCS相对于集中式VCS的优势并不在于一定不存在事实上的中心，而是变化不必经过任何中心，因为（冲突允许）任何人都可以合并任何东西。

由于DVCS系统是分散式的，因此它们也被迫提供某些方便的功能，其依据是您必须在本地必须具有完整的历史记录（即仓库）才能执行任何操作。但是，如果考虑到这一点，就没有根本原因无法配置带有本地缓存​​的集中式VCS，该缓存不会使只读操作的全部历史记录过时（我认为Perforce可以选择此模式，但我从未使用过Perforce）。或者原则上您可以git使用.git/远程安装的文件系统上的目录，以模拟没有网络连接时SVN的“功能”不起作用。实际上，DVCS使管道的功能比在集中式VCS中无法实现的更加强大。这是一种（非常受欢迎）的副作用，并帮助激励DVCS设计，但在这种责任的分配技术水平是不一样的完全下放所有的人的责任。

关于DVCS的本质的有趣之处在于，如果其他人以分布式方式使用它，除非他们直接与您进行交互，否则您可能不会知道它。您唯一可以说的就是您和您的直接队友不使用git。这不需要公司范围内的政策。所以，我会问你，你为什么不，你以分散的方式使用git？

为了解决您的编辑问题，也许您需要一些使用实际集中式版本控件的经验才能体会到这些差异，因为尽管它们看起来可能很细微，但却无处不在。这些是我的团队在集中化VCS时实际上无法完成的所有工作：

• 核心开发人员的清单非常小，可以提交每个微服务的“中央”存储库。其他所有人都可以在分叉中工作并通过拉取请求提交。
• 可以提交多更频繁，每小时通常数次与每天一次或两次。
• 可以出于任何原因创建分支机构，以与同事进行临时协调，每天将其推入并拉出几次，然后准备与较大的团队共享时将其压扁。您是否知道在传统的CVCS中获得类似权限的临时分支的创建有多困难？

冒着说老话的风险，您真的不知道自己有多容易。

我认为您的问题来自于（可理解的）始终保持联系的心态。 即中央“真相” ci服务器始终（或几乎始终）可用。虽然在大多数环境中都是如此，但我至少在一个与之相距甚远的环境中工作。

我的团队几年前曾从事过军事模拟项目。 所有代码（根据法律/国际协议，如果您不穿深色西服的人，如果您不这样做，则必须使用超过10亿美元的代码库）都必须位于与任何 Internet连接物理隔离的机器上。这意味着通常情况下，我们每个人都有2台PC，一台用于编写/运行/测试代码，另一台用于Google东西，检查电子邮件等。这些机器的团队中有一个本地网络，显然没有以任何方式连接到Internet。

“真相的中央来源”是在一个军事基地的机器上，在一个无障碍的地下无窗房间（加固的建筑物，yada-yada）中。那台机器也没有互联网连接。

定期地，将具有git repo的驱动器（包含我们所有的代码更改）（物理地）传输到军队基地（这是几百公里之外）是某人的工作，因此，您可以想象。

而且，在非常大的系统中，您有很多团队。他们通常将各自拥有自己的“中央”存储库，然后再返回到实际的（“神”层）“中央”中央存储库。我知道至少还有1个承包商也用他们的代码执行了相同的git git repo dash。

另外，如果您考虑Linux内核规模的问题，开发人员不只是向Linus自己发送拉取请求。它本质上是仓库的层次结构-每个仓库对于某人/某些团队来说都是“中心”的。

GIT中的断开连接的性质意味着它可以在环境中使用，其中连接的模型源控制工具（即 SVN，为一个）不能使用-或无法作为容易使用。

最终，您正在构建产品。该产品在单个时间点上代表您的代码。鉴于此，您的代码必须在某个地方合并。自然点是从中构建产品的ci服务器或中央服务器，并且有意义的是，该中央点是git存储库。

DVCS的分布式方面始终以分叉的形式出现在开源开发中。例如，我贡献的一些项目被原始作者遗弃，现在有很多分支，维护人员有时会相互拉一些特定的功能。甚至在一般情况下，OSS项目都是通过请求请求来获取外部贡献的，而不是通过允许随机的人员推送访问地面真实回购协议的方式来进行的。

在使用特定的官方发行版构建具体产品时，这不是一个非常常见的用例，但是在F / OSS领域中，这是正常的，也不例外。

为什么每个人都集中使用git？

我们从未见过面，大家怎么说？;）

其次，您可以在Git中找到更多其他功能，但在CVS或SVN中找不到。也许这只是你假设这必须是唯一的特点为大家。

当然，许多人可能会像CVS或SVN这样集中使用它。但是，不要忘了分布式VCS固有的另一个功能：所有副本或多或少都是“完整的”（所有分支和完整的历史记录都可用），并且可以在不连接服务器的情况下检出所有分支。

我认为这是不应忘记的另一个功能。

虽然您无法使用开箱即用的CVS和SVN做到这一点，但是Git可以像以前一样集中使用，没有任何问题。

这样我就可以提交更改，也许可以将正在进行的挤压在一起提交，然后将其工作提取并重新建立到主要的开发分支上。

Git现成的其他功能：

• 密码签名提交
• 变基（重新排序和压缩提交；编辑提交，而不仅仅是消息）
• 采摘樱桃
• 分裂历史
• 本地分支机构和隐藏更改（在Wikipedia中称为“搁置”）

另请参阅Wikipedia中的这三个表-版本控制软件的比较：

• 特征

• 基本命令

• 进阶命令

再一次，也许分散的方式不仅仅是让人们使用它的功能。

1. 人们为什么在实践中不使用分布式工作流程？

任何在Bitbucked，GitHub等上贡献或托管更大项目的人都会做到这一点。维护者保留“主”存储库，贡献者克隆，提交并随后发送拉取请求。

在公司中，即使有小型项目或团队，当他们要么外包模块，也不希望外部人员在不事先审查其更改的情况下修改其神圣的开发分支时，也可以选择使用分布式工作流。

2. 以分布式方式工作的功能对现代版本控制是否重要，...

与往常一样：这取决于要求。

如果适用任何点，请使用分散式VCS：

• 想离线提交或浏览历史记录（即在假期中完成山间小屋的子模块）
• 提供中央存储库，但希望保留“真实的”存储库以查看更改（例如，针对大型项目或分布式团队）
• 想要提供整个历史记录（副本），并偶尔提供分支，同时防止直接访问中央仓库（类似于第二个仓库）
• 想要版本化，而不必远程存储或建立专用存储库（尤其是使用Git git init .进行版本化就足够了）

还有更多，但四个就足够了。

...还是听起来不错？

当然，这听起来不错-对于初学者。

灵活性既是祸也是福。而随着Git是非常灵活的，它几乎总是远远的典型情况太灵活。具体来说，大多数Git项目不是Linux。

因此，明智的选择是在实施Git时消除一些理论上的灵活性。从理论上讲，存储库可以形成任何图，实际上，通常的选择是一棵树。使用图论，我们可以看到明显的好处：在存储库树中，任何两个存储库都共享一个祖先。在随机图中，祖先的想法甚至不存在！

但是，您的git客户端几乎可以肯定默认为“单个祖先”模型。节点具有单个祖先（根节点除外）的图恰好是树。因此，您的git客户端本身默认为树模型，因此为默认存储库。

业务逻辑奖励中央服务器。对于几乎所有现实的业务场景，中央服务器都是工作流的基本功能。

仅仅因为您有能力执行DVCS，并不意味着您的主要工作流程就必须是DVCS。当我在工作中使用git时，我们会以集中方式使用它，除了那些奇怪的奇怪情况，在这些情况下，分布式的位对于保持事物的前进是必不可少的。

事物的分布式方面很复杂。通常，您想使事情保持顺畅和轻松。但是，通过使用git可以确保您可以访问分布式端，以处理将来可能出现的恶劣情况。

对于同事来说，要从我计算机上的git存储库中提取信息，意味着我需要在根级别运行git守护程序作为后台任务。我非常反对在自己的计算机上或在公司提供的笔记本电脑上运行的守护程序。最简单的解决方案是“否”！对于同事来说，从我的计算机上的git repo中提取信息也意味着我的Internet地址需要固定。我旅行，在家工作，偶尔在办公室工作。

另一方面，VPN连接到公司站点并将分支机构推送到中央存储库只需不到一分钟的时间。如果我在办公室，甚至不需要VPN。我的同事可以轻松地从那个分支中撤出。

第三，我的本地git repo是功能齐全的存储库。我可以提交新工作，为实验工作创建新的分支，并在弄乱事物时恢复工作，即使当我正在空地中空飞行30,000英尺的飞机上工作时。尝试使用集中式版本控制系统来实现。

复杂：

使用中央存储库，典型的工作流程可能是

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

关于O（1）中的开发人员数量的复杂性。

相反，如果每个开发人员都有他们自己的master分支，则对于开发人员0而言：

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

对等方法是O（N）。

一致性：

现在考虑Alice的master分支和Bob的master分支之间是否存在合并冲突。N个开发人员中的每个开发人员都可以以不同的方式解决冲突。结果：混乱。有一些方法可以实现最终的一致性，但是在这种情况下，所有开发人员的时间都会浪费掉。

简单：

公司是具有集中式工作流程的集中式组织。

每个程序员都有一个老板，他有他的老板，直到CTO。CTO是技术真理的最终来源。无论工具公司使用什么工具，都必须反映此命令链。一个公司就像一支军队-你不能让私人胜过将军。

GIT提供了对公司有用的功能（例如，拉动代码审查请求），仅此一项就使他们切换到GIT。分散的部分只是他们不需要的功能-因此他们将其忽略。

回答您的问题：分布式部分在分布式环境中确实是优越的，例如开源。结果取决于谁在说话。Linus Torvalds并不完全是您的小卧室老鼠，这就是为什么GIT的不同功能对他而言比对以github为中心的公司更重要的原因。

也许是因为他的薪水处理是集中的，所以如果我们希望得到薪水，我们就必须让中央人员感到高兴。

也许是因为我们正在创建一种产品，所以我们需要为客户提供软件的主副本。

也许是因为程序员去一个地方获取每个人的更改要容易得多，而不是必须连接许多不同的机器。

可能是因为错误数据库是集中的，并且必须与代码保持同步。

集中管理是一件好事，直到出现问题为止…..

Git是一个分布式系统，可以从任何最新的存储库中以低成本创建一个新中心（只需将存储库暴露给网络）。Git还允许从开发人员计算机上的存储库中更新过期备份，从而使恢复中心变得更加容易。

当网络中断时，能够在存储库的本地副本上进行合并等工作非常好，但是不需要分布式系统。它只需要一个保留所有数据的本地副本的系统。同样，通过飞行等方式签入代码。

归根结底，分发成本很少，而且有一些好处。如果要对分支机构等进行很好的跟踪，则分发的大部分成本都在所需的区域中。如果要设计一个可在大多数公司中使用的系统，则不会将其设计为分发，而是对源代码进行集中控制显然是主要的“用例”。