在過去的一年裡，新的 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 社群。對於開發人員來說，這是一個激動人心的時代！