在过去的一年中，Spring 项目在许多领域都推出了新的项目，包括社交、移动、数据和集成。我已经做了这个将近7年，老实说，对我来说，现在比以往任何时候都更令人兴奋。我觉得是这样，因为我们的社区理解通过建立在您之前奠定的基础上提高标准的重要性。这就是为什么我们能够如此快速地前进的原因，这也是对由Juergen Hoeller领导的核心开发团队质量的证明。

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

提高对可能性的认识

让我想到这个主题的是Jettro Coenradie撰写的关于Spring Mobile的最近一篇博文。在他的博文中，Jettro提出了一项关于新功能的绝妙想法。他还花时间编写了一个示例来展示其价值。我心想“太棒了！”，如果Jettro能够将他的功能贡献回项目中该有多好。Jettro 将受益于他的代码出现在下一个官方版本中，而社区将受益于可以使用以前没有的实用功能。借助社交编码，这一切在今天都是可能的，我们有责任让社区了解这个流程。

“社交编码”平台的兴起

在过去两年中，我们看到了诸如Github、Gitorious、Bitbucket和Launchpad等社交编码平台的兴起。在这四个平台中，Github 最受欢迎，拥有超过一百万个托管项目，包括一些著名的项目。这些平台的秘诀在于它们将分布式版本控制的原则（使共享更改变得容易）与社交网络功能相结合，从而培养了强大的软件开发社区。

所以假设，像 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 @author，我的提交历史记录得到了完整保留！在等待我的更改被集成时，我还可以并行处理其他改进，每个改进都在一个专用的主题分支中。我还制作了一个简短的屏幕录像，向社区展示了新功能的价值。

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社区。这是一个成为开发者的激动人心的时刻！