Why is Git better than Subversion?我已经使用Subversion几年了，使用SourceSafe之后，我只是喜欢Subversion。 与TortoiseSVN结合使用，我真的无法想象它会变得更好。 但是，越来越多的开发人员声称Subversion存在问题，我们应该转向新的分布式版本控制系统，例如Git。 Git在Subversion上有何改进？ Git并不比Subversion好。但是也不差。这不一样。 好。 关键区别在于它是分散的。想象一下，您是旅途中的开发人员，您在笔记本电脑上进行开发，并且希望拥有源代码控制权，因此可以返回3个小时。 好。 使用Subversion，您会遇到一个问题：SVN信息库可能位于您无法到达的位置(在公司中，并且您目前没有互联网)，因此无法提交。如果要复制代码，则必须逐字复制/粘贴。 好。 使用Git，您就不会遇到这个问题。您的本地副本是一个存储库，您可以对其进行提交并获得源代码管理的所有好处。重新获得与主存储库的连接时，可以对其进行提交。 好。 首先看起来不错，但请记住此方法会增加复杂性。 好。 Git似乎是"新的，闪亮的，酷的"东西。这绝不是一件坏事(毕竟，Linus为Linux Kernel开发编写了它是有原因的)，但是我感到许多人跳入"分布式源代码控制"培训只是因为它是新的，并且是由Linus Torvalds编写的，实际上没有知道为什么/如果更好。 好。 Subversion有问题，但是Git，Mercurial，CVS，TFS或其他问题也有问题。 好。 编辑：所以这个答案已经有一年历史了，仍然产生了很多反对意见，所以我想我会添加一些更多的解释。自编写此书以来的最后一年，Git获得了很多动力和支持，尤其是自GitHub之类的网站真正腾飞以来。如今，我同时使用Git和Subversion，我想分享一些个人见解。 好。 首先，当分散工作时，Git最初可能真的会造成混乱。什么是遥控器？以及如何正确设置初始存储库？一开始会出现两个问题，特别是与SVN的简单" svnadmin create"相比，Git的" git init"可以采用--bare和--shared参数，这似乎是设置集中式管理的"正确"方法资料库。这是有原因的，但是会增加复杂性。" checkout"命令的文档对于转换的人非常混乱-"正确"的方式似乎是" git clone"，而" git checkout"似乎是切换分支。 好。 当您分散时，Git确实会发光。我在家中有一台服务器，在旅途中有一台笔记本电脑，而SVN在这里根本无法正常工作。使用SVN，如果未连接到存储库，则无法获得本地源代码控制(是的，我知道SVK或复制存储库的方式)。无论如何，使用Git都是默认模式。不过，这是一个额外的命令(git commit在本地提交，而git push origin master将master分支推送到名为" origin"的远程)。 好。 如上所述：Git增加了复杂性。创建存储库的两种模式，即检出与克隆，提交与推送......您必须知道哪些命令在本地工作以及哪些与"服务器"一起工作(我假设大多数人仍然喜欢中央"主存储库" )。 好。 而且，该工具仍然不足，至少在Windows上是如此。是的，有一个Visual Studio加载项，但是我仍然将git bash与msysgit一起使用。 好。 SVN的优点是学习起来非常简单：存在您的存储库，对它的所有更改，如果您知道如何创建，提交和签出，并且准备就绪，可以稍后进行分支，更新等操作上。 好。 如果某些开发人员不总是连接到主存储库，则Git的优势是更适合。而且，它比SVN快得多。从我听到的信息来看，分支和合并支持要好得多(这是我们写的核心原因，这是可以预料的)。 好。 这也解释了为什么它在Internet上获得如此多的关注，因为Git非常适合于开放源代码项目：只需对其进行分叉，将更改提交到您自己的Fork中，然后要求原始项目维护者来进行更改。使用Git，这是可行的。真的，在Github上尝试一下，这很神奇。 好。 我还看到了Git-SVN桥：中央存储库是Subversion存储库，但是开发人员在本地使用Git，然后桥将其更改推送到SVN。 好。 但是即使有这么长的时间，我仍然坚持我的核心信息：Git并不好坏，只是有所不同。如果您需要"离线源代码管理"，并且愿意花一些额外的时间来学习它，那就太好了。但是，如果您有严格集中化的Source Control，并且/或者由于您的同事不感兴趣而一开始就在努力引入Source Control，那么SVN的简单性和出色的工具(至少在Windows上是如此)非常出色。 好。 好。 使用Git，您几乎可以脱机执行任何操作，因为每个人都有自己的存储库。 制作分支和分支之间的合并真的很容易。 即使您没有项目的提交权限，您仍然可以在线拥有自己的存储库，并为补丁发布"推送请求"。每个喜欢您的补丁程序的人都可以将其加入他们的项目中，包括官方维护人员。 派生一个项目，对其进行修改，并且仍然继续合并来自HEAD分支的错误修正，这是微不足道的。 Git为Linux内核开发人员服务。这意味着它确实非常快(必须如此)，并且可以扩展到成千上万的贡献者。 Git还使用较少的空间(Mozilla存储库的空间最多减少30倍)。 Git非常灵活，而且非常TIMTOWTDI(有多种方法可以做到)。您可以使用所需的任何工作流程，而Git将支持它。 最后，还有GitHub，这是一个托管Git存储库的好网站。 Git的缺点：
其他答案也很好地解释了Git的核心功能(很棒)。但是，还有很多小方法可以使Git表现得更好，并帮助保持我的生活更加理智。以下是一些小事情： "为什么Git比X更好"概述了Git与其他SCM的优缺点。 简要地：
有一些缺点：
在最简单的用法中，Subversion和Git几乎相同。之间没有太大区别：
和
Git真正令人眼前一亮的是分支机构并与其他人一起工作。 Google Tech Talk：git上的Linus Torvalds
Git Wiki的比较页面 http://git.or.cz/gitwiki/GitSvnComparsion 好吧，它是分布式的。基准测试表明它的速度要快得多(考虑到它的分布式特性，差异和日志之类的操作都是本地的，因此在这种情况下当然要快得多)，并且工作文件夹更小(这仍然让我感到震惊)。 当您使用Subversion或任何其他客户端/服务器版本控制系统时，实际上是通过签出修订版本在计算机上创建工作副本。这代表了存储库外观的快照。您通过更新来更新工作副本，并通过提交来更新存储库。 使用分布式版本控制，您没有快照，而只有整个代码库。想要与3个月大的版本进行比较吗？没问题，使用3个月的旧版本仍在您的计算机上。这不仅意味着事情要快得多，而且如果您与中央服务器断开连接，您仍然可以执行许多惯用的操作。换句话说，您不仅拥有给定修订版的快照，而且还拥有整个代码库。 您可能会认为Git会占用您的硬盘驱动器上的大量空间，但是从我所看到的一些基准测试来看，它实际上花费的空间更少。不要问我如何。我的意思是，它是由Linus构建的，我对文件系统了解一两点。 我喜欢DVCS的要点是： 进行相对大型项目的主要原因是第3点改善了沟通。其他都是不错的奖励。
有趣的是： 请阅读在Google Code项目上使用Git开发
在Svn存储库上使用Git给我带来了好处： 机器，提交和从中拉出 对他们 这里的所有答案都是以程序员为中心的，如预期的那样，但是，如果您的公司在源代码之外使用版本控制，会发生什么？有很多不是源代码的文档都可以从版本控制中受益，它们应该靠近代码而不是另一个CMS。大多数程序员并不是孤立地工作-我们作为团队的一员为公司工作。 考虑到这一点，请比较Subversion和git在客户端工具和培训中的易用性。我看不到任何分布式修订版本控制系统都将更易于使用或向非程序员解释的情况。我希望证明自己是错误的，因为这样我就可以评估git，并且实际上希望它可以被那些需要版本控制且不是程序员的人所接受。 即使这样，如果管理层问到为什么我们应该从集中式修订控制系统转移到分布式修订控制系统，我也很难给出一个诚实的答案，因为我们不需要它。 免责声明：我很早就对Subversion感兴趣(大约v0.29)，因此我很偏颇，但是自那时以来我工作的公司从我的热情中受益，因为我一直鼓励并支持使用它。我怀疑大多数软件公司都是这样的。如此众多的程序员加入git潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处吗？即使您为不同的团队使用单独的系统，您也会错过一些好处，例如(统一的)问题跟踪集成，同时增加了维护，硬件和培训要求。 Subversion仍然是使用更为广泛的版本控制系统，这意味着它具有更好的工具支持。您会发现几乎所有IDE都具有成熟的SVN插件，并且有不错的资源管理器扩展(例如TurtoiseSVN)。除此之外，我必须同意Michael：Git并不比Subversion更好或更糟，而是不同的。 David Richards WANdisco关于Subversion / GIT的博客
让SubVersion感到困扰的一件事是，它在项目的每个目录中都放置了自己的文件夹，而git仅在根目录中放置了一个文件夹。没什么大不了的，但是类似的小事加起来。 当然，SubVersion具有Tortoise，(通常)非常好。 Git还使分支和合并变得非常容易。 Subversion 1.5刚刚添加了合并跟踪，但是Git仍然更好。使用Git分支非常快速且便宜。这使得为??每个新功能创建分支更加可行。与Subversion相比，Oh和Git存储库在存储空间方面非常有效。 这全都涉及做某事所需的易用性/步骤。
如果我要在PC /笔记本电脑上开发单个项目，则git会更好，因为它更容易设置和使用。 如果只有2个人，我想说git也更容易，因为您可以互相推拉。 但是，一旦超出了范围，我就会进行颠覆，因为此时您需要设置一个"专用"服务器或位置。 您可以使用git和SVN一样好地执行此操作，但是由于需要执行其他步骤来与中央服务器同步，因此git的好处远远超过了git。在SVN中，您只需提交即可。在git中，您必须先进行git commit，然后进行git push。仅仅因为您最终做了太多事情，其他步骤就变得烦人了。 SVN还具有更好的GUI工具的优势，但是git生态系统似乎正在迅速赶上，因此从长远来看，我不必担心。 Easy Git上有一个漂亮的页面，比较了Git和SVN的实际用法，这将使您了解Git与SVN相比可以做(或更容易做)的事情。 (从技术上讲，这是基于Easy Git的，它是Git之上的轻量级包装。) 通常，Git和DVCS对于开发人员彼此独立执行大量编码非常有用，因为每个人都有自己的分支。但是，如果您需要其他人进行更改，则她必须提交其本地存储库，然后她必须将该更改集推送给您，或者您必须将其从她那里撤出。 我自己的推理也使我认为，如果您进行集中式发行之类的事情，DVCS会使质量检查和发行管理更加困难。必须负责从其他所有人的存储库中进行该推/拉操作，解决在最初的提交时间之前已经解决的所有冲突，然后进行构建，然后让所有其他开发人员重新同步其存储库。 当然，所有这些都可以通过人工流程解决。 DVCS只是打破了集中版本控制所修复的问题，以便提供一些新的便利。 我喜欢Git，因为它实际上可以帮助中大型团队的开发人员之间进行交流。作为一个分布式版本控制系统，通过其推/拉系统，它可以帮助开发人员创建源代码生态系统，从而有助于管理在单个项目上工作的大量开发人员。 例如，说您信任5个开发人员，仅从其存储库中提取代码。每个开发人员都有他们自己的信任网络，从那里可以提取代码。因此，开发基于开发人员的信任结构，其中代码责任在开发社区之间共享。 当然，这里的其他答案中也提到了其他好处。 我认为Subversion很好..直到您开始合并..或做任何复杂的事情..或做Subversion认为很复杂的事情(例如执行查询以找出哪个分支与特定文件混淆，更改实际来自何处，检测复制和粘贴)等)。 我不同意最终的答案，他说GIT的主要好处是脱机工作-这固然有用，但是对于我的用例来说，它更像是一个额外的东西。 SVK也可以脱机工作，但毫无疑问，我可以选择哪个时间来投入我的学习时间。 只是它非常强大且快速，并且在习惯了这些概念之后非常有用(在某种意义上是：用户友好)。
有关合并故事的更多详细信息，请参见： 这些都暗示了一些答案，但我想明确指出两点：
1)进行选择性提交的能力(例如， 2)在不公开更改的情况下进行提交的能力。在Subversion中，任何提交都会立即公开，因此不可撤销。这极大地限制了开发人员"提早提交，经常提交"的能力。 Git不只是一个VCS；它也是开发补丁的工具。 Subversion仅仅是一个VCS。 我绝对喜欢能够在Git中管理我的源代码的本地分支，而又不会浪费中央存储库的资源。在许多情况下，我都会从Subversion服务器中签出代码，然后运行本地Git存储库以实现此目的。初始化Git存储库不会污染到处都是一堆烦人的.svn文件夹，这也很棒。 就Windows工具的支持而言，TortoiseGit能很好地处理基础知识，但是除非我想查看日志，否则我还是更喜欢命令行。我非常喜欢Tortoise {Git | SVN}在读取提交日志时的帮助方式。 这是一个错误的问题。专注于git的疣，就至少在某些用例中，Subversion为何表面上看起来更好更好，形成论点太容易了。 git最初被设计为低级版本控制构造集，并且具有面向Linux开发人员的巴洛克式界面，这一事实使圣战更容易获得吸引力和合法性。 Git的支持者凭借数百万个工作流程优势而振奋精神，这使svn的人宣称没有必要。很快，整个辩论被归结为集中式与分布式，这符合企业SVN工具社区的利益。这些公司通常发布有关颠覆在企业中的优势的最具说服力的文章，取决于git的不安全感和svn为企业的长期成功所准备的企业级产品。 但这是问题所在：Subversion是体系结构的死胡同。 尽管svn的使用时间是svn的两倍以上，但是您甚至可以轻松地使用git并构建集中式的subversion替代品，即使svn都无法像git一样在任何地方实现基本的合并跟踪。这样做的一个基本原因是使分支与目录相同的设计决策。我不知道为什么他们本来会这样，这肯定会使部分结帐非常简单。不幸的是，这也使得无法正确跟踪历史记录。现在显然您应该使用颠覆存储库布局约定来将分支与常规目录分开，并且svn使用一些启发式方法使事情在日常使用情况下正常工作。但是，所有这些都只是在记录一个非常糟糕且有限的低级设计决策。能够执行版本库差异(而不是目录差异)是版本控制系统的基本和关键功能，并且极大地简化了内部结构，从而有可能在其之上构建更智能，更有用的功能。您可以看到扩展颠覆已付出的努力，但是从诸如合并解析之类的基本操作来看，它与当前的现代VCS相比还有很多差距。 现在，对于那些仍然相信Subversion在可预见的将来足够好的人，这是我的衷心和不可知论的建议： Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型VCS。除非他们从头开始重新构建存储库模型，否则这在技术上是不可能的，但是那真的不是svn吗？无论您认为自己没有现代VCS的功能有多少，您的无知都不会使您免受Subversion的陷阱的困扰，其中许多情况是其他系统无法或无法轻松解决的。 像svn一样，解决方案的技术劣势如此明显是极为罕见的，当然我永远不会对win-vs-linux或emacs-vs-vi提出这样的看法，但是在这种情况下，它是如此明确，源代码控制是开发人员手中的如此基本工具，我认为必须明确说明。无论出于组织原因而使用svn的要求，我恳求所有svn用户不要让他们的逻辑思维错误地认为，更现代的VCS仅对大型开源项目有用。无论开发工作的性质如何，如果您是一名程序员，那么如果您学会了如何使用设计更好的VCS(无论是Git，Mercurial，Darcs还是其他许多类型的VCS)，都将成为一名更有效的程序员。 由于它不需要与中央服务器持续通信的事实，几乎每个命令都在不到一秒钟的时间内运行(显然git push / pull / fetch速度较慢，仅因为它们必须初始化SSH连接)。分支要容易得多(一个简单的命令即可分支，一个简单的命令即可合并) Subversion非常易于使用。在过去的几年中，我从未发现任何问题或无法正常工作。另外，还有许多出色的GUI工具，并且对SVN集成的支持很大。
使用Git，您可以获得更灵活的VCS。您可以将其与SVN相同的方式与用于提交所有更改的远程存储库一起使用。但是您也可以在离线状态下使用它，并且仅将更改不时推送到远程存储库。
如果您大多数情况下都是使用本地存储库脱机工作，则如果本地计算机上丢失了某些内容，则将没有备份。使用SVN时，您主要是在使用远程存储库，这也是您在另一台服务器上进行备份的同时。 Git比SVN好吗？只需一些版本历史记录和备份机制的开发人员，使用SVN可以轻松自如。经常与分支机构合作，同时测试更多版本或大部分离线工作的开发人员可以从Git的功能中受益。有一些非常有用的功能，例如SVN找不到的隐藏功能，可以使生活更轻松。但另一方面，并??非所有人都需要所有功能。因此，我看不到SVN的死机。
Git需要一些更好的文档，并且错误报告必须更有帮助。而且，现有有用的GUI很少。这次，我仅找到1个Linux的GUI，它支持大多数Git功能(git-cola)。 Eclipse集成正在运行，但尚未正式发布，并且没有正式的更新站点(仅某些具有定期构建的外部更新站点来自主干http://www.jgit.org/updates)
SourceGear的Eric Sink撰写了一系列有关分布式和非分布式版本控制系统之间差异的文章。他比较了大多数流行的版本控制系统的优缺点。非常有趣的阅读。
对于寻求良好Git GUI的人来说，Syntevo SmartGit可能是一个很好的解决方案。我认为，它的专有但非商业用途免费，可在Windows / Mac / Linux上运行，甚至使用某种git-svn桥支持SVN。 Windows中的Git现在已得到很好的支持。 查看GitExtensions = http://code.google.com/p/gitextensions/ 和手册以获得更好的Windows Git体验。 我最近一直居住在Git土地上，我喜欢将其用于个人项目，但是鉴于工作人员对需求的看法发生了变化，如果没有紧迫的好处，我还无法将工作项目从Subversion切换到它。此外，我们内部运行的最大项目非常依赖svn：externals，据我到目前为止所看到的，它在Git中无法很好地，无缝地工作。 http://subversion.wandisco.com/component/content/article/1/40.html 我认为可以肯定地说，在开发人员中，SVNVs。 Git的争论已经有一段时间了，每个人都有更好的观点。在我们于2010年及以后举办的有关Subversion的网络研讨会中，甚至提出了这些问题。 我们的开源总监兼Subversion公司总裁Hyrum Wright谈到了Subversion与Git以及其他分布式版本控制系统(DVCS)之间的区别。 他还谈到了Subversion即将发生的变化，例如下一代工作副本(WC-NG)，他认为这将导致许多Git用户转换回Subversion。 观看他的视频，并通过评论此博客或在我们的论坛中发布让我们知道您的想法。注册很简单，只需要一点时间！ 首先，并发版本控制似乎很容易解决。一点也不。无论如何... SVN非常不直观。 Git更糟。 [讽刺的推测]这可能是因为像并发版本控制之类的难题一样，开发人员对制作一个好的UI没有太大兴趣。 [/讽刺推测] SVN支持者认为他们不需要分布式版本控制系统。我也这么认为。但是，既然我们只使用Git，我就是一个信徒。现在，版本控制对我和团队/项目都有效，而不仅仅是为项目工作。当我需要分支时，我分支。有时，这是一个分支，在服务器上具有相应的分支，有时则没有。更不用说我必须继续研究的所有其他优点(部分由于现代版本控制系统的UI荒唐而荒唐的缺乏)。 为什么我认为Subversion比Git更好(至少对于我从事的项目而言)，主要是因为它的可用性和更简单的工作流程： http://www.databasesandlife.com/why-subversion-is-better-than-git/ |
