Git 是常用的去中心化源代码存储库。它是由 Linux 创建者 Linus Torvalds 创建的，用于管理 Linux 内核源代码。像 GitHub 这样的整个服务都是基于它的。因此，如果您想在 Linux 世界中进行编程或将 IBM 的 DevOps Services 与 Git 结合使用，那么深入了解 Git 会很有帮助。

当我开始使用 Git 时，我对并发版本系统 (CVS) 和 Apache Subversion (SVN) 有一些经验，因此我尝试从这些经典的源代码存储库系统的角度来理解它。这种思维方式只让我对 Git 的功能了解有限。从那时起，我对 Git 有了更好的理解，所以这篇文章是一种“自我笔记”文本，旨在提醒自己 Git 是如何工作的，并向那些刚接触 Git 的人解释它。我假设您了解其他更经典的源代码存储库（如 CVS 或 SVN）。

基础知识

因此，让我们从经典源代码存储库中的一个基本示例开始，如图 1 所示。在经典源代码存储库中，包含文件和子文件夹的文件夹将作为内容进行处理（CVS 和 Git 实际上不处理文件夹，仅处理位于路径位置）。存储库保存内容的所有版本，而工作目录是您修改代码的位置。您将代码从存储库检出到工作目录，并将在此工作目录中所做的更改提交回存储库中内容的新版本。

图 1. 经典源代码存储库工作区处理

每次提交都会创建一个新的内容子版本，该内容派生自您修改的先前父版本，如图 2 所示。内容存储为一系列版本（也称为快照），通过创建的父子关系链接通过提交操作。通过提交在父版本和子版本之间发生更改的信息称为更改集。

这一系列的版本称为流或分支。在SVN中，主流称为trunk；在 CVS 中，它通常称为HEAD；在 Git 中，它通常被命名为master。分支在实施项目中用于分离特定功能的开发或用于旧版本的维护。

图 2. 在经典存储库中创建新版本

到目前为止，Git 看起来非常像这种经典的源代码存储库，不是吗？不幸的是，相似之处就到此为止了。 CVS 和 SVN 的一大特点是它们有一个中央存储库。 Git 是去中心化的。多个存储库可以在软件开发中协同工作，事实上，每个开发人员的存储库的工作和通信方式与任何基于服务器的 Git 存储库相同。

Git 的工作原理

一旦理解了 Git 的主要原理，就会发现它非常简单。

首先，Git 处理快照中的内容，每次提交一个快照，并且知道如何应用或回滚两个快照之间的更改集。这是一个重要的概念。在我看来，理解应用和回滚变更集的概念会让 Git 更容易理解和使用。

这才是真正的基本原理。其他任何事情都由此而来。让我们进一步深入研究 Git。

使用 Git

首先，这里列出了使用 Git 时将使用的常用命令：

• git init-- 初始化存储库
• git checkout <branch>-- 将存储库中的分支检出到工作目录中
• git add <file>-- 将文件中的更改添加到更改集
• git commit-- 将更改集从工作目录提交到存储库

要开始使用 Git，您只需运行git init命令。它将当前目录转换为 Git 工作目录，并在.git它创建的（隐藏）目录中创建存储库。然后您就可以开始使用 Git。checkout和命令commit与其他源代码存储库类似，但对更改集的关注是在 Git 中拥有该命令的原因add（类似于 SVN）。使用此命令，工作目录中的更改将添加到下一次提交的暂存区域。该暂存区通常称为索引。图 3 说明了创建从快照版本 A 到快照版本 B 的更改集的过程。

git status帮助您跟踪您所在的分支上已添加或未添加哪些更改。

图 3. 在 Git 中创建更改集

git log显示工作目录中的更改（即提交）的历史记录，或git log <path>应用到给定路径的更改的历史记录。

同时git status列出了工作区中修改过的文件以及索引中的文件，您可以通过命令查看文件之间的差异git diff。仅使用git diff（不带参数）仅显示工作目录中尚未添加到索引中的更改。您需要使用git diff --cached来查看索引中实际内容：暂存的更改。git diff <name>或git diff <name> -- <path>分别显示当前工作目录与工作目录或给定路径的命名提交之间的差异。该名称可以是提交 ID、分支名称或其他名称。现在是讨论命名的好时机。

命名

注意：
由于提交 ID 的长度，我将在图中仅使用“(A)”、“(B)”等缩写。

让我们看一下 Git 中事物的命名。快照是 Git 中的主要元素。它们以提交 ID命名，这是一个哈希 ID，例如“c69e0cc32f3c1c8f2730cade36a8f75dc8e3d480”。它源自快照的内容，由实际内容和一些元数据组成，如提交时间、作者信息、父母等。快照没有像 CVS 那样的点号版本，也没有交易编号（和/branches 顶级目录下的路径）与 SVN 中一样。因此，您无法像在其他存储库中那样从 Git 快照名称确定任何类型的顺序。为了方便起见，Git 可以通过从 ID 开头获取最少数量的字符，将这些长哈希缩写为短名称，以便短名称在存储库中仍然是唯一的。在上面的示例中，简称为“c69e0cc”。

请注意，术语commit既用作创建快照的动词，也用作生成的快照的名称。

通常您不必使用提交 ID；相反，您与分支机构一起工作。在其他源代码存储库中，命名的更改流称为分支。在 Git 中，更改流是更改集的有序列表，因为它们被一个接一个地应用以从一个快照转到下一个快照。Git 中的分支只是指向特定快照的命名指针。它指出了使用此分支时应应用新更改的位置。当更改应用于分支时，分支标签也会移动到新的提交。

Git 如何知道将工作区中的更改放在哪里？这就是 HEAD 所指向的地方。开发的 HEAD 是您最后一次检查工作区的位置，更重要的是，是提交更改的位置。它通常指向您上次签出的分支。请注意，这与 CVS 将术语 HEAD 解释为默认分支的开发技巧不同。

该tag命令命名一个提交，并允许您使用可读的名称来寻址单个提交。基本上，标签是提交 ID 的别名，但也可以使用一些快捷方式来处理提交。 HEAD 作为工作目录中的开发提示。 HEAD^1 是 HEAD 提交的第一个父级，HEAD^2 是第二个，依此类推。

有关更多详细信息，请参阅gitrevisions主页。因为像标签或分支名称这样的名称是对提交的引用，所以它们被称为refnames。引用日志显示名称生命周期内发生的更改，从创建名称（通常由分支）到当前状态。

分枝

分支背后的概念是每个快照可以有多个子快照。将第二个更改集应用到同一个快照会创建一个新的、独立的开发流。如果命名的话，就称为分支。

图 4. Git 中的示例分支结构

图 4 通过 Git 中的示例分支结构说明了这一点。当前发生一些开发的主分支指向快照 F。另一个旧分支标记了旧快照，也许是一个可能的修复开发点。功能分支对特定功能有其他更改。更改集被标记为从一个版本到另一个版本，例如“[B->D]”。在此示例中，快照 B 有两个子级，两个开发流从那里开始，一个用于功能分支，另一个用于其他分支。提交 B 也被标记为修复编号 123 的错误。

您需要了解的其他命令：

• git branch <branchname>-- 从当前 HEAD（工作目录）创建一个新分支
• git checkout -b <branchname>-- 从当前 HEAD 创建一个新分支，并将工作目录切换到新分支
• git diff <branchname> - <path>path-- 显示工作目录和给定分支之间的差异
• git checkout <branchname> - <path>-- 将给定分支中的文件检出到工作目录中
• git merge <branchname>-- 将给定分支合并到当前分支
• git merge -abort-- 中止导致冲突的合并

分支是使用git branch <branch name>当前 HEAD 或git branch <branch name> <commit id>任何有效快照版本上的命令创建的。这会在存储库中创建一个新的分支指针。请小心，以这种方式分支会将__您的工作空间保留在旧分支上。您需要先签出新分支。随着git checkout -b <branch name>新分支的创建，您的工作空间也将移动到新分支。

另外两个命令相当有用：

• git diff <branch> -- <path>如上所述，打印当前工作目录和指定分支之间给定路径（文件或目录）的差异。
• git checkout <branch> -- <path>将不同分支中的文件检出到工作目录中，以便您可以从另一个分支中选择更改。

合并

当您实现新功能时，您将其签入存储库，例如，在“功能”分支上。当该功能完成后，您需要将其合并回 master 分支。您可以通过检查 master 分支并使用 来完成此操作git merge <branch name>。然后，Git 将给定分支的更改合并到已签出的分支中。 Git 为实现此目的所做的是将功能分支中的所有更改集应用到主分支的尖端。

根据两个分支中的更改类型以及可能的冲突，可能会发生三种可能性。

• 快进合并：由于两个分支分歧，接收分支没有得到任何更改。接收分支仍然指向另一个分支分歧之前的最后一次提交。在这种情况下，Git 将接收分支的分支指针向前移动，如图 5 所示。由于除了向前移动分支指针之外没有其他操作，因此 Git 将其称为快进合并。

  图 5. 快进合并

  

• 无冲突合并：两个分支都有变化，但不冲突。例如，如果两个分支中的更改影响不同的文件，就会发生这种情况。 Git 可以自动将其他分支的所有更改应用到接收分支，并创建包含这些更改的新提交。然后接收分支向前移动到该提交，如图 6 所示。

请注意，生成的提交（合并提交）有两个父级。不过，我还没有注意到这里的更改集。原则上，从（E）到（H）的变更集将是自两个分支转移以来来自特征分支的所有变更集的组合，但这可能使类比太过分了。

图 6. 无冲突合并

• 冲突合并：两个分支都有更改，但它们发生冲突。在这种情况下，冲突的结果将保留在工作目录中，供用户修复和提交，或者中止与git merge –abort.

需要注意的一件有趣的事情是，合并会查找两个分支中应用了相同补丁的实例。因为两个分支都有更改，这通常会导致冲突，但由于 Git 足够智能，可以检测到这种情况，因此您仍然可以进行快进合并。

回滚和重放变更集的概念进一步体现了诸如变基和挑选等高级功能。

有时您开发了一个功能，但主开发也在并行进行，而您还不想合并您的功能。结果将是两个分支很快彼此远离。然而，可以将变更集从一个分支应用到另一分支。 Git 为此提供了 rebase 和cherry-picking 功能。

变基

想象一下，您正在开发您的功能，并且需要合并主分支的最新更改以跟上总体开发的步伐。这就是所谓的功能分支变基；它将两个分支之间的分流点向上移动到其中一个分支上。 Git 所做的是，然后它会在另一个分支的顶端重播一个分支的更改，为每个原始提交创建新的提交。在图 7 所示的示例中，它尝试将来自 master 分支顶部的功能分支的更改应用。

图 7. 分支变基

如果重播导致冲突，则变基会在第一次冲突时停止，并将冲突状态保留在工作目录中供用户修复。然后可以继续或中止变基。

使用该--onto选项，变基实际上可以将转移点“移动到”另一个分支中的任何较新的快照上。

樱桃采摘

想象一下，您现在正在开发一项功能，并且已经开发了一些更改，应该立即将其放入您的主开发中。这可能是一个错误修复，或者是一个很酷的功能，但您还不想合并或变基分支。 Git 允许使用樱桃选择功能将更改集从一个分支复制到另一个分支。

在这种情况下，如图 8 所示，Git 仅应用导致 HEAD 上选定快照的更改集（例如 master 分支）。这里通常实际使用提交 ID，也称为哈希值。

图 8. 择优选择提交

恢复

该revert命令回滚工作目录上的一个或多个补丁集，然后在结果上创建一个新的提交。revert几乎与樱桃采摘相反。有关示例，请参见图 9。

图 9. 恢复提交

该revert命令将恢复记录为新提交。如果您不希望记录下来，可以将分支指针重置为较早的提交，但这超出了本文的范围。

那么为什么我要如此详细地讨论这一部分呢？这是因为在下一节讨论协作功能时理解这些功能至关重要。事实上，一旦你理解了第一部分，第二部分几乎立刻就清楚了。大多数协作功能都基于迄今为止讨论的基本功能。

合作

在经典的源代码存储库中，总是有一个明确的概念：什么是分支；这是中央存储库上的一个。

然而，在 Git 中，不存在主分支这样的东西。等等，我上面不是写了一般都有一个master分支吗？是的，我做到了。然而。该 master 分支仅存在于本地。除了您创建的关系之外，一个存储库中的 master 分支与另一存储库中的 master 分支之间不存在任何关系。

图 10. 两个存储库

如果您已有存储库，则可以使用该git remote add命令添加远程存储库。然后你可以使用命令在你自己的存储库中获取远程分支的镜像fetch。这称为远程跟踪分支，因为它跟踪远程系统上的开发。

当您签出仅作为远程跟踪分支（而不是本地分支）存在的分支时，Git 会自动从远程跟踪分支创建本地分支并签出该分支。

一旦完成，您就可以将远程分支的内容合并到您自己的分支中。图 11 显示了签出到本地 master 分支，但情况不一定如此，您可以将其合并到具有公共历史记录的任何其他分支，如普通合并命令。

图 11. 获取并签出远程分支

另一种方法是使用git clone例如从托管服务获取远程存储库的命令。这会自动获取所有远程分支（但还没有本地引用）并签出主分支。

正如您所看到的，一种模式出现了。因为远程存储库分支“只是一个分支”，所以上面讨论的有关分支、合并等的所有内容几乎无缝地适用于这里，特别是在从远程存储库获取更改时。

图 12. 获取远程更改

在图12中，git fetch示出了a；它更新远程跟踪分支。然后，您只需在远程跟踪分支和本地分支之间执行正常的合并操作，在本例中git checkout master; git merge repo1/master。提取后，您可以使用FETCH_HEAD合并命令中的名称作为提取的远程分支的快捷方式，例如git merge FETCH_HEAD.此外，与上面的讨论类似，此合并可能会导致快进合并、无冲突合并或需要手动解决的冲突。

该命令是与git pull结合使用的便捷命令。fetchmerge

当更改已提交到本地分支时，必须将它们传输到远程分支。这是通过push将本地更改推送到远程分支的命令来完成的。它是相反的fetch，而不是相反的pull。然而，它的作用不仅仅是获取，因为它更新远程分支的本地副本以及其他存储库中的远程分支，如图 13 所示。push还允许您在远程存储库中创建新分支。

图 13. 推送更改

有一个保障。仅当推送会导致远程存储库中的远程分支上的快进合并时，它才会成功，否则会中止。如果情况并非如此，则远程分支已经有来自其他存储库或提交者的一些其他更改（提交）。 Git 中止推送并让一切保持原样。然后您必须获取更改，将它们合并到本地分支中，然后再次尝试推送。

请注意，在这种情况下，您可以进行正常合并，但也可以选择进行变基合并，以将本地分支中的更改变基到远程分支的新的、更新的头。

除了 fetch 和 push 命令之外，还有另一种分发补丁的方法：旧式，通过邮件。为此，有一个命令git format-patch <start-name>，它为从给定提交到当前分支状态的每个提交创建一个补丁文件。git am <mail files>将这些补丁文件应用到当前分支。

注意事项

一个警告：如果您尝试推送到一个存储库，其中有人实际跟踪分支并在本地对其进行处理。这可能会扰乱分支管理，因此 Git 会警告您并告诉您首先将远程分支的状态与pull.

很明显，您不应该对远程跟踪分支进行变基。它不再与远程分支匹配，因此它不会在push.您已经破坏了存储库结构。

高级 Git

图 14. 多存储库结构示例

通常情况下，即使使用 Git，也存在星型结构，其中有一个中央存储库作为主存储库，以及每个用户的本地存储库。但情况并非一定如此。您可以像在 Web 中一样使用交叉连接添加远程存储库连接，如图 14 所示。

上面我将变基描述为在原始分支的不同分支（或转移）点之上重放更改集。 Git 通常按照提交的顺序进行重播。作为一项高级功能，git rebase -i您可以实际选择应按何种顺序进行哪些提交，即使可以删除提交或可以组合两个提交（“压缩”）。只需确保不要对已推送的提交执行此操作 - 否则，那些基于这些提交进行工作的提交可能会产生很多冲突。

我还编写了如何检查特定分支，但您也可以检查任何提交（快照）。这让 HEAD 指针指向提交，而不是分支。这称为分离 HEAD模式。当你在这种情况下做出改变时，你就开始了新的发展。基本上，您会进行分支，但没有为这个新分支指定分支名称。开发的尖端只能通过使用提交 ID 才能到达；任何引用名称都无法访问它。您可以使用通常的“”命令从此 HEAD 创建分支git branch <branchname>。

任何引用都无法访问的提交会发生什么情况？好吧，如果您不做任何特殊的事情，它们就会保存在存储库中。但是，您可以（托管服务可能实际运行git gc）Git 垃圾收集器来删除不必要的文件。任何引用名称都无法访问的提交是不必要的，因此将被删除。因此，始终在真实分支上工作是一种很好的做法，尤其是当在 Git 中创建新分支如此快速且轻松时。

结论

Git 一方面基于简单的原则，但它提供的灵活性有时可能令人难以承受。主要要点是 Git 管理快照以及快照之间的更改集。最常见的命令应用并回滚不同分支之间的这些更改集。第二个要点是，处理远程分支基本上与处理本地分支相同，因为甚至存在远程分支的本地镜像。

至此，我已经快速浏览了 Git 的工作原理。这些命令基本上涵盖了我使用 Git 所做的所有操作。所有命令的更多详细信息可以在相应的手册页中找到，通过此处提供的知识，您希望能够更好地理解它们并使用它们。此外，命令本身git status通常会给出下一步该做什么的宝贵提示。

另一个帮助你理解 Git 的好工具是图形化的gitk工具，它显示了本地存储库的结构。用于gitk --all显示所有分支和标签等。它还提供了一个简单的界面来在 Git 上发起操作。

Git 通常已经安装在您的 Linux 系统上。您可能必须从包管理器安装开发工具。对于 Windows，您可以在Git 主页上下载它。

我希望现在您对 Git 的工作原理有了更好的了解，并且不再害怕使用它的灵活性。

感谢我的同事 Witold Szczeponik 对这个主题进行了一些有趣的讨论，并审阅了本文，他比我更了解 Git。