近年来，Git 的使用极大地普及了分布式版本控制系统。根据 Eclipse 社区调查，2014 年 Git 最终超越 SVN，成为 Java 开发人员首选的版本控制系统 (VCS)。
前言
GitHub 和 Bitbucket 等托管平台通过提供开发社区托管空间和工具，使分布式版本控制成为可能。Microsoft 已将 Git 作为其 TFS 平台中新项目的默认版本控制提供程序，并强烈鼓励开发人员使用 Git，除非他们特别需要集中式 VCS。那么，最流行的 VCS 在功能分支模型的实现和便利程度方面如何比较呢？
选择适合您需求的版本控制系统
当一个团队开始一个新项目或在一个正在进行的计划中达到一个转折点时，它提供了一个提问的机会，“我当前的版本控制系统是否正常工作？” “Git 和 SVN 有什么区别？” 我们将探索三个最流行的版本控制系统——Git、SVN 和 Mercurial。从意识形态的角度来看，Mercurial 和 Git 属于同一类分布式 VCS。主要区别是什么，我们为什么选择 Git？
分布式与集中式版本控制系统
首先是 RCS (1982) 及其后继 CVS (1987) 的集中式版本控制系统。目前最流行的是 Subversion、TFVC、Perforce 和 Clearcase。使用这些系统，所有开发人员都可以访问一个中央存储库。如果进行了更改，它将在每个开发人员提交更改之前到达，不幸的是，这还包括损坏的代码。由于只有一个“真正的”存储库，因此离线工作可能是一项挑战。为了完成添加查看历史或提交代码等基本操作，您需要访问存储库。
最早的分布式版本控制系统之一是 Bitkeeper (1997)。当前流行的工具包括 Git、GNU Arch 和 Mercurial。在分布式模型中，每个开发人员都有他/她自己的存储库副本。使用这种方法，开发人员可以离线工作——他们可以提交、分支、合并分支、查看历史记录以及他们需要的任何东西，因为他们手头有整个存储库。只有在与其他团队成员同步时才需要访问 Internet。
Mercurial 和 Git 的区别
Mercurial 和 Git 之间存在两个主要区别。
单体。Mercurial 是一个单体应用程序，而 Git 遵循 linux 意识形态，是许多小型二进制文件，通常对开发人员隐藏。拥有能够调整系统的精细工具意味着 Git 非常灵活。准确性和灵活性对客户很重要。因此，拥有实施非标准解决方案的灵活性可能会改变游戏规则。
历史。Mercurial 和 Git 之间的另一个区别是它们如何处理历史。Git 允许（有些人可能会说鼓励）用户在需要时重写其存储库的历史记录。这允许仔细调整提交日志以保持日志简单和逻辑结构，而不是包含整个历史记录。强大的力量伴随着巨大的责任，所以历史重写应该只发生在本地提交上。
最后，这两个系统非常相似。此外，Git 提供的许多开箱即用的功能都作为插件引入 Mercurial。功能分支工作流可以在 Git 和 Mercurial 中轻松实现。
使用 Git 实现功能分支开发流程的优缺点
VCS 中的分支允许我们创建代码的虚拟副本，以便在不影响原始代码的情况下进行更改。在特征分支模型中，我们希望每个新特征都有一个单独的分支。这有几个重要的好处。
合并代码之前的简单代码审查
代码审查很棒。它们有助于保持代码统一，保持相同的样式，并显着减少重构以使代码与标准保持一致的需要。有时，代码审查甚至可以在问题移交给质量保证分析师之前发现错误，从而在开发过程中节省宝贵的时间。
更好地控制源
功能请求方法如此受欢迎的原因在于它提供的隔离性。功能与代码分开孵化，在它们准备好之前不会影响代码库。尽管 SVN 提供分支，但临时分支仅用于更大的功能，因为它们在大型项目中的价格标签。
在问题之间轻松转换
通常，开发人员需要在此过程中暂停并在不同问题或任务之间调整工作。假设开发人员已经在一个问题上工作了大约一周，当时需要在生产中进行关键的新修复。当然，他可以做一个 SVN 补丁或在新位置干净下载源代码，但这些变通方法会耗费时间并可能导致挫败感。使用每个功能的分支工作流程，所有这些工作都可以通过简单的临时提交和分支更改来完成。
更好的发布流程
功能分支与非常流行的Git Flow整齐排列。它考虑了所有可能的情况，如修补程序、代码冻结等。
缺点：复杂的历史记录
至于缺点，它们来自开发人员必须完成的额外步骤。开发人员必须确保他们从正确的提交分支。根据已完成问题的合并策略，历史日志可能会变得更大且更难理解。
Git 和 SVN 的区别
切换到 Git 时最显着的差异之一是它的速度。由于整个存储库本地存储在开发人员的机器上，因此他或她可以在互联网连接非常差的情况下工作数天。由于 Git 的分支实现，创建分支非常快。在 Git 中，分支只是对提交的引用，其中将附加以下提交。它甚至不包含创建日期、创建它的用户或某种消息等基本信息。
由于 Git 鼓励使用分支，我们不能忘记对其合并功能大加赞赏。1.5 版之前的 SVN 只进行双向合并，涉及应用于当前代码库的更改集，因为它不存储合并信息。Git 使用存储库的历史来识别合并分支之间的共同基础，并且只需要从它们分歧的地方合并——从而完成三向合并。SVN 也在改进，从 1.5 开始支持三路合并。在即将到来的 1.9 版本的 SVN 中，它还将有更好的文件重命名/移动跟踪，这是 Git 已经做到的。
平台架构
Git 与 SVN 之间的主要区别在于它们的代码管理方法。Git 具有分布式架构，而 SVN 是集中式的。两者都是企业级版本控制系统，Git 更多地定位为源代码管理 (SCM) 工具，而 SVN 更多地充当修订控制系统。
任何 Git 安装都可以充当服务器和客户端。每个用户都将拥有存储库的本地副本及其完整版本历史记录。它消除了不断与服务器连接的需要，同时允许通过更快的 VCS 操作进行本地更改，这些操作可以稍后推送到服务器。这种方法为您实现 VCS 功能的方式提供了更大的灵活性，并在开发环境中提供了更多的自由。
另一方面，SVN 需要单独的客户端和服务器，只有开发人员正在处理的文件作为本地副本保存。它需要与服务器进行持续通信，检出文件并提交回服务器。这种方法有助于在 SVN 中存储大型二进制文件，因为它们不会被复制到每个开发人员环境中。
仅考虑源代码时，每个平台的存储要求将相似。但是，如果需要存储更大的文件，SVN 比 Git 具有明显的优势。
分支结构
这就是 Git 的灵活性大放异彩的地方。SVN 基于目录结构，分支在存储库中创建为目录。开发完成后，更改将提交到主干。但是，当多个开发人员在同一个主干中工作时，可能会出现未反映在其他开发人员的分支中的更改。这种情况会导致合并冲突、文件丢失等，需要复杂的分支合并模型。
Git 分支只是对特定提交的引用，可以随时创建、编辑或删除分支，而不会影响底层提交。因此，开发人员可以轻松地创建和合并分支或删除它们以保持整个存储库的清洁。这种灵活性还支持不同的分支策略并降低分支的整体复杂性。
支持和社区
Git 因其更灵活的版本控制方法和强大的功能集而成为行业标准。它还导致 Git 在许多平台上得到原生支持，并成为许多源代码控制平台的默认版本控制机制。这种广泛的支持有助于在将 Git 集成到 CI/CD 等第三方工具或平台时提供相对方便的用户体验，并提供许多支持选项来设置或排除 Git 故障。
此外，由于全球社区高度活跃，为 Git 的改进做出了贡献，因此有大量资源可以获取有关 Git 的知识。如果您遇到错误，只需敲几下键即可解决您最喜欢的搜索引擎的问题。您还可以找到关于修复致命错误的优秀文章：拒绝合并不相关的历史错误。
相比之下，SVN 的社区相对较小，商业支持选项有限。这也意味着支持 SVN 的工具和平台将会减少。但是，这并不意味着没有办法获得对 SVN 的支持。有一些蓬勃发展的 SVN 提供商，它们拥有小型但支持性的 SVN 社区，但它们不会像 Git 那样无处不在。
使用方便
这是大多数开发人员之间的争论点，每个人都坚持认为他们首选的 VCS 是最简单的工具。然而，共识是 SVN 比 Git 更容易上手。两者都使用 CLI 作为与其存储库交互的主要方法。
Git 更陡峭的学习曲线可归因于平台的复杂性。然而，这种复杂性也是优势之一，因为它使 Git 能够作为 VCS 提供更精细的控制和灵活性。
关于 Git 与 SVN 的结论
Git 和 Apache Subversion 都是称职的版本控制系统，各有优缺点。Git的流行使其成为行业标准和大多数开发的默认 VSC。此外，Git 提供的灵活性和功能集使其成为与敏捷和 DevOps 等实践集成的理想平台。虽然 Git 无疑是领先的平台，但 SVN 不应该在没有适当考虑的情况下被丢弃。SVN 的功能（例如处理大文件的能力和基于路径的用户权限）在您的开发环境中可能至关重要。