589次阅读 | 发布于2年以前

关于 Git

Git 是目前世界上最为广泛使用的软件版本控制系统（Version Control System），同时也是一个成熟及活跃的开源项目。

Git 最初是由 Linux 之父 Linus Torvalds 在 2005 年创建，至今已经迭代了17年。但任何程序都会有Bug，对于 Git 这样一个成熟的开源项目也不例外。引用 Linus 的话来说：

“Bugs will happen, if they don’t happen in hardware, they will happen in software and if they don’t happen in your software and they will happen in somebody else’s software.” Torvalds said.

“错误总会发生，如果它们不发生在硬件中，它们将发生在软件中；如果它们不发生在你的软件中，也会发生在其他人的软件中。”

接下来，我们将从一个由 Git 引发的故障，一起来看看如何排查问题，并逐步进行 Git 社区贡献。

Git 问题排查

现场还原

这个问题最初在 2022.6.8 被发现，代码平台服务收到报警，收到了大量的 Git 的代码下载请求。在一番定位之后，发现在部分代码下载的服务器上，发现了下图的一连串 Git 进程：

从上图我们可以看到一个关键点，PID 与 PPID 首尾相连，这是一个典型的嵌套循环问题。

在这个循环当中，产生了大量的 Git 进程，不但对代码平台产生了压力，也对用户本地产生了极大的困扰（本地的进程资源被大量占用）。

所幸这个问题只要满足触发条件，就可以稳定复现。在获取了异常的仓库副本之后，我们就开始了问题剖析之旅。

问题剖析

首先，让我们一起分析下异常仓库的特点：

.git/objects/info 目录下，存在 commit-graph 图文件。
仓库使用了 .git/objects/info/alternates 来引入一些外部的仓库。
使用了局部克隆（Partial Clone）：在 .git/config 当中发现了一些痕迹。

[remote "origin"]
        promisor = true
        partialclonefilter = blob:none

为了不对代码平台产生异常调用，我们尝试在本地电脑上还原这个问题：

我们将异常仓库副本，解压到 work 目录下。
通过 git clone --bare {url} remote.git 我们下载了一个远程仓库。
通过 git -C work remote set-url origin "$(pwd)remote.git" 将 work 的远程仓库设置成本地。

接下来，我们就可以通过执行异常命令来复现问题。

为了更好地跟踪，我们可以通过 GIT_TRACE=1 或者 GIT_TRACE2_EVENT="$(pwd)/event.trace" 来开启过程追踪。

为了更好地定位问题，我们也可以考虑修改 Git 源码，通过 trace_print 增加一些额外的调用日志。此外，我们还可以借助 LLDB / GDB 帮助我们进行本地观察与调试。

最终，在一番努力之后，一个可怕的死循环调用链逐渐浮出水面：

 git fetch
     -> do_fetch_pack_v2() 
         -> deref_without_lazy_fetch() 
             -> lookup_commit_in_graph() 
                 -> repo_has_object_file() 
                     -> promisor_remote_get_direct() 
             -> fetch_objects() 
                 -> git fetch (，我们又回到了最初相遇的地点，开始新的轮回）

原因分析

让我们就着调用链路，再来回顾一下原因：

由于本地是一个的局部克隆的仓库，存在一些对象缺失的情况，而访问这些缺失的对象，就可能产生懒加载拉取。
而在懒加载的过程中，引用查找 deref_without_lazy_fetch() 方法会尝试先去从 commit-graph 提交图当中寻找对象来进行一些加速。
而 lookup_commit_in_graph() 当中，使用了 repo_has_object_file() 来判断对象是否存在于 Git 仓库当中，这个方法，可能引发懒加载拉取本地缺失的对象，开启一轮新的git fetch。
而新一轮的 git fetch ，由于本地存在 commit-graph，在引用查找中，再次进入了步骤2~3的循环当中。

这里有一个关键点，问题是由于提交记录存在于 commit-graph，而在 Git 对象仓库中缺失导致的。这种情况通常并不会发生。结合仓库使用了 objects/info/alternates 来引入外部仓库，我们来猜想一下问题是如何产生的。

猜想验证

如下图当中，通过 objects/info/alternates ，我们引入了一个外部的共享仓库，来减少当前仓库的对象存储。同时，我们创建了一个 commit-graph，来加速本地的提交记录访问。

由于共享的仓库与本地仓库维护的引用列表（分支、标签等统称为引用）并不相同，在触发 git gc或者自动 gc 之后，由于提交记录 B 是一个不可达的对象（不存在于任何引用当中），导致了存在于 commit-graph 当中的共享提交记录 B 被清理了。

这时候，只要在当前仓库触发了懒加载，就会引发前面的死循环调用链，产生大量的 Git 进程，最终拖垮用户本地及远端服务。

虽然从原因来看，这个问题的产生，某种意义上是由于不合理使用 alternates 及 commit-graph 导致的，但我们的确很难限制用户该如何使用。于是，我们决定寻求 Git 社区的帮助。

寻求 Git 社区帮助

我们决定，派你出发，开始这次的 Git 社区之旅。

芝麻开门

提到开源社区，大家都会不约而同想到Github[1]，比较这可是全球最大的“程序员交友社区”。

可当你兴冲冲地跑到 https://github.com/git/git 准备提交一个 Issue (问题）时，嗯？说好的Issues 入口去哪了？

再看右边的描述：

虽然，你可以通过 Github 上的 GitGitGadget 机器人帮助我们进行补丁提交，可是你现在只是想请教社区一个问题，该怎么办呢？

曲径通幽

在 git-scm.com 上，通过阅读《MyFirstContribution》[2]，你找到了寻求帮助的三个路径：

1、git@vger.kernel.org这是主要的 Git 项目邮件列表，用于进行代码审查、版本公告、设计讨论等。

这也是目前 Git 社区最主要的交流方式，Github 上的 GitGitGadget 也是帮助你做邮件转换的工作。

任何有兴趣贡献的人，都在这里发布问题。

但需要注意的是，Git 列表需要纯文本电子邮件，并且在回复邮件时更喜欢内联和底部发布。

2、git-mentoring@googlegroups.com此邮件列表面向新的贡献者，并被创建为在主列表的公众视线之外发布问题和接收答案的地方。对帮助指导新人特别感兴趣的资深贡献者出现在列表中。为了避免搜索索引器，查看消息需要组成员身份；任何人都可以加入，无需批准。

3、#git-devel[3] 在 Libera Chat[4] 上这个 IRC 频道用于 Git 贡献者之间的对话。

如果有人当前在线并且知道你的问题的答案，你可以实时获得帮助；或者你也可以阅读 scrollback[5] 以查看是否有人回答了你。但IRC 不允许离线私信，因此如果你尝试私信某人然后退出 IRC，他们将无法回复你。

你随意翻开如下链接中看到了其中一天的讨论：

https://colabti.org/irclogger/irclogger_log/git-devel?date=2022-06-20

新手上路

接下来你选择使用邮件的方式，请求社区的帮助，于是，你奋笔疾书，写了一封邮件。

当你通过 git@vger.kernel.org 发送邮件到社区之后，就可以通过 https://lore.kernel.org/git 这个公共的收件箱列表，找到刚才发送的邮件。

除此之外，你惊喜地发现，新世界的大门正式向你敞开：

由于“Git 列表需要纯文本电子邮件，并且在回复邮件时更喜欢内联和底部发布”，因此在使用邮件服务时请特别注意：

例如使用Gmail时，请选择“Plain text mode”：

你也可以选择使用git send-email来发送/回复邮件：

https://kernel.org/pub/software/scm/git/docs/git-send-email.html

你可以通过点击 permalink 找到如下的命令行：

  git send-email \
    --in-reply-to={Message-ID} \
    --to=someone@email.com
    --cc=git@vger.kernel.org \
    --subject='Re: [PATCH v2 0/1] scalar: move to the top-level, test, CI and "install" support' \
    /path/to/YOUR_REPLY

请特别注意携带 in-reply-to，只有这样你的邮件才会被很好地组织在一起，避免丢失一些上下文。

小试牛刀

在与社区交流的过程中，你不断深入，找到了可行的修复方案。我想，此刻的你一定跃跃欲试，想尽快将自己的修复方案发给社区。但如果你不想石沉大海，或是迎来一些不必要的批评，请你先保持冷静，除了前面提到的《MyFirstContribution》，你还需要再做一些准备工作。

1、阅读 Git 的《补丁提交》[6]> https://github.com/git/git/blob/master/Documentation/SubmittingPatches

《补丁提交》将指导你如何建立自己的工作，比如该基于 maint（稳定版本）还是该基于master ，又或者是指导你该如何清晰地表达这个补丁的价值。

在这个文档当中，你将学到关于补丁制作与提交的方方面面。

2、阅读 Git 的《编码指南》[7]> https://github.com/git/git/blob/master/Documentation/CodingGuidelines

《编码指南》将帮助你了解一些Git非常较真的编码规范，从下面的一个例子你就可以看出他们对空格有多么的较真：

        (incorrect)
        cat hello > world < universe
        echo hello >$world

        (correct)
        cat hello >world <universe
        echo hello >"$world"

3、学习如何编写 Git 的测试用例> https://github.com/git/git/blob/master/t/README

Git 当中，使用一套以 shell 脚本为主，名为Sharness的测试框架。这套测试框架在2011年创建，并从 Git 的 test-lib.sh 当中派生出来，成为了一个独立的项目：https://github.com/chriscool/sharness

4、勇敢发送你的补丁当你一切准备就绪，确认Github CI也亮起了绿灯，勇敢地发送你的补丁吧，开始属于你的Git贡献之旅。

小结

我们从一个 Git 引发的故障开始，了解了 Git 问题排查的过程，在找到并复现问题之后，尝试寻求 Git 社区的帮助，并小试牛刀，向 Git 社区提交了我们的补丁。

Git 自2005年开始发展至今，正是由于其广泛的使用，以及一大批优秀的社区贡献者，让 Git 变得越来越好。使用 Git，发现问题并改进它，在这个过程中你一定可以得到别样的收获。

附录

Github：https://github.com
《MyFirstContribution》：https://git-scm.com/docs/MyFirstContribution / https://github.com/git/git/blob/main/Documentation/MyFirstContribution.txt
#git-devel：https://web.libera.chat/#git-devel
Libera Chat：https://libera.chat
scrollback：https://colabti.org/irclogger/irclogger_logs/git-devel
CodingGuidelines：https://github.com/git/git/blob/master/Documentation/CodingGuidelines
SubmmitingPatches：https://github.com/git/git/blob/master/Documentation/SubmittingPatches

如何向 Git 社区提交补丁代码