原文链接http://drupal.org/node/1134754
恭喜，现在您已经能够编写简单的模块并测试了。但是在现实世界中，我们基本不会有机会从零开始编写自己的模块，多数情况下，drupal已经有一个模块能满足或者接近满足我们的需要。所以如果您要为一个模块提供新的功能或者纠正错误，您共享到整个社区。
在这部分，您将有机会来练习为一个模块建立patch和分析别人为您的模块编写的patch。比如说，我们的模块发布了，但是没有‘more'链接，我们可以提供这个功能。我们将用一个特殊的模块'Current content'代替'Current posts'。您可以把这个模块建立到http://example.com/sites/all/modules路径，来避免与我们之前写的'Current posts'模块产生冲突。
我们的任务是用drupal默认的版本控制系统GIT, 来复制工作区的根目录，建立子分支，在添加了‘more'功能后，提交一个patch。如果您还能想出更多的功能，您也可以一起添加到新功能里。然后把您的patch提交到'Current content' 的报错队列中。下一步，审查在队列中由别人编写的在其他子分支的patch。如果这个patch工作无误，那么我们将把他的状态改为‘审核并测试通过’(RTBC)。（大多数的patch很难达到这个状态，所以在提交patch前，请仔细审查您的patch）如果有人在提交patch的同时还审核patch，那么您的patch也将会被审核。
连接到GIT
Drupal开发社区用GIT来管理drupal所有版本的所有文件。如果您还不熟悉GIT，请参阅一些出色的文档，从Introduction to Git开始。您将需要连接到GIT到您的电脑，请参看Installing Git。
要应用drupal.org的GIT，您必须在drupal.org有一个账户，并在您的资料编辑页面接受'Git access agreement'。请参看Obtaining Git access来获得更详细的说明，然后到Identifying yourself to Git来完成您的设置。
复制工作区根目录
现在我们可以开始建立patch了。首先，访问Current content的开发沙盘。在页面的顶部，查看'Version control'链接，然后在您的电脑上启动终端，然后输入命令来复制工作区。（本部分的说明是基于命令行的，如果您用的是图形界面，您需要把命令转化。）如果您吧代码复制到了http://example.com/sites/all/modules目录，您可以检查功能并运行测试，
建立patch
在GIT中，不同的路径可能会链接到同一个终点。这就是建立patch的真谛。如果您已经有了您自己的流程，只是想练习一下，请继续您自己的流程。在这里，我们将用子分支来联系，这样我们就可以建立并审查patch，而不会影响到模块的源代码了。如果您对以上的说明有意问，请参看下面的其他选择。
在'Current content'队列中，在‘新功能需求’目录下，建立一个新issue。请注意issue号，这将是您issue的url，用下面的命令建立一个子分支：
git checkout -b more_patch-[issue-number]
checkout告诉GIT你在改变一个子分支。-b的意思是您在建立的是一个新的子分支，后面跟着是名字。您可以随便为子分支命名，但是在这里我们建议用issue号，这样就不会于其他issue混淆。我们在这里把batch加到名字里来与我们将审核的batch区分。
现在您可以修改.module文件了，您可以选用任意的编辑器。只要您是在子分支上工作，您的修改就不会影响到主分支的代码。要添加‘more'链接，您需要修改menu方法，page方法，和block view方法中的theme_item_list，就像我们在之前的章节中做的那样。请在您的开发站点中查询相关的代码，让你后您可以运行'Current content'的测试，应该都可以通过。
当您对您的修改满意时，您就可以把修改上传到GIT。在命令行（或者图形界面）中，运行下面的命令：
git status
status命令会告诉您您目前处于patch的子分支上，它还会告诉您您的.module文件已经被修改，但是还没有上传。下一个命令：
git diff
这个命令对您的修改做了最后的检查，来确保您已经包含了所有需要上传的。如果您不小心包含了空格在里面，GIT将把它标出来。确保您把空格都删除，确保所有格式和修改都是正确的，我们的目标是用一次上传就把所有的修改完成。
当您准备好上传您的修改。-A参数将把所有的修改上传到子分支。包括新文件，修改了的文件，和删除了的文件：
git add -A
如果您在这时候运行git status, GIT将会把您的文件放到'Changes to be committed'目录下，现在实施修改：
git commit -m "Issue #[issue number] by [your drupal.org username]: Added a 'More' link"
commit信息严格的遵循drupal的格式，请参看Commit messages - providing history and credit来查询详细的解释。下一步为了防止以外的更改，我们获取最新的代码：
git fetch origin
GIT将提示您正在从drupal.org的'Current content'工作区获取并解压对象。下一步在刚获取的文件中做我们刚才做过的更改：
git rebase origin/master
您将收到信息，告诉您GIT已经从头修改分支上的文件，现在您已经准备好建立您的patch文件了。
建立patch文件
我们有两种方法来建立patch文件：
- 1.只上传更改一次。如果您在一次commit中完成了所有更改，那么您可以用git format-patch命令来建立patch文件并包含您的信息：
git format-patch origin/master --stdout > added_more_link-[issue number]-[comment number].patch确保您没有井号在文件名里，不然文件将不会被接受。
- 2.多次长传。如果您上传了多次，那么您可以用git diff：
git diff origin/master > added_more_link-[issue number]-[comment number].patch
当然，如果您愿意，您夜可以用别的名字。如果您是为core模块写的patch，那这里的将会用core模块的版本号好作为您patch的版本号。如果是其他模块，版本号可能会不同。（如果您在作出注释之前就已经建立了patch，那么您可以推算出注释号。）
当您运行了这个命令，GIT将提交这个patch，但是不会显示任何信息。您将在您当前的工作区的根目录下找到patch文件。（这个工作区只有一个文件夹，如果有多层子文件夹，那么这个patch文件将会被保存在最上层的文件夹。）打开这个文件，并检查您的修改。如果您用的是git format-patch命令，这个patch文件将起始于井号，作者的名字，邮件地址，建立时间和上传信息。如果您用的是git diff命令，这个patch文件将用diff作为起始。如果您只是为了‘more’链接做了修改，那么您的patch文件应该包括三部分。每部分将用行号和修改的方法作为起始。
现在返回到'Current content'的问题队列，上传您的patch，把状态改成‘Needs review‘。
如果您现在运行git status命令，您将发现您的patch文件已经被包括了。为了您不会重复上传这个patch文件，请用下面的命令移除文件：
rm added_more_link-[issue number]-[comment number].patch
审核patch
现在我们已经建立了一个patch，是时候审核别人的patch了。首先选择一个patch，并点击它名字上的链接来浏览。把issue号记录下来。
然后回到命令行，进入current_content目录，检查状态：
git status
如果您不在主工作区，请用下面的命令：
git checkout master
下面要确保您在用最新的版本的代码：
git pull
为审核这个patch建立一个新的子分支:
git checkout -b more_review-[issue number]
有集中不同的方法来下载和应用这个patch。如果您要用curl，请查看这个链接在 'Reviewing patches'下面的内容。我们在这里将用Unix命令wget：
wget http://drupal.org/files/issues/[patchname].patch
git apply -v [patchname].patch
当您下载这个patch时，您将获得很多数据，当您用-v参数时，您将得到一个信息来告诉您是否已经把这个patch应用成功。
如果您现在运行git status，您将看到这个patch已经被包含了。为了您在将来不会重复上传这个patch，请用下面的Unix rm命令来移除此文件：
rm [patchname].patch
检查代码的变化：
git diff
您也可以用其他编辑器查看文件。
现在检查patch。因为现在的sandboxes已经不包括testbot的功能，所以您需要在您的站点上用SimpleTest来测试。请留意您所测试的，哪些工作，哪些不工作。并在issue中写明。要查看如何审核patch的细节，请访问Reviewing patches
如果在您测试中发现什么问题，请把issue的状态改为'Needs work'。如果工作无误，请把状态改成RTBC。注意，在真是的issue队列中，一般需要2人以上来认证patch和把状态改为RTBC。请参看链接来了解如何适当的改变issue状态。
总结
我们终于到了这个教程的结尾。如果您是从头做下来的话，您应该已经熟悉了钩子系统，区块系统，目录系统，数据库系统，表格系统，解析队列，页面方法，一些drupal方法，SimpleTest，和用GIT提交patch。
下一步做什么呢？看一下 Working with the Drupal AP和Examples for Developers， 那些是您所感兴趣的。