前言

作为现在最流行的开源分布式版别控制系统，Git 的诞生超越17年，但现在仍然具有非常活泼的开发者社区，远超一般开源软件的生命周期，其代码奉献者也现已超越 1.5K，并且仍连绵不断有新增奉献者，这使得 Git 能够持续不断地有各种更新、功用优化等等。

但是要想参与到这个大型的国际化的开源社区中来并成为源码奉献者，关于国内很多开发者来说并不是那么简略。

在 Gitee 架构团队中，我有时机深入探求 Git 的底层原理，以及 Git 的一些运用，这个进程中我也成为了 Git 社区的奉献者。截至现在，我向 Git 社区提交了 4 次代码。 现在，作为奉献者中的一员，我很乐意分享这个进程，以便协助更多人有时机参与到像 Git 这样的大型开源社区中来。

这个系列将从 Git 社区奉献者的角度，向广大开发者分享我怎样向 Git 官方社区提交代码，以及从提交代码到最终兼并代码的整个进程。

起因

假如你在运用 Git 时发现了 bug，或许觉得某些指令没有你想要的功用，或许你发现它的协助文档描绘不够清晰让你感到利诱，你完全能够自己修正 Git 源码，然后实现自己的预期功用。

获取源码

首要从 Git 在 Github 镜像仓 上 fork 出一个自己的库房，然后克隆到本地：

$ git clone https://github.com/myfork/git mygit
$ cd mygit
# 增加上游远程库房，便于更新最新代码
$ git remote add upstream https://github.com/git/git

编译源码

确保在未作任何修正之前，代码不缺少任何编译依赖，能够正常编译。

# 切出一个自己的主题分支
$ git checkout -b myown-topic origin/master
$ make DEVELOPER=1

topic 是个人主题分支，所谓主题便是自己要修正什么那便是什么主题。

编写代码

其实在老练的项目中编写新代码的进程便是一个仿照的进程，先调查他人是怎样写的，再仿照写即可。比方，调查他人是怎样界说变量，在哪里界说，怎样处理缩进，怎样界说函数等等，依照相同的风格进行仿照大致是不会犯错的。 假如想看详细的编码规范，可参阅 Git 代码编写规范

测验代码

Git 测验代码绝大部分是用 shell脚本写的，由于 Git 本来便是一个Linux下的指令行东西，对它的测验便是由一系列指令组成的，所以就很自然地运用 shell 脚本写测验用例。 它有自己共同的测验框架，这个在前期咱们不必深究。那怎样写测验代码呢，答案也是仿照。 详细测验代码都在 t/ 目录下，请阅览 t/README 文档，参阅测验编写规范，然后编写测验用例。

当然，假如有需求，我能够再写一篇详细介绍 Git 测验框架以及怎样写 Git 测验代码的文章。

PS. 向开源软件奉献代码不必定非得是修正核心代码，或许说非得搞一个什么特性，或许解决什么 bug, 只完善文档，完善测验代码也是一种方法奉献，并且这关于入门者好处多多：更简略成功，形成激励闭环，能够了解一整套流程，了解这个开源社区的气氛，规范等等。

例如，对照 t/README 中引荐的测验风格 Recommended style章节，能够在测验代码中找到一些不符合引荐风格的测验代码，然后向社区提交PR。这个任务就留给有心人啦。

运转单项测验：

$ make DEVELOPER=1
$ cd t/ && prove t9999-psuh-tutorial.sh

或许运转悉数测验，以确保自己的修正没有影响其他代码运转：

$ cd t/
$ prove -j$(nproc) --shuffle t[0-9]*.sh

文档更新

假如修正是新增某个特性，或许增加某个选项装备等，都需求补充文档，装备阐明，乃至是原理解析等等。

Linux环境中需求安装 asciidoc 东西，来支撑文档

$ sudo apt-get install asciidoc
$ make all doc
$ make check-docs

对待文档需求跟对待代码一样，由于它们相同重要。 和编写代码一样，需求遵循已有文档的风格，详细风格辅导文档请参阅可参阅 Git 代码编写规范中的 Writing Documentation 章节。

编写 commit

编写 commit 信息也是很重要的一步，这个后续系列文章我会专门阐明这一点。

创建 commit 的准则，首要是对逻辑上不同的更改进行不同的提交(make separate commits for logically separate changes)，也便是坚持每个commit尽量独立且是最小更改。

每条 commit 需求带上签名，运用 git commit -s ，-s/--signoff 选项会在 commit 尾部加上 Signed-off-by：签名信息。

编写commit message 需求遵循必定规范，如下图：

如何向 Git 官方社区提交代码(一)

关于commit message, 官方主要维护者说：A canonical form of our log message starts by explaining the need, and then presents the solution at the end.(一个规范的格局的 commit message 应该在最初描绘需求，在结尾展现解决方案。)

commit head 部分不超越 50 个字符

commit body 部分不超越 76 个字符

向社区提交代码

首要有以下几点需求注意：

  • Git 库房主要有 5 个分支，master, maint, seen, next, todo。其中：

seen 是调查分支，向官方提交一般补丁，开始被承受后还需先进入调查期，即兼并到seen 分支，此时还要持续承受他人的代码检视，可能会持续修正。

next 是预备分支，当 seen 上预备好了后，进入 next 分支，承受更多更广泛的测验，确保新补丁不会引发其它 issue。

master 是安稳分支， 在 next 分支上的补丁经过各种测验后，就能够进入安稳分支。

maint 是维护分支，bugfix 一般在这个分支上进行(也能够在 master 分支上进行)

  • 向社区发送邮件至少需求以下邮件地址：
  1. 主送官方邮件列表(有必要)： git@vger.kernel.org。
  2. 抄送代码相关人。比方你的补丁修正了某个文件的某行代码，经过 git-blame 知道这行代码之前的修正者，那么最好也要抄送给这个人，由于他应该比你更了解这行代码。
  3. 抄送现在主要维护者: gitster@pobox.com
  • Git 社区交流都是用纯文本邮件方法，邮件回复有很多种方法，常见的有 top-posting, bottom-posting, interleaved-style(也叫inline-style)。邮件回复方法概况见 Posting_style Wiki
  • Git 官方社区引荐用 inline-style 回复邮件。

向官方提交代码的方法主要有两种:

一. 经过 Git 指令行：

  1. git format-patch 制作补丁包；
  2. git send-email 发送邮件到官方社区。

二. 经过 GitGitGadget：

  1. 运用Github的PR作业流，向 GitGitGadget 的 Github 库房 提交 PR；
  2. 找人邀请自己，让他人在 PR 谈论区发送 /allow(仅针对第一次提交PR的用户)；
  3. Github CI 经往后，发送 /submit 触发脚本，主动发送格局化的邮件到官方社区。

经过指令发送邮件向社区提交代码的方法遵循的是比较陈旧的 mailing list(邮件列表)作业流程，关于现在习惯了直接在网页上提交 PR/MR 的用户来说，邮件列表的方法比较复杂，不建议运用这种方法。但是假如想了解的话，能够参阅如下链接：Submit Your Patch

GitGitGadget 相当于一套主动化程序，实现了 Github PR 作业流，使一切人能够直接在 Github 上经过提交 PR 的方法向 Git 官方提交代码，这极大的简化了原来的 mailing list作业流。一切这儿引荐运用这种方法进行提交代码。

怎样在 Github 上提交 PR 大部分人应该都会，一切这儿就不打开讲了。关于第一次向 Git 库房提交代码的情况，这儿简略阐明一下：

当在本地库房依照前面的方法编写好 commit 后，push 到自己 fork 的库房后，回到 gitgitgadget/git 库房，能够看到：

如何向 Git 官方社区提交代码(一)
只需求点击绿色按钮，就能够创建 PR 了。

GitGitGadget 能够检测到用户是第一次提交 PR ，所以 gitgitgadgetbot 会主动在 PR 下面发送谈论，提示用户该怎样操作。这儿最重要的一点便是用户(你)需求找一个现已向 Git 成功提交过 PR 的人在你的 PR 谈论区发送 /allow 指令，这样你才被真正允许提交 PR。

假如一切顺利，这时候你只需求在 PR 谈论区发送 /submit 指令，GitGitGadget 程序会主动将你的 PR 转化为 Git 社区能够承受的格局，并发送到 Git 邮件列表 中。

提交成功！

/submit 指令发送成功后，第一次向 Git 社区提交代码就成功啦！ 但是，这只是成功的第一步，后续的代码检视，以及你对检视意见的回应才是重点。这将鄙人一篇文章中介绍。