在過去一年裡，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 社群。現在是一個令人興奮的開發者時代！