在过去一年里，Spring 在多个领域推出了新项目，包括 社交、移动、数据 和 集成。我做这个已经 近 7 年了，说实话，从来没有像现在这样令我兴奋。我之所以这么想，是因为我们的社区理解在前人奠定的基础上再接再厉的重要性。正因如此，我们才能如此快速地前进，这证明了由 Juergen Hoeller 领导的核心开发团队的优秀品质。

让我非常兴奋的一点是，我们看到的社区贡献越来越多。这些贡献传统上是通过 JIRA 以补丁的形式提交，但现代的社交编程平台，如 Github 和 Gitorious，开辟了新的机遇。在这篇博客文章中，我想介绍一种新的贡献模式，它使您能够为自己喜欢的 Spring 项目做出贡献，并直接与核心开发团队合作。

提升对可能性的认识

让我开始思考这个话题的是 Jettro Coenradie 最近一篇关于 Spring Mobile 的博客文章。在他的文章中，Jettro 为一个新功能提出了一个很棒的想法。他甚至花时间整理了一个示例来展示其价值。我当时心想：“太棒了！”，如果 Jettro 能够被授权将他的功能贡献回项目，那岂不是太好了。Jettro 将受益于他的代码出现在下一个官方版本中，而社区也将受益于获得一个以前没有的实用功能。通过社交编程，这一切在今天都成为可能，而让社区了解这一过程是我们的责任。

“社交编程”平台的兴起

在过去两年里，我们看到了社交编程平台的兴起，例如 Github、Gitorious、Bitbucket 和 Launchpad。在这四个平台中，Github 最受欢迎，托管项目超过 100 万个，其中包括 几个 著名的 项目。这些平台的秘诀在于它们结合了 分布式版本控制 的原则，使得共享更改变得容易，同时又具备社交网络功能，以促进赋能软件开发社区的发展。

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

现代社交编程平台提供了一种更优越的工作流程。 首先，我无需成为项目提交者即可进行更改。我被授权可以派生（fork）项目的仓库，创建本地主题分支，然后开始着手修改。我将更改提交到我的仓库中，并在准备就绪时，请求核心开发团队将我分支中的更改拉取（pull）到 master 分支。这种工作流程让你直接关注核心：代码，并避免了与 JIRA issue 和补丁文件相关的繁琐流程。

赋能贡献者的工作流程可以可视化如下

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

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

赋能贡献的示例

对于 Spring Mobile 1.0.0.M2 版本，我亲身经历了这一工作流程，贡献了 Jettro 最初建议的改进。在接下来的部分，我将重演这段经历，以便您可以将其用作您自己赋能贡献的示例。

由于 Spring Mobile 托管在 SpringSource 的 Gitorious 实例上，本示例中的某些内容特定于 Gitorious。不过，总的来说，社交编程平台非常相似。存在显著差异的地方，我会加以说明。

第 1 步：派生（Fork）仓库

我做的第一件事是创建了我自己的 Spring Mobile 仓库派生。Gitorious 使用术语“克隆”（Clone）而非派生（fork），通过点击仓库面板上的“克隆仓库”（Clone Repository）按钮即可完成。

第 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 步：为您的工作创建主题分支

接下来，我为我的改进创建了一个主题分支。主题分支为我的更改提供了一个专门的工作空间，并允许我的派生成为一个可以重复使用的干净的 master 分支镜像。我将该分支命名为 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 步：发送拉取请求

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

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

要创建拉取请求，我在我的派生面板上选择了“请求合并”（Request Merge）。

Gitorious 使用术语“合并请求”（Merge Request）而不是“拉取请求”（Pull Request），后者因 Github 而流行。它们的意思完全相同，并且 Gitorious 和 Github 都提供了一个使过程变得简单的表单工作流程。在表单上，我首先为核心开发团队提供了我的更改描述。

接下来，我指明希望将我的主题分支中的所有提交合并到 master 分支，然后点击“创建合并请求”（Create Merge Request）发送请求。

发送后，开发团队会收到通知，并且主仓库面板上会出现一个新的、开放的“合并请求”。

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

集成赋能贡献的示例

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

第 1 步：审查和测试

首先，我对更改进行了一次快速的代码审查。我通过使用 Gitorious 的差异查看器完成了这项工作，它允许我从网络浏览器审查更改，并可选择对其进行评论。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 步：合并

完成审查后，我将更改合并到 master 分支。

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

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

第 3 步：清理

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

git branch -D kdonald-site-switcher

回到贡献方，我将我的派生与上游 master 分支同步，以拉取已合并的更改。这使得我的派生与不断发展的上游仓库保持同步。

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 社区。现在是一个令人兴奋的开发者时代！