这篇向导专为那些希望在该软件上做出贡献的程序员而写。
（0）决定你工作的基石是什么。
一般而言，应该基于和你的修改相关的最旧的版本分支上。
-如果你是要修复一个 bug，则通常基于‘maint’版本。
如果该 bug不在 ‘maint’中出现，那么就应该基于‘master’。如果那个 bug 也不存在于‘master’中的话，你就应该去找介绍该 regression的专题，然后应该在该主题的指引下进行。
– 如果情况特殊，新特性应该建立在‘master’上。如果新特性是依赖于 ‘pu’而不是 ‘master’，那应该在该专题的指引下进行。
– 如果修正和改善一个没有出现在‘master’上的专题，那么你应该在该专题的相关指引下进行。如果该专题还没有被 merge 到 ‘next’，请添加一个指引，然后把细小的修正挤压到一个系列中。
-针对一个新的特性是基于一系列不在‘master’中的专题这种异常情况，要在‘next’或‘pu’上进行独立的工作，同时分发修补程序以进行讨论。在最后的合并之前，你可能需要等待一段时间，直到部分相关的专题已摆脱了“master”（graduate to ‘master’），之后再重新定位工作所依赖的基石。
-系统的某些模块可能由专门的维护人员在他们自己的仓库中进行维护（参考下面关于“Subsystems”的部分）.在这些模块上进行修改需要基于他们的代码提交树。
若要查找一个专题分支的指引，运行"git log–first-parent master..pu"然后查找合并信息。该提交的第二个父节点就是该专题的分支指引。
（1）分别提交逻辑上不相关的修改
除非你的修改真的非常非常重要，否则不要发送在你的工作树和提交头之间所生成的修改。取而代之的是，总是提交拥有完整提交信息的修改文件及从你自己的仓库中生成一系列的修改文件。相信我，这是一个美好的原则。
为你的修改提供足够详细的说明，使别人可以通过它来判断你的修改是否有价值，而不用通过阅读你提交的修改文件来判断你提交的代码在多大程度上和你的说明所承诺的一致。
如果你开始的描述非常的长，那应该敲响你的警钟，你可能需要把你的提交分成更好的模块。
话虽这么说，但如果你的补丁有一份简洁的描述同时能够帮助审阅者审阅你的修改，帮助未来的维护人员理解你的代码，那将是最美丽的补丁。
包括以下的描述也是一件值得的事：
1、 准确概括这个科目的重点、核心。
2、 描述修改的目的。
3、 该修改使用的方法。
4、 如果相关，当前修改与前一版本的本质区别是什么
确保你测试debug过你修改的文件。参考 t/README
当添加一个新的特性的时候，请确保你测试过你的代码，表明它只做了它该做的，不多也不少。此外，还需要保证你的测试套件在你提交后能够通过检查。可别忘记更新你的文档以记录你的提交行为。
提到文档的问题，那就不得不提由于英国英语和美国英语在拼写和语法形式上存在的文化差异所导致的混淆。在某种程度上，这真是件糟糕的事情。只是为了更正这两者之间的不一致性而创造一个庞大的包罗所有文件的补丁也是不值得提倡的，也很难做到。
冒着带来其它的连锁反应及潜在冲突的险而做这个修改也是不值得的。
我们更喜欢在它们（不一致性）附近做一些其它的真正工作时，以副作用的形式通过一些小的容易理解的补丁渐进地修改这两者的不一致性，使其倾向于美国英语。
（比如：修改 en_UK 检查为en_US 检查，然后为了更清晰而修改一个段落）。显然，进行拼写错误检查会更受欢迎（"teh->"the"），更适宜的是与其它的文档修改分开，作为一个独立的修改而提交。
哦，差点忘记了另外一件大事了。我们对于空白字符非常挑剔。请确保你的修改不会引发错误：with the sample pre-commit hook shipped intemplates/hooks–pre-commit.（不懂）为了保证不会出现上述错误，请在你提交之前执行 git diff –check
（2）更好地描述你的修改。
提交信息的第一行应该是一个简短的描述（一般限制在50个字符内，请参考 git-commit(1)中的DISCUSSION部分），应该跳过句号。
多数情况下，在第一行的前面添加“area：”域，其中“area:”表示的是被修改代码所在的主要区域的文件名或其标识符。比如：
.archive: ustar header checksum is computed unsigned
.git-cherry-pick.txt: clarify the use of revision range notation
如果你不确定使用哪个标识符，在你所修改的文件上执行"git log –no-merges"以查看当前使用的约定。
剩下的主体部分应该提供一个有意义的提交信息，包括：
解释当前修改尝试修正的问题，换句话说，原有代码哪里做的不好？
证明你的修改能够解决上面提到的问题，换句话说，为什么你的修改是值得的？
用祈使语气描述你的修改(比如应该描述成"make xyzzy do frotz" 而不是"[Thispatch] makes xyzzy do frotz" or "[I] changed xyzzyto do frotz")，就好像你对代码发号施令，要求其修改自己的行为。
尽量使理解你的程序不需要额外的资源。不是给出一个到概括了当前讨论相关问题的文件列表的链接。
(3)使用 Git 工具生成你提交的补丁。
Git 依据“diff”工具生成最受欢迎的 unidiff 格式。即使你的修改涉及到文件重命名，也不需要害怕在"git diff" 或
"git format-patch" 中使用 –M 选项。接收者有能力处理它们。
请确保你提交的修改不包含被注释掉的调试代码，也不应包含额外的、与当前修改目的无关的文件。
保险起见，请在生成补丁后进行检查。在发送之前，，请确保它已被应用在“master“分支头上。如果你正准备在它的“next”分支上工作，那很好，否则也请你这么认为。（保证你足够认真对待这件事）
（4）发送补丁
在 git 邮件列表中的成员应该能够阅读和评论你提交的修改。开发者能够使用标准电子邮件工具应用你的修改是很重要的。因为他们可能针对你代码的某一特别部分进行评论。为此，每一个修改都应该用分离的信息进行“在线”提交。
多个相关的修改应该集成在他们独自的邮件列表中，以使读者能够找到该系列的所有相关部分。为此，像回应一样，给他们发送第一个修改的额外“附信”消息（参考下面）或各自修改的前置修改。
如果你的日志消息（包括你在线上签署的名字）不能够用 ASCII表示，请确保你发送了一份正确编码的信。
警告：当心你邮件代理的自动换行弄乱你的代码。不要剪切粘贴你的代码。一不留神就会丢失代码的 tap 字符。
自信是一个人的胆，有了这个胆，你就会所向披靡！
