Git与SVN：两者有何区别？
Git与SVN - 有什么区别？
如果你正在寻找版本控制解决方案，你可能会找寻并比较一些相关功能的开源软件。但是，Git和Subversion（SVN）两者之间该如何比较呢？
通过阅读下文你会了解到他们之间的根本区别。
服务器架构
Git软件安装在工作站上，充当客户端和服务器。使用SVN，有一个单独的服务器和客户端。使用Git，每个开发人员都可以在其单个计算机上拥有项目完整版本历史的本地副本。使用SVN，只有开发人员正在处理的文件保留在本地计算机上，开发人员必须连接网络，与服务器一起工作。
SVN用户check out文件并将更改后的文件提交回服务器。Git的文件更改发生在本地。优点是开发人员不必一直保持网络连接。将所有文件下载到开发人员的工作站后，本地操作就会更快。
过去，每个Git开发人员都拥有完整版本历史记录的副本，这意味着他们可以在将更改推送到中央存储库之前轻松共享更改。现在所有的共享都在中央存储库中完成，就像GitHub一样。而且，在当今世界，企业的项目跨越多个包含大型二进制文件的存储库。随着项目的增长，在本地存储是不太现实可取的。在Git与SVN性能方面，SVN的客户端 – 服务器模型在更大的文件和代码库方面性能更好。
SVN存储二进制文件更具优势
在Git中存储大型二进制文件会降低他们声称拥有的优于SVN的优势。开发人员花时间等待将完整的存储库check out到他们的计算机上。每次更改和提交大文件时，Git存储库都会呈指数级增长。
当然，有一些解决方法可以将您的二进制文件存储在Git中，例如Git LFS。但是，每个开发人员的行为都会导致大量的历史变更数据。这会降低性能。
在SVN中，仅将工作树和最新更改check out到本地计算机上。当二进制文件发生很多变化时，SVN中的check out时间会缩短。
SVN与Git Branching
关于SVN用户抱怨的最多之一是它繁琐的分支和复杂的合并模型。这可能很耗时。SVN分支创建为存储库中的目录。这个目录结构是SVN分支的核心痛点。分支准备就绪后，您将返回主干。
当然，你不是唯一合并变化的人。你的主干版本可能不会对应开发人员的分支版本。这意味着文件冲突，文件丢失和混乱变化让你的分支变得“扑朔迷离”。
开发人员喜欢Git，因为它有效的分支模型。在Git中，分支只引用某个提交，使它们轻量级但功能强大。Git允许您随时创建，删除和更改分支，而不会影响提交。如果您需要测试新功能或发现错误，可以创建分支，进行更改，将提交推送到中央存储库，然后删除分支。
访问控制
访问控制是Git与SVN辩论中的另一个关键。在权限和访问方面，两种系统都采用不同的方法。默认情况下，Git假定所有贡献者都具有相同的权限。
另一方面，SVN允许您为每个文件级别和每个目录级别指定读取和写入访问控制。
Git或SVN的安全性
使用SVN，存储库的更改历史记录非常一致。要对存储库的历史记录进行任何更改，您需要访问中央服务器。
Git的分布式特性允许任何人更改其本地存储库历史记录的任何部分。尽管不鼓励改变历史，但它可能会发生。如果其他开发人员依赖于特定更改，则可能会导致问题。
在Git中，每次开发人员将文件克隆到计算机时，都会“备份”存储库的完整历史记录。如果忽略，这种自然备份机制则派不上用场。
Git和SVN都非常鼓励定期备份。如果没有共享服务器的最新副本，你不会希望成为服务器崩溃时的接收端。
存储要求
随着Git或SVN狂热的争论，你可能会注意到，在存储方面 – 没有区别。令人惊讶的是，Git和SVN存储库的磁盘空间使用量相等。即使SVN跟踪文件级别的更改并且Git跟踪存储库级别的更改，也是如此。
再者，对于相同的大型二进制文件，在SVN中存储要比在Git中小得多。
哪个更容易接受 - Git还是SVN？
从SVN转型有几个原因。它不是自动化和DevOps的好工具。它不再拥有一个充满活力的社区支持它。
在寻找更现代化和支持的系统来取代SVN时，Git似乎是不费吹灰之力。特别是因为它也是开源的：你无须为免费的事物做预算。
但是，如果您正在处理大型文件，拥有大型全球团队，安全问题或其他“大规模”挑战，Git产生的问题可能会多于它带来的益处。
