如果有参与过GitHub上面一些开源仓库的代码贡献，可能会比较习惯于通过github平台进行merge request这种方式来向开源社区提交代码。

但是像是Linux这种仓库使用了另一种代码提交方式，通过邮件列表的方式。

我们提交代码需要包含最基本的内容就是代码，除此之外可能还要有一个沟通渠道，代码贡献者于代码维护者之间要对代码进行一些讨论、交流的过程。

邮件列表即实现了这几种功能：

所有于github的开源项目不同，linux内核时通过发邮件的方式来贡献提交代码的，并且所有的交流邮件内容会在一个网站显示出来，所有人都可以进行查看邮件内容。

现在开始贡献代码的第一步，修改代码，并生成补丁文件。

我们在开发过程中如果发现了代码中的问题，就可以去修改并提交代码到社区。

首先需要下载内核代码的git仓库，好像对仓库的分支没有严格要求，可以选择使用 main 分支进行拉取。

接着我们可以对代码进行修改，并创建一个commit，这里在创建commit的时候，要注意commit message的内容，因为是开源项目，所以相关的信息一定要描述符合规范，并且描述清晰。如果不清楚该怎么写，可以参考下你修改的文件之前的其他人的commit message内容格式，一般来说按照相同文件的格式来描述是最好的，毕竟该文件的维护者也是固定的几个人，他们也是认可这样的格式。

假设我们修改的源文件是 drivers/spi/spi-cadence-quadspi.c , 就可以执行如下的命令来查看一些之前其他人的提交内容，了解下提交的格式

从这一条提交记录也可以大致猜到一些格式：

应该是固定格式，表示我们要修改的源文件， 后面紧接着是一条概括性的语句，概况本次提交的主要内容

接着下面用一个段落来详细描述本次提交的内容，可以介绍一下修改的内容，修改的原因等等

第三段是签名的内容，签名主要是为提交者署名，正常提交时，我们在 commit 时加入 -v 参数后会自动在commit message后面添加上自己的签名

第一条内容就是提交者的签名

第二条内容是这条提交的邮件讨论链接，记录了从代码提交到交流到最终合并的过程

第三条内容是合并你的代码的人员的签名。

在我们修改代码，完成 commit 的动作，并且清晰、符合规矩的描述了 commit message 之后，就可以生成一个patch文件。patch文件将会包含你本次提交的代码差异以及commit message的内容，保存在一个文本文件中，后缀是 .patch , 具体怎么生成patch文件的更多内容可以搜索git生成patch文件相关教程。

如果你是要生成最近提交的一笔commit的patch ， 可以输入命令 git format-patch -1 ，会生成一个文本格式的patch文件

我们生成补丁文件之后，就可以通过邮件工具来发送补丁的内容

发送邮件，首先要知道发给谁。linux整个内核十分庞大，所以内核的维护也是由很多人负责。我们需要将补丁发送给该模块、该文件的维护者，内核中提供了相关的脚本来自动分析文件的维护者，获取维护者的邮箱地址。

这里我们使用命令 ./scripts/get_maintainer.pl drivers/spi/spi-cadence-quadspi.c就可以得到文件 drivers/spi/spi-cadence-quadspi.c 的维护者的邮箱列表了，接下来我们发邮件时，收件人就是这几个邮箱。

发送邮件也是通过命令行完成 ， 可以使用工具git工具提供的命令git send-email

我们平时发送邮件时需要使用用户名和密码登录邮箱，但是该工具使用另一种方式登录发件人的邮箱，使用SMTP协议来登录并发送邮件，SMTP协议需要在邮箱的设置界面进行开通和设置。

以网易邮箱为例，登录到网页版邮箱之后，点击设置，选择 POP3/SMTP/IMAP 选项，进入后选择开启SMTP服务。

接着在授权密码管理选项中新增授权密码，授权密码时一种动态生成的密码，我们需要记录下本次生成的授权密码，并填入到git工具的配置文件中，此时git工具才能登录你的邮箱发送邮件。

git配置文件路径是 ~/.gitconfig , 打开并编辑该文件，下面是使用网页163邮箱的配置方法。其中 smtpPass 填入刚刚生成的动态密码

完成邮箱的SMTP服务配置之后，我们就可以发送邮件了,发送邮件使用下面的命令

执行上面的发送命令之后 git send-email 工具会自动登录邮箱并向对应的发件人发送邮件。发送的内容就是patch文件中的内容。所以这也是要认真填写commit message的内容的原因，它将会成为邮件的正文。

执行完成上面的发送命令之后，我们可以登录邮箱查看一下发件箱，也会显示出来刚才使用git send-email 工具发送的邮件

对比一下我们的 commit message && patch && 邮件 可以发现一些规律：

commit message 内容的第一行变成了 pathc 文件的 subject 行， 进而在发送邮件时变成了邮件的主题

commit message 内容的介绍段落以及签名、提交的代码变成了邮件的正文。其中代码差异部分使用 -- -- 包含

有没有发现 commit message、patch 、邮件在内容格式上好像真的有一些对应关系，出现这样的现象，究竟是一种巧合，还是说设计者就是出于这样的目的取设计的呢？很多时候当我们参与一些事情的时候事情已经发展了很久，对于其最合理的使用方式可能慢慢消失或者发生了变化，被新的工具，新的方法取代。

邮件发出之后，我们也可以在网页公共的邮件列表中看到我们发送的内容 ：

https://lore.kernel.org/r/[email protected]

如果维护者回复了你的邮件，我们可以在公共邮件列表中看到回复的内容，也可以在自己邮箱的收件箱中收到对应的邮件，以及如果有更多需要讨论的也可以通过邮件进行讨论交流和回复。

对于上面的简单代码修改，由于没有进行代码逻辑的修改，只是修改了一些字母和拼写，所以合并的流程也不会太过于负责，基本上维护者可以一次性通过，没有经过过多的讨论。从提交代码发送邮件之后，大概一俩天就有人回复了邮件并进行了合并。

所有的合并操作都是由维护者完成，由维护者将邮件中的代码修改合并到代码仓库。

合并了代码之后，我们的提交记录就会永远保留在Linux内核的仓库，以后可能你修改的代码可能会在各种地方运行。