关于
分支和合并
让 Git 真正区别于几乎所有其他 SCM 的功能是其分支模型。
Git 允许并鼓励你拥有多个可以完全独立于彼此的本地分支。创建、合并和删除这些开发分支只需几秒钟。
这意味着你可以执行以下操作
- 无摩擦上下文切换。创建一个分支来尝试一个想法，提交几次，切换回分支的源头，应用一个补丁，切换回正在试验的分支，并将其合并。
- 基于角色的代码规范。拥有一个分支始终只包含进入生产环境的内容，另一个分支用于合并工作以进行测试，以及几个较小的分支用于日常工作。
- 基于特性的工作流。为正在处理的每个新特性创建一个新分支，以便可以在它们之间无缝切换，然后在该特性合并到主分支时删除每个分支。
- 一次性试验。创建一个分支进行试验，意识到它不起作用，然后直接删除它 - 放弃工作 - 其他人永远不会看到它（即使你在此期间推送了其他分支）。
值得注意的是，当你推送到远程仓库时，不必推送所有分支。你可以选择仅共享一个分支、几个分支或所有分支。这往往让人们可以自由尝试新想法，而不用担心如何以及何时将其合并或与他人共享。
有一些方法可以使用其他系统完成其中一些操作，但所涉及的工作要困难得多，且容易出错。Git 使这个过程变得非常容易，并且在大多数开发人员学习它时会改变他们的工作方式。
小巧而快速
Git 很快。使用 Git，几乎所有操作都在本地执行，这给了它一个巨大的速度优势，因为集中式系统必须不断与某个地方的服务器通信。
Git 是为 Linux 内核而构建的，这意味着它从第一天起就必须有效地处理大型存储库。Git 用 C 语言编写，减少了与高级语言相关联的运行时开销。从一开始，速度和性能就是 Git 的主要设计目标。
基准
让我们看看常见操作与 Subversion（一个类似于 CVS 或 Perforce 的常见集中式版本控制系统）相比如何。越小越快。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
为了进行测试，在同一可用性区域中设置了大型 AWS 实例。在两台机器上都安装了 Git 和 SVN，Ruby 存储库被复制到 Git 和 SVN 服务器，并在两者上执行了常见操作。
在某些情况下，命令并不完全匹配。在这里，尝试匹配最小公分母。例如，“提交”测试还包括 Git 的推送时间，尽管在大多数情况下你不会在提交后立即将内容推送到服务器，而在 SVN 中这两个命令无法分开。
所有这些时间都以秒为单位。
| 操作 | Git | SVN | ||
|---|---|---|---|---|
| 提交文件 (A) | 添加、提交并推送 113 个修改的文件 (2164+, 2259-) | 0.64 | 2.60 | 4 倍 |
| 提交图像 (B) | 添加、提交并推送一千张 1 kB 的图像 | 1.53 | 24.70 | 16 倍 |
| 差异当前 | 差异 187 个更改的文件 (1664+, 4859-) 与上次提交 | 0.25 | 1.09 | 4 倍 |
| 差异最近 | 差异 4 次提交 (269 个更改/3609+,6898-) | 0.25 | 3.99 | 16 倍 |
| 差异标签 | 差异两个标签 (v1.9.1.0/v1.9.3.0) | 1.17 | 83.57 | 71 倍 |
| 日志 (50) | 最后 50 次提交的日志 (19 kB 输出) | 0.01 | 0.38 | 31 倍 |
| 日志 (全部) | 所有提交的日志 (26,056 次提交 – 9.4 MB 输出) | 0.52 | 169.20 | 325 倍 |
| 日志 (文件) | 单个文件历史的日志 (array.c – 483 次修订) | 0.60 | 82.84 | 138 倍 |
| 更新 | 拉取提交 A 场景 (113 个文件更改，2164+, 2259-) | 0.90 | 2.82 | 3 倍 |
| 责备 | 单个文件 (array.c) 的行注释 | 1.91 | 3.04 | 1 倍 |
请注意，这是 SVN 的最佳情况：一台没有负载的服务器，与客户端机器建立千兆位连接。如果连接速度较慢，SVN 的所有这些时间几乎都会更糟，而 Git 的许多时间不会受到影响。
显然，在这些常见的版本控制操作中，即使在 SVN 的理想条件下，Git 也比 SVN 快一个或两个数量级。
Git 速度较慢的一个地方是初始克隆操作。在这里，Git 下载的是整个历史，而不是仅下载最新版本。如上图所示，对于仅执行一次的操作来说，它的速度并没有明显降低。
| 操作 | Git* | Git | SVN | |
|---|---|---|---|---|
| 克隆 | Git 中的克隆和浅克隆(*) 与 SVN 中的检出 | 21.0 | 107.5 | 14.0 |
| 大小（MB） | 克隆/检出后客户端数据和文件总大小（MB） | 181.0 | 132.0 |
值得注意的是，即使 Git 拥有项目整个历史中每个文件的每个版本，客户端上的数据大小也十分相似。这说明 Git 在客户端压缩和存储数据时非常高效。
分布式
分布式 SCM（包括 Git）最棒的功能之一就是分布式。这意味着您不必对源代码的当前提示进行“检出”，而是对整个存储库进行“克隆”。
多个备份
这意味着，即使您使用的是集中式工作流，每个用户实际上都拥有主服务器的完整备份。如果发生崩溃或损坏，可以将其中任何一个副本推送到主服务器以进行替换。实际上，除非存储库只有一个副本，否则 Git 没有单点故障。
任何工作流
由于 Git 的分布式特性和出色的分支系统，可以相对轻松地实现几乎无限数量的工作流。
Subversion 风格的工作流
集中式工作流非常常见，尤其是在从集中式系统过渡的人员中。自上次获取以来，如果有人推送，Git 将不允许您推送，因此所有开发人员都将推送至同一服务器的集中式模型运行良好。
集成管理器工作流
另一个常见的 Git 工作流涉及集成管理器——一个提交到“受信任”存储库的个人。然后，许多开发人员从该存储库克隆，将其推送到他们自己的独立存储库，并要求集成器拉取他们的更改。这通常在开源或 GitHub 存储库中看到的开发模型类型。
独裁者和副手工作流
对于更大规模的项目，类似于 Linux 内核的开发工作流通常很有效。在此模型中，一些人（“副手”）负责项目的特定子系统，并合并与该子系统相关的所有更改。另一个集成器（“独裁者”）只能从其副手中拉取更改，然后将其推送到每个人都再次从中克隆的“受信任”存储库。
数据保证
Git 使用的数据模型确保了项目中每一比特的加密完整性。每次检出时，都会对每个文件和提交进行校验和，并按其校验和进行检索。除了您输入的确切比特之外，不可能从 Git 中获取任何内容。
在不更改其之后所有内容的 ID 的情况下，也不可能更改 Git 存储库中的任何文件、日期、提交消息或任何其他数据。这意味着，如果您有提交 ID，则不仅可以确保您的项目与提交时完全相同，还可以确保其历史记录中没有任何内容被更改。
大多数集中式版本控制系统默认情况下不提供此类完整性。
暂存区
与其他系统不同，Git 有一个称为“暂存区域”或“索引”的东西。这是一个中间区域，可以在完成提交之前对提交进行格式化和审查。
Git 与其他工具不同的一点是，它可以快速暂存一些文件并提交它们，而无需提交工作目录中所有其他修改的文件，也无需在提交期间在命令行中列出它们。
这允许你仅暂存修改文件的部分内容。在意识到忘记提交其中一个修改之前，对文件进行两个逻辑上无关的修改的日子一去不复返了。现在，你可以仅暂存当前提交所需的更改，并将其他更改暂存到下一次提交。此功能可根据需要扩展到文件中的许多不同更改。
当然，如果你不想要那种控制，Git 也让你可以轻松忽略此功能——只需在提交命令中添加一个“-a”即可将所有文件的所有更改添加到暂存区域。
免费且开源
Git 根据 GNU 通用公共许可证版本 2.0 发布，这是一个 开源许可证。Git 项目选择使用 GPLv2 来保证你共享和更改自由软件的自由——确保该软件对所有用户都是免费的。
GIT 商标政策
1 目的
Git 项目是软件自由保护协会（“保护协会”）的成员项目。保护协会根据其非营利慈善使命代表 Git 项目持有商标权。
Conservancy 已采用此政策来保护商标（定义如下）并确保 Git 软件的身份及其自由和开源性质对每个人来说都是明确的。通过使用此政策，Git 项目可以传播 Git 软件的使用，同时确保以符合美国商标法的方式保护商标（美国注册号 4680534）。本政策旨在允许对商标的所有明确和适当的使用，同时禁止以可能让用户对软件来源感到困惑或暗示与 Git 项目不存在关联的方式使用商标。通过遵守本政策，您有助于向公众宣传自由使用和开发 Git 软件的权利。
在整个本政策中，“商标”一词指以下内容
文字商标“Git”
在 https://git.js.cn/downloads/logos 上展示和可供下载的徽标和图形商标
标语“愚蠢的内容跟踪器”
本政策仅涉及与 Git 项目相关的商标，不涉及与 Git 软件相关的任何版权。
2 使用商标的指南
2.1 首次提及时的商标符号
首次突出提及商标时，应立即在其后加上注册商标 (®) 或未注册商标 (™) 符号（视情况而定）。例如：“Git™”。
在不需要此类商标来保护与商标相关的知识产权的任何情况下，例如电子邮件、在线讨论和学术论文，都可免除此要求。我们鼓励尽可能使用适用的符号，但认识到许多用户会在非商业和非正式的情况下省略它们。
当您需要在例如他人持有的商标列表中提及“Git”时，可以使用“Git 及 Git 徽标是 Software Freedom Conservancy, Inc.（Git 项目的企业所在地）在美国和/或其他国家/地区的注册商标或商标”。
2.2 未经书面许可使用商标
您可以在未经事先书面许可的情况下使用商标（受其他部分约束）
以基本未修改的形式引用 Git 软件。“基本未修改”是指由 Git 项目提供的源代码构建，可能包括但不限于以下小修改：默认启用或禁用某些功能、翻译成其他语言、为与特定操作系统发行版兼容而必需的更改，或包含错误修复补丁。
将 Git 软件标识为软件产品的一个独特组件。
事实性地引用 Git 项目本身、其产品或其协议。
此外，您可以在以下情况下使用标记来引用 Git 软件和 Git 项目之外的产品、服务或社区，而无需书面许可
- 在引用基本未修改的 Git 软件时，表示此类软件是 Git 的“衍生产品”或“基于”Git。
- 在引用与 Git 软件互操作的第三方软件产品和/或服务时，采用“[产品名称] for Git”格式——前提是此类使用符合本政策的其余部分。
我们不会对在这些情况下使用标记收取许可费。但是，我们当然欢迎捐赠。如果您有兴趣向 Git 项目捐赠，请访问 https://git.js.cn/sfc，由 Conservancy 负责。Conservancy 是美国 501(c)(3) 公益慈善机构。
2.3 禁止使用的标记
您不得以下列方式使用标记
以任何可能导致混淆 Git 项目的身份、其软件的来源或软件许可的方式。
以任何表明您与 Git 项目之间存在比实际存在的更大关联程度的方式。
以任何暗示 Git 指定了继任者的方式（例如，不允许“Git++”）。
以任何表明 Git 偏爱某一发行版、平台、产品等的方式，除非 Conservancy 明确以书面形式表示。
以任何其他稀释或侵犯 Conservancy 和 Git 项目在标记中的商标权的方式。
要引用 Git 软件，由第三方修改到与基本未修改形式的 Git 软件无法操作的程度。
此外，未经 Conservancy 的书面许可，您不得将任何标记用作新词中的音节或作为合成词（例如，“Gitalicious”、“Gitpedia”）的一部分，用作第三方产品或服务的标记。为避免疑义，即使第三方标记将标记用作音节或作为合成词的一部分来指代产品或服务使用 Git 代码，此规定也适用。
2.4 本政策的限制
本政策不授予使用商标“Software Freedom Conservancy”、“Conservancy”或使用第 1 节中列出的标记以外的任何其他商标的任何权利。本政策不授权您代表 Conservancy 采取行动、代表 Git 项目或 Conservancy 签订任何协议或以其他方式创建任何责任。
2.5 在商品中使用标记
未经 Conservancy 明确书面许可，您不得创建和/或销售带有任何标记的商品。如果您有兴趣使用创建和/或销售带有任何标记的商品，请将您的设计证明发送给我们，地址为 [email protected]。
3 Conservancy 保留的权利
Conservancy 保留以下独家权利
确定是否遵守本政策。
以符合其保护公众使命的方式修改本政策。
对本政策授予例外，无论任何类型和任何原因，尽管有其他条款。
4 问题
本政策旨在保护标记的安全，以保护该软件的声誉，该声誉是由 Git 项目对自由和开源软件社区以及广大公众的贡献所赢得的。如果您在任何地方看到对标记的使用，您认为违反了本政策或以其他方式违背了 Git 项目和 Conservancy 的使命，请通过 [email protected] 联系我们，提请 Conservancy 注意。
如果您对使用商标有任何疑问，或者您认为您应该能够将商标用于本政策不允许的任何目的，并且希望获得该用途的许可，请通过发送电子邮件至 [email protected] 或写信至 Git 项目 c/o Software Freedom Conservancy, 137 Montague St. Ste 380, Brooklyn, NY 11201-3548 联系 Conservancy。
