分支和合并Git相对于其他版本控制系统的最大优势是它先进的分支模型。Git允许并鼓励你在本地使用多个完全独立的分支。这些分支的创建、合并和删除都可以在几秒钟内完成。这意味着您可以轻松地执行以下操作：无痛上下文切换创建一个分支来试验一个想法，提交几次，切换回原始分支的状态，应用补丁，切换回您正在试验的状态，更改应用的补丁被合并。基于角色的代码分支你可能有一个只包含生产环境中存在的代码的分支，另一个用于合并测试环境代码的独立分支，以及几个用于日常开发工作的较小分支基于特性的工作流为每个新的新分支创建一个新分支功能，您可以方便、流畅地在这些分支之间无缝切换。当对这些特性的修改完成后，就可以将它们合并到主分支中，将Feature分支删除。任何实验都会创建一个专用于该实验的分支。当你觉得实验不理想时，直接删除即可，放弃之前的实验内容。此时没有其他人会注意到这个实验（你甚至可以同时推送其他不相关的分支）尤其是当你推送到远程仓库时，你不必推送所有分支，你可以选择只推送几个您想要共享的分支，当然您可以根据需要推送所有分支。这往往使开发人员在试验许多新想法时不必发布他们自己的半生不熟的试点。当然，也有一些其他系统可以部分实现上述功能和优势，但具体实现起来会变得困难和容易出错。Git使这些任务变得异常简单，并且一旦开发人员学会了如何使用它，它就会改变他们的工作方式。轻量级和快速Git是快速的。Git基本上在本地完成所有事情，这对于必须与服务器通信的集中式系统来说是一个巨大的速度优势。Git最初是为了管理LinuxKernel的源代码而设计的，这意味着他从诞生的第一天起就具有处理大型仓库的高效优势。Git是用C语言编写的，减轻了使用更高级编程语言的运行时带来的性能损失。从一开始，Git的两个最重要的设计目标就是性能和速度。压力测试让我们看看与SVN（一种常见的集中式存储版本控制系统，很像CVS和Perforce）相比常规操作的性能基准。这里的指标是数值越小，速度越快。为了进行测试，我们在亚马逊AWS的同一可用区中创建了两个新的大型计算服务器实例。Git和SVN安装在每个计算实例上。我们将Ruby源代码存储库复制到Git和SVN计算服务器示例，它们都执行常见操作。在某些情况下，两者的命令和实际效果并不完全对应。在这里，我们选择在常用操作中具有相似效果的匹配案例。比如对于“commit”的测试，我们也在Git中计算Push的时间。然而，在大多数情况下，您实际上可能不会在提交后立即推送到服务器，这是SVN上的一个完整操作。下表中所有时间单位均为秒。操作说明GitSVNPerformanceMultiplier提交文件（A）添加、提交并推送113个修改后的文件（2164+、2259-）0.642.604x提交图片（B）添加、提交并推送1000张1k图片1.5324.7016x比较当前更改Diff187更改文件(1664+,4859-)与上一次提交0.251.094xDiff与4次提交返回(269changed/3609+,6898-)0.253.9916xDiff两个标签相互比较(v1.9.1.0/v1.9.3.0)1.1783.5771x提交历史(50)最近50次提交的日志（19k输出）0.010.3831x提交历史（全部）所有提交的日志（26,056次提交–9.4M的输出）0.52169.20325x提交历史（文件）单个文件的历史记录（array.c–483次）0.6082.84138x提交A的更新拉取scenario(113fileschanged,2164+,2259-)0.902.823x单个文件(array.c)BlameLineannotation1.913.041x需要注意的是，这已经是SVN***的运行场景——没有For任意一台服务器，任意负载，客户端与服务器之间的网络带宽达到80MB/s。以上各项指标均受网络波动影响，或者在较差的网络环境下，SVN表现较差。但是，几乎所有的Git指标都不会受到影响。很显然，在这些最常用的版本控制工具的运行中，即使是在SVN这样理想的使用环境中，**Git在很多方面都遥遥领先**。Git比SVN慢的一个地方是初始化克隆存储库。在这种情况下，Git正在下载整个存储库历史记录，而不仅仅是最新版本的代码。如上表所示，仅执行一次的操作影响不大。操作说明Git(ShallowClone)GitSVNCloneGitCloneandshallowclone(shallowclone)vsSVNcheckout21.0107.514.0Size(M)clone/checkout后客户端的文件大小(inM)181.0132.0还有一个比较有意思的地方就是有Clone或Checkout到本地后，Git和SVN的文件大小几乎没有区别。要知道对于Git来说，local包含了整个项目的历史。这也证明了Git在文件压缩和存储方面的超强效率。分布式Git的最佳特性之一是它是分布式的。这意味着您必须克隆整个存储库，而不是仅仅检查分支的最新主版本。多备份Git在日常使用场景中经常会有多备份。这意味着即使使用集中存储的工作流程，每个用户在服务器本地都有一个完整备份。当服务器端数据损坏或丢失时，这里的任何一个版本都可以推送回服务器，以挽救损失。其实只要你的仓库不是只有一份，Git是不会出现单点问题的。任意工作流由于Git的分布式特性和优秀的分支系统，你可以很容易地在它之上实现大量的工作流模型。Subversion(SVN)风格的工作流集中式存储工作流非常普遍，尤其是对于那些从传统的集中式代码版本管理系统转向使用Git的人来说。Git也可以提供这种工作形式：每次Push都必须更新到远程仓库的最新版本。所以大家还是用集中存储的工作流程，把代码推送到和以前一样的服务器上，还是没问题。IntegrationManagerWorkflow另一个常见的Git工作流是集成工作流。主存储库由单个开发人员（维护者）维护。其他几个开发者从这个仓库clone，然后push到他们自己完全独立的仓库，并且***要求维护者从他们各自仓库的主仓库拉取变更。这种形式通常在GitHub上作为开源进行协作。Maintainerandleadworkflow对于更复杂的项目，像Linux内核这样的开发工作流也是有效的。在此模型中，负责人（副手）负责整个项目的某些特定子系统，他们合并与该子系统相关的所有更改。另一个维护者（dictator，字面意思：独裁者）只能从他管辖的负责人那里获取变更，并将这些变更推送到主仓库。然后每个人都从这个存储库中获取更新。数据校验Git的数据模型保证了项目中每一个字节、每一位的一致性。每个提交的文件都会使用校验和来计算摘要，摘要值也会在签出时使用。从仓库中获取的内容不可能与您存储的内容有任何不同。在不更改ID（校验和）的情况下，也无法更改Git存储库中的任何文件、日期、提交说明或任何其他数据。这意味着如果你有commitID，你不仅可以确定这个版本的代码和他提交的时候一模一样，而且这个版本的历史没有改变。默认情况下，大多数集中存储的版本控制系统不提供此类验证集成。暂存区与其他系统不同，Git有一个称为“暂存区”或“索引”的概念。这是一个临时区域，可以在执行提交之前对更改进行格式化和审查。Git优于其他系统的一个功能就是我们可以快速的暂存一些变化的文件，只提交工作目录下部分变化的文件，或者文件的部分变化内容，在命令上列出变化提交文件列表时的行。暂存区允许您仅暂存对文件的部分更改。在您意识到忘记提交其中一项之前对文件进行两项逻辑上不相关的更改的日子已经一去不复返了。现在您可以在当前提交中只暂存需要更改的文件，其他更改将在下一次提交中暂存。此功能可以扩展到对文件所做的任何更改。当然，Git也允许你忽略暂存区的进程，你可以很方便的在commit命令后加上'-a'选项直接提交所有修改。Git会自动帮你先存到暂存区，然后执行commit。免费和开源Git是一种开源软件，在GNUGPL2.0许可证下获得许可。Git选择GPLv2是为了确保您可以自由地共享和转换自由软件，并确保任何使用它的人都是免费的。但是，我们确实保留了“Git”和徽标以避免争议。有关详细信息，请参阅我们的商标政策。
