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

#1 楼

啊，但是实际上您是在分散使用git的！颠覆只有一种“回购”，一种真理的来源。当您进行提交时，它是到一个其他开发人员也要提交的中央集中回购。

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

然后会出现整个单点故障以及随之而来的问题。如果您的中央svn存储库以某种方式失效，那么您将全被搞砸，直到可以从备份中还原它为止；如果没有备份，那么您全都被搞砸了。但是，如果“中央” git存储库丢失，则可以从备份，甚至从CI服务器，开发人员的工作站等上的存储库的其他副本之一恢复。您可以这样做是因为它们是分布式的，并且每个开发人员都拥有该仓库的一流副本。本地仓库。如果要与他人共享或作为真理的主要来源，则必须通过推向遥控器来明确地做到这一点。然后，其他开发人员可以在方便的时候撤消那些更改，而不必不断检查svn来查看是否有人做了将其破坏的事情。

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

#2 楼

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

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

DVCS的优势并不在于它的点对点，而在于它是分层的。我修改我的工作区，然后提交到本地。功能完成后，我将合并提交并将其推送到远程。这样，在我创建拉取请求并将项目管理员将其合并到One True存储库中之前，任何人都可以看到我的暂定代码，提供反馈等。 。对于某些工作流程（我将两种VCS类型用于不同的项目）很好，但是对于公共项目或OSS项目，它的面目全非。关键是DVCS包含多个步骤，这些步骤需要更多工作，但是提供了一种更好的方法，可以通过内置过程集成陌生人的代码，从而可以更好地查看正在检查的内容。以集中方式使用意味着您仍然拥有项目当前状态的黄金标准，同时还提供了更好的代码共享机制。

#3 楼

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

但是，肯定有90％以上的时间我们通过中央存储库。当我不关心任何特定更改或特定同事的工作时，它更方便且扩展性更好，它可以提取“已在中央仓库中审核的所有同事的更改”，而不是分别从N同事。 DVCS并非试图阻止“从主存储库中拉出”是最常见的工作流程，而是试图阻止它成为唯一可用的工作流程。就git软件而言，但就开发人员和我们的工作流程而言，它们并没有同等重要。当我们发布给客户或生产服务器时，我们用来做的回购与只有一个开发人员在其笔记本电脑上使用的回购具有不同的意义。如果“真正去中心化”的意思是“没有特殊的回购协议”，那么我认为那不是Linus拥护的意思，因为事实上，他确实保留了特殊的回购协议，这在大事情上比我昨天制作了一些Linux的随机克隆，计划仅用于开发一些小补丁，然后在他接受补丁后将其删除。 git并未将其回购权授予我的特权，但Linus对其授予了特权。他的“是Linux的当前状态”，不是。因此，变化自然会贯穿Linus。 DVCS相对于集中式VCS的优势并不是要有一个事实上的中心，而是因为不必（因为冲突允许）任何人都可以合并任何东西，所以更改不必经过任何中心。

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

#4 楼

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

要解决您的编辑问题，也许您需要一些实际的集中版本控制经验才能体会其中的差异，它们看起来微妙，无处不在。这些是我的团队在集中化VCS时实际上无法完成的所有工作：每个微服务的仓库。其他所有人都可以用分叉的方式工作并通过请求请求进行提交。
可以更频繁地进行提交，通常每小时执行几次，而不是每天一次或两次。 ，然后每天将其推入并拉出几次，然后准备与较大的组共享时将其压扁。您是否知道要获得许可才能在传统的CVCS中为类似的内容创建临时分支有多难？

冒着听起来有些陈旧的风险，您真的不知道你有多容易。

#5 楼

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

#6 楼

我认为您的问题来自于（可理解的）始终保持联系的心态。即中央“真实” ci服务器始终（或几乎始终）可用。尽管在大多数环境中都是如此，但我至少已经在一个远非如此的环境中工作过。所有代码（我们正在谈论的代码价值超过10亿美元）必须（根据法律/国际协议，如果您不穿深色西装的人会来）在与任何Internet连接物理隔离的计算机上。这意味着通常情况下，我们每个人都有2台PC，一台用于编写/运行/测试代码，另一台用于Google东西，检查电子邮件等。在这些机器的团队中有一个本地网络，显然没有以任何方式连接到Internet。煤渣地下无窗房间（钢筋建筑，亚达亚达）。那台机器也没有互联网连接。而且，您可以想象。


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

此外，如果您考虑使用Linux内核规模的东西...开发人员不会只是向Linus自己发送拉动请求。它本质上是仓库的层次结构-每个仓库都是/对某人/某些团队来说是“中心”。 （例如SVN）无法使用-或无法如此轻松地使用。

#7 楼

DVCS的分布式方面始终以分叉的形式出现在开源开发中。例如，我贡献的某些项目被原始作者遗弃，现在有很多分支，维护人员有时会相互拉扯特定的功能。即使在一般情况下，OSS项目也通过拉取请求获得外部贡献，而不是通过让随机的人员推动访问地面真相回购来进行贡献。具有特定的正式版本，但在F / OSS世界中，这是规范，并非例外。

#8 楼

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


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

其次，您可以在Git中找到其他更多功能，但在CVS或SVN中找不到。也许只是您以为这必须是每个人的唯一功能。

确保许多人都可以像CVS或SVN这样集中使用它。但是请不要忘记，分布式VCS本身具有另一个功能：所有副本或多或少都是“完整的”（所有分支和完整的历史记录都可用），并且可以在不连接服务器的情况下检出所有分支。 />
我认为这是另一个不应该忘记的功能。

所以我能够提交我的更改，也许将正在进行的工作一起提交，然后将我的工作提取并重新建立到主要的开发分支上。 >
Git附带的其他功能：樱桃采摘
将历史一分为二
存储本地分支和存储更改（在Wikipedia中称为“搁置”）

也在Wikipedia中查看这三个表-版本比较续rol软件：


功能
基本命令
高级命令

所以再次，也许分散的方式并不仅限于此让人们使用它。



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




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

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



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




和往常一样：它取决于要求。

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


要脱机提交或浏览历史记录（即在假期中完成山间小屋的子模块的制作） ）
提供中央存储库，但希望保留“真实的”存储库以查看更改（例如，针对大型项目或分布式团队）
偶尔提供（副本）整个历史记录和分支，同时防止直接访问中央存储库（类似于第二个存储库）
想要版本化某些东西，而不必远程存储或设置专用存储库理论（尤其是对于Git来说，仅需git init .就足以准备对某些版本进行版本化）

还有更多，但四个就足够了。 。还是听起来不错？


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

#9 楼

灵活性既是祸也是福。而且由于Git非常灵活，因此对于典型情况几乎总是太灵活了。具体来说，大多数Git项目不是Linux。

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

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

#10 楼

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

因为您具有执行DVCS的能力并不意味着您的主要工作流程就必须是DVCS。当我在工作中使用git时，我们会以集中方式使用它，除了那些奇怪的奇怪情况，其中分散的位对于保持事物的前进是必不可少的。通常，您想使事情保持顺畅和轻松。但是，通过使用git可以确保您可以访问分布式端，以处理将来可能出现的恶劣情况。

#11 楼

对于同事来说，要从我的计算机上的git repo中拉出，意味着我需要在根级运行git守护程序作为后台任务。我对在我自己的计算机上或在公司提供的笔记本电脑上运行的守护程序非常谨慎。最简单的解决方案是“否”！对于同事来说，从我的计算机上的git repo中提取信息也意味着我的互联网地址需要固定。我旅行，我在家工作，偶尔我在办公室工作。如果我在办公室，甚至不需要VPN。我的同事可以轻松地从该分支中​​撤出。

另一方面，我的本地git repo是功能齐全的存储库。我可以提交新工作，为实验工作创建新的分支，并在弄乱事物时恢复工作，即使当我正在空地中间30000英尺的飞机上工作时。尝试使用集中式版本控制系统来做到这一点。

#12 楼

复杂度：

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

1）。

如果相反，每个开发人员都拥有自己的master分支，对于开发人员0：

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（N）。

一致性：

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

#13 楼

很简单：

公司是具有集中式工作流程的集中式组织。 CTO是技术真理的最终来源。无论工具公司使用什么工具，都必须反映此命令链。公司就像军队一样-您不能让私人人士胜过将军。 GIT。分散的部分只是他们不需要的功能-因此他们忽略了它。结果取决于谁在说话。 Linus Torvalds并不完全是您的小卧室老鼠，这就是为什么GIT的不同功能对他而言比对以github为中心的公司更重要的原因。

#14 楼

也许是因为他的工资单处理是集中的，所以如果我们希望获得薪水，就必须让核心人员满意。

也许是因为我们正在创建一个产品，所以我们需要一个主副本

也许是因为程序员去一个地方获取每个人的更改要容易得多，而不必连接许多不同的机器。
/>
也许是因为bug数据库是集中式的，必须与代码保持同步。

集中式很棒，直到出现问题为止。...

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

能够在存储库的本地副本上合并等。网络中断很大，但是不需要分布式系统；它只需要一个保留所有数据的本地副本的系统。就像通过飞行等方式签入代码一样。

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