在过去的一年里，新的 Spring 项目在多个领域启动，包括社交、移动、数据和集成。我从事这项工作近7年，说实话，对我来说，从未像今天这样令人兴奋。我之所以有这种感觉，是因为我们的社区理解通过在你之前奠定的基础上进行构建来提高标准的重要性。这就是我们能够如此迅速地发展的原因，这证明了由Juergen Hoeller领导的核心开发团队的质量。

我感到非常兴奋的一件事是，我们看到的社区贡献数量正在增加。这些贡献传统上是通过 JIRA 以补丁的形式提交的，但像 Github 和 Gitorious 这样的现代社交编码平台开辟了新的机会。在这篇博客文章中，我想介绍一种新的贡献模式，它使您能够为您喜爱的 Spring 项目做出贡献，并直接与核心开发团队合作。

提高对可能性的认识

让我思考这个话题的原因是 Jettro Coenradie 关于 Spring Mobile 的最近一篇博文。在他的文章中，Jettro 提出了一个关于新功能的绝妙想法。他甚至花时间编写了一个示例来证明其价值。我当时想“太棒了！”，如果 Jettro 有能力将他的功能贡献回项目，那该有多好。Jettro 将受益于他的代码出现在下一个官方版本中，而社区将受益于拥有一个以前没有的有用功能。有了社交编码，这一切在今天都成为可能，我们有责任让社区了解这个过程。

“社交编码”平台的兴起

在过去两年中，我们看到了像 Github、Gitorious、Bitbucket 和 Launchpad 等社交编码平台的兴起。在这四个平台中，Github 最受欢迎，托管了超过 100 万个项目，其中包括 几个 知名 项目。这些平台的秘密武器在于它们结合了分布式版本控制的原则，使共享更改变得容易，以及社交网络功能，以培养有能力的软件开发社区。

因此，假设像 Jettro 一样，我是一个需要对 Spring 项目进行改进的用户。以前，我能做的最好的事情是检出源代码，在本地进行更改，生成一个补丁文件，然后将补丁附加到 问题。由于我不是项目提交者，我无法自己提交任何更改。我也无法创建分支，让我同时处理多项改进。如果我发现我的一个补丁需要改进，我将被迫进入生成和附加另一个补丁文件的痛苦过程。

现代社交编码平台提供了一种卓越的工作流程。首先，我不需要成为项目提交者才能进行更改。我有权派生项目的存储库，创建一个本地主题分支，然后开始编码。我将更改提交到我的存储库，当我准备好时，我请求核心开发团队将更改从我的分支拉入主分支。这种工作流程让您直接关注最重要的事情：代码，并避免了与 JIRA 问题和补丁文件相关的繁文缛节。

“赋能贡献者”工作流程可视化如下

Spring 项目团队成员（例如 Juergen Hoeller）收到您的拉取请求，然后整合您的更改

一个好的社交编码平台提供支持此工作流程的有用功能，例如交互式差异审查器、审查讨论功能、贡献者许可协议 (CLA) 处理器和事件通知器。

赋能贡献的示例

对于 Spring Mobile 1.0.0.M2 版本，我亲自经历了此工作流程，贡献了 Jettro 最初建议的改进。在以下部分中，我将重现该经验，以便您可以将其作为您自己赋能贡献的示例。

由于 Spring Mobile 托管在 SpringSource Gitorious 实例上，因此此示例中的某些内容是 Gitorious 特有的。但总的来说，社交编码平台非常相似。如果存在显著差异，我将予以说明。

步骤 1：派生存储库

我做的第一件事是创建我自己的 Spring Mobile 存储库派生。Gitorious 使用“克隆”而不是派生，这是通过单击存储库仪表板上的“克隆存储库”按钮来完成的

步骤 2：在本地克隆您的派生

接下来，我将我的派生克隆到文件系统上的本地目录

git clone --recursive [email protected]:~kdonald/spring-mobile/kdonalds-spring-mobile.git

请注意 URL 如何引用我 Gitorious 用户目录中的存储库位置。作为比较，Github 的 URL 格式相似，但略有不同

git clone --recursive [email protected]:kdonald/spring-mobile.git

步骤 3：与上游存储库链接

接下来，我将我的本地派生连接到上游 Spring Mobile 存储库。这是一个可选步骤，但通常建议这样做，因为它允许我随着更改推送到上游存储库而保持我的派生最新。

git remote add upstream git://git.springsource.org/spring-mobile/spring-mobile.git
git fetch upstream

步骤 4：为您的工作创建一个主题分支

接下来，我为我的改进创建了一个主题分支。主题分支为我的更改提供了一个专用的工作区，并允许我的派生保持主分支的干净镜像，可以重复使用。我将该分支命名为 site-switcher，以我打算实现的功能的名称命名

git checkout -b site-switcher

步骤 5：编写、提交并推送您的更改

接下来，我实现了该功能，以逻辑的、迭代的块在本地提交我的工作。我经过多次迭代才得到一个满意的完整实现，其中包括新代码、测试和文档。最后，我向我的派生推送了 4 次提交。

./gradlew eclipse build <!-- import into Eclipse and hack, hack, hack... -->
git commit -m "logical commit 1"
git commit -m "logical commit 2"
git commit -m "logical commit 3"
git commit -m "logical commit 4"
git push origin site-switcher

步骤 6：发送拉取请求

接下来，我向开发团队发送了一个拉取请求，请求他们将我的更改集成到主存储库中。在此之前，我确保我的更改可以在不冲突的情况下应用于主分支的当前状态

git checkout master
git fetch upstream
git merge upstream/master
get checkout site-switcher
get rebase master

要创建拉取请求，我从我的派生仪表板中选择了“请求合并”

Gitorious 使用“合并请求”而不是“拉取请求”，后者已由 Github 推广。它们的含义完全相同，Gitorious 和 Github 都提供了一个表单工作流程，使该过程变得微不足道。在表单上，我首先为核心开发团队提供了我的更改的描述

接下来，我表示希望将我的主题分支中的所有提交合并到主分支中，然后单击“创建合并请求”发送请求

发送后，开发团队会收到通知，并且一个新的、开放的“合并请求”会出现在主存储库的仪表板上

每个拉取或合并请求都被分配一个 URL，您可以在其中查看合并状态、审查差异并讨论更改。

整合赋能贡献的示例

此时，球在核心开发团队手中。他们的责任是在合理的时间范围内，以社区的最佳利益审查并整合您的更改。在本节中，我将通过说明典型的集成工作流程来继续示例。

步骤 1：审查和测试

首先，我快速审查了更改的代码。我通过使用 Gitorious 的差异查看器完成了这项工作，它允许我从 Web 浏览器审查更改并选择性地评论它们。Github 提供了类似的功能。

接下来，我创建了一个本地分支，它为我提供了一个专用的工作区来拉取更改并测试它们

git checkout -b kdonald-site-switcher master
git pull git://git.springsource.org/spring-mobile/spring-mobile.git refs/merge-requests/1
git log --pretty=oneline --abbrev-commit master..kdonald-site-switcher
./gradlew build

在 Gitorious 上，每个合并请求都会从目标存储库中派生一个分支，该分支也可以用于推送从审查中识别出的额外改进。在 Github 上，您只需直接从贡献者主题分支拉取

git pull https://github.com/kdonald/spring-mobile.git site-switcher

步骤 2：合并

完成审查后，我将更改合并到主分支中

git checkout master
git merge kdonald-site-switcher
git push origin master

在 Gitorious 上，我现在必须更新合并请求的状态为“已关闭”，表示它已完成（Github 会在合并后自动关闭拉取请求）。贡献者将收到通知，剩下的就是一些最后的清理工作。

步骤 3：清理

在集成方面，我只需删除我的本地审查分支。由于更改现在已经合并，它不再需要了

git branch -D kdonald-site-switcher

回到贡献方面，我将我的派生与上游主分支同步，以拉入已合并的更改。这使我的派生与不断发展的上游存储库保持同步

git checkout master
git fetch upstream
git merge upstream/master
git log

我删除了我的主题分支，因为我的工作已经完成

git branch -D site-switcher
git push origin :site-switcher

就是这样！我的更改现在已集成，我现在是 Spring Mobile 的正式 @作者，我的提交历史得到了完整保留！在等待我的更改集成期间，我也可以并行处理额外的改进，每个改进都在一个专门的主题分支中。我还制作了一个快速的 截屏视频，展示了新功能对社区的价值。

Github 与其他平台

在下一节中，我想简要强调社交编码平台之间的比较以及 SpringSource 当前如何使用它们。

鉴于 Github 的受欢迎程度，所有其他社交编码平台都不可避免地与其进行比较。我最近在 Hudson 邮件列表上读到一篇文章，其中指出，对于开发人员来说，“拥有一个 GitHub 帐户几乎与拥有一个 Twitter 句柄或 Gmail 地址一样普遍”。我曾 见过 雇主 使用 Github 个人资料作为筛选求职者时的差异化因素。各种平台的具体功能实际上 非常相似。Github 相对于其他平台的显著优势在于其受欢迎程度和 领导地位。这对于专注于建立多元化、赋能社区的 开源项目 尤其具有吸引力。

SpringSource 自己目前运行着一个内部 Gitorious 实例，该实例托管着许多项目，包括 Spring Integration、Security、Roo、Mobile 和 Social。Gitorious 的优势在于它可以免费托管您自己的实例，这正是我们所做的，将这些项目托管在我们自己的基础设施上。

SpringSource 最近还在 Github 上注册成为一个组织，新的 Spring Data 项目以及 Batch、AMQP 和 Grails 都托管在那里。

总的来说，我预计未来会有越来越多的 Spring 项目采用 DVCS 和社交编码，对此我感到非常兴奋。我预计我们将继续支持 Gitorious 和 Github，并且最终您可能会看到所有内容都可以从 Github 访问（无论是直接还是通过镜像）。我很想听听您对您想看到什么以及您是否偏爱特定平台的反馈。

总结

我希望这篇帖子能帮助您了解社区贡献的卓越模式。我鼓励您充分利用它，成为一名赋能的 Spring 开发人员，与我们的核心开发团队一起处理您职业生涯中每天使用的项目。代表 Spring 项目团队，我们非常期待与您中的许多人建立新的和更新的关系，以造福整个 Spring 社区。对于开发人员来说，这是一个激动人心的时代！