在過去一年中，新的 Spring 專案在許多領域啟動，包括 社群、行動、資料 和 整合。我從事這行 將近 7 年了，老實說，對我而言從未像今天這樣令人興奮。我之所以有這種感覺，是因為我們的社群理解到，透過在您先前奠定的基礎上發展，來提高標準的重要性。這就是為什麼我們能夠如此快速地進展，這也證明了由 Juergen Hoeller 領導的核心開發團隊的素質。

我非常興奮的一件事是，我們看到的社群貢獻數量不斷增加。這些貢獻傳統上是以修補程式的形式透過 JIRA 提交，但現代的社群協作程式碼平台，例如 Github 和 Gitorious，開創了新的機會。在這篇部落格文章中，我想介紹一種新的貢獻模式，讓您可以為您最喜歡的 Spring 專案做出貢獻，並直接與核心開發團隊合作。

提高對可能性的認識

讓我開始思考這個主題的是 Jettro Coenradie 最近一篇關於 Spring Mobile 的 部落格文章。在他的文章中，Jettro 提出了一個關於新功能的絕妙想法。他甚至花時間整理了一個範例，展示了它的價值。我當時的想法是「太棒了！」，如果 Jettro 能夠被授權將他的功能貢獻回專案，那不是太棒了嗎？Jettro 將受益於他的程式碼被納入下一個官方版本，而社群將受益於獲得一個他們以前沒有的有用功能。透過社群協作程式碼，這一切在今天都是可能的，而讓社群了解這個流程是我們的責任。

「社群協作程式碼」平台的興起

在過去兩年中，我們看到了社群協作程式碼平台的興起，例如 Github、Gitorious、Bitbucket 和 Launchpad。在這四個平台中，Github 最受歡迎，託管了超過 1 百萬個 專案，包括 幾個 著名的 專案。這些平台的秘訣在於它們結合了 分散式版本控制 的原則（這使得共享變更變得容易）與社群網路功能，以促進授權的軟體開發社群。

假設，像 Jettro 一樣，我是一個需要對 Spring 專案進行改進的使用者。以前，我能做的最好的事情是檢出原始碼，在本地進行更改，生成修補程式檔案，然後將修補程式附加到 問題。由於我不是專案提交者，我無法自行提交任何變更。我也無法建立一個分支，讓我一次處理多個改進。如果我發現我的其中一個修補程式需要改進，我會被迫進入生成和附加另一個修補程式檔案的痛苦過程。

現代社群協作程式碼平台提供了卓越的工作流程。 首先，我不需要成為專案提交者即可進行變更。我被授權可以 Fork 專案的儲存庫，建立本地主題分支，然後開始編碼。我將我的變更提交到我的儲存庫，當我準備好時，我請求核心開發團隊將變更從我的分支拉取到主分支中。這個工作流程讓您直接處理重要的事項：程式碼，並避免與 JIRA 問題和修補程式檔案相關的官僚程序。

被授權的貢獻者 工作流程可以視覺化如下

Spring 專案團隊成員（例如 Juergen Hoeller）收到您的提取請求，然後整合您的變更

一個好的社群協作程式碼平台提供了有用的功能來支援這個工作流程，例如互動式差異檢閱器、檢閱討論功能、貢獻者授權協議 (CLA) 處理器和事件通知器。

授權貢獻的範例

對於 Spring Mobile 1.0.0.M2 版本，我親身經歷了這個工作流程，貢獻了最初由 Jettro 提出的改進。在以下章節中，我將重現該經驗，以便您可以將其作為您自己授權貢獻的範例。

由於 Spring Mobile 託管在 SpringSource Gitorious 實例 上，因此此範例中的某些內容是 Gitorious 特有的。但是，總體而言，社群協作程式碼平台非常相似。在存在顯著差異的地方，我會註明它們。

步驟 1：Fork 儲存庫

我做的第一件事是建立我自己的 Spring Mobile 儲存庫的 Fork。Gitorious 使用術語「Clone」而不是 Fork，這可以透過點擊儲存庫儀表板上的「Clone Repository」按鈕來完成

步驟 2：在本地 Clone 您的 Fork

接下來，我將我的 Fork Clone 到我檔案系統上的本地目錄

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：連結到上游儲存庫

接下來，我將我的本地 Fork 連接到上游 Spring Mobile 儲存庫。這是一個可選步驟，但通常建議這樣做，因為它讓我能夠在變更被推送到上游儲存庫時保持我的 Fork 為最新狀態。

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

步驟 4：為您的工作建立主題分支

接下來，我為我的改進建立了一個主題分支。主題分支為我的變更提供了專用的工作區，並允許我的 Fork 保持為主分支的乾淨鏡像，可以重複使用。我將分支命名為 site-switcher，以我打算實作的功能名稱命名

git checkout -b site-switcher

步驟 5：編碼、提交和推送您的變更

接下來，我實作了這個功能，以邏輯的、迭代的區塊在本地提交我的工作。我迭代了幾次才得到一個完整的實作，我對此感到滿意，其中包括新程式碼、測試和文件。最後，我將 4 次提交推送到了我的 Fork。

./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

為了建立提取請求，我從我的 Fork 的儀表板中選擇了「Request Merge」

Gitorious 使用術語「Merge Request」而不是「Pull Request」，後者已在 Github 上普及。它們的意思完全相同，Gitorious 和 Github 都提供了表單工作流程，使這個過程變得非常簡單。在表單上，我首先為核心開發團隊提供了我的變更描述

接下來，我指示我希望將我的主題分支中的所有提交合併到主分支中，然後點擊「Create Merge Request」發送請求

發送後，開發團隊會收到通知，並且在主儲存庫的儀表板上會出現一個新的、開啟的「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：合併

完成檢閱後，我將變更合併到主分支中

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

在 Gitorious 上，我現在必須更新合併請求的狀態為「已關閉」，表示它已完成（Github 會在合併後自動關閉提取請求）。貢獻者將收到通知，剩下的就是一些最終的清理工作。

步驟 3：清理

在整合方面，我只需刪除我的本地檢閱分支。由於變更現在已合併，因此不再需要它

git branch -D kdonald-site-switcher

回到貢獻方面，我將我的 Fork 與上游主分支同步，以拉取合併的變更。這使我的 Fork 與不斷發展的上游儲存庫保持同步

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 社群。現在是成為開發人員的令人興奮的時刻！